The llvmcompiler branch

Truecolor ZDoom with extra features and some unofficial/beta GZDoom features.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Libs (Win)] [Repo] [Bugs&Suggestions]

Moderators: Rachael, dpJudas

User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: The llvmcompiler branch

Post by Rachael »

This is why people who know nothing about computers should never be in charge of those that do. :( At least, not in a direct decision making process. They always expect computers and programmers to be more magical than they really are.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: The llvmcompiler branch

Post by Graf Zahl »

In the case I mentioned it was actually a programmer, but one of the overpaid kind with a nice degree and very little knowledge of software engineering. He was a good programmer but as a project leader not the right person. And I think it's telling that the next job he took was as a Java programmer in some large company maintaining their in-house software.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: The llvmcompiler branch

Post by Graf Zahl »

Do you have an ETA on uploading these files?

I'd like to set up a test enviroment but from the CMakeLists file I can't really tell where to put what.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: The llvmcompiler branch

Post by dpJudas »

Just finished testing them: https://github.com/dpjudas/dpDoom/tree/ ... m-binaries :D

My CMake skills are rather poor unfortunately. I tried to make it so that if the 7z files are unzipped into a llvm subfolder it will pick them up automatically. I'm sure someone better at CMake could make it more clever about it. Make sure you get the latest version of the llvmcompiler branch as I did some last minute changes to the CMakeLists file.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: The llvmcompiler branch

Post by Graf Zahl »

Got 'em.

One question: The old version had

set( LLVM_COMPONENTS_X86 x86asmprinter x86info x86desc x86utils x86codegen )
set( LLVM_COMPONENTS_X64 aarch64asmprinter aarch64info aarch64desc aarch64utils aarch64codegen )


the new one only x86, even for 64 bit. Why?
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: The llvmcompiler branch

Post by dpJudas »

Turns out that the x86 codegen stuff is for x64 as well. What the AArch64 target then is I have no idea.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: The llvmcompiler branch

Post by Graf Zahl »

Google says ARM64. We'd need that if we wanted to target iOS (that is, if that system allowed dynamic code generation. Apple won't even allow dynamic scripting into the store.)
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: The llvmcompiler branch

Post by dpJudas »

The ARM target must be the old 32 bit ARM then.

Do they consider DECORATE scripting? If not, an iOS version of ZDoom could always use the interpreter that the execution engine also has.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: The llvmcompiler branch

Post by Graf Zahl »

dpJudas wrote:The ARM target must be the old 32 bit ARM then.

Do they consider DECORATE scripting? If not, an iOS version of ZDoom could always use the interpreter that the execution engine also has.

I said "dynamic scripting". They have an issue with software that can alter its behavior after installation by generating or downloading new code that Apple is unable to review.
That by its very definition makes ZDoom a no-go.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: The llvmcompiler branch

Post by Graf Zahl »

Oh, and btw, I just finished a test compile with LLVMProgram initializing itself. The size of ZDoom has doubled from 5 to 10 MB.
Well, I think we can end the experiment right here. This is not going to fly, I fear. :(

I'm waiting for feedback on the ZDoom dev forum before proceeding.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: The llvmcompiler branch

Post by dpJudas »

Yes well, doesn't really surprise me if ZDoom would consider this a showstopper. It isn't a particular large executable though: Battlefield Bad Company 2 (2010) is 18 MB, Civilization 5 is 16 MB (2010), American Truck Simulator 19 MB (2016).

There's also the issue with at least GZDoom (and maybe also ZDoom nightly builds?) being compiled with the legacy XP toolset in VS2015. Probably best to just stay with the current interpreter for decorate.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: The llvmcompiler branch

Post by Graf Zahl »

The XP toolset is irrelevant here, it only affects Windows SDK stuff itself, it should have no impact on code generation for system independent libraries that do not call some more esoteric parts of the system API.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: The llvmcompiler branch

Post by Rachael »

The files have been given a (temporary) permanent home, here: http://qzdoom.drdteam.org/download
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: The llvmcompiler branch

Post by dpJudas »

Thanks Eruanna. Removing them from own repository again.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: The llvmcompiler branch

Post by Rachael »

You're welcome. If/when QZDoom starts getting official releases, I'll likely make a special development folder for them but they'll still be accessible from that link.
Locked

Return to “QZDoom”