Delphi x86 classic back-end: bit-rot or bit-swelling? (assembler dumps)
Delphi x86 classic back-end: bit-rot or bit-swelling? (assembler dumps)
PS: vote please at http://qc.embarcadero.com/wc/qcmain.aspx?d=121566
PPS. comparison of Win64 codegen - almost the same results: http://kazav.blogspot.ru/2014/02/delphi-2-64.html
PPPS: XE5 LLVM (Android) example, claimed are Release mode and maximum optimizations on: http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1034973&msg=15555899
PS: vote please at http://qc.embarcadero.com/wc/qcmain.aspx?d=121566
PPS. comparison of Win64 codegen - almost the same results: http://kazav.blogspot.ru/2014/02/delphi-2-64.html
PPPS: XE5 LLVM (Android) example, claimed are Release mode and maximum optimizations on: http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1034973&msg=15555899
Can't say anything but wow, especially the XE5 assembly dump - three try-finally blocks!
ReplyDeleteWe certainly have seen resulting EXE jump in size over the years... and I wonder the reason for the poor optimizations. In order to get small EXEs, that can be embedded in resources (for auto-update help), I have to compile them it in Delphi 7; in order to get the size down to 33% vs Delphi XE2. Delphi 7 was released 12 years ago in 2002.
ReplyDeleteI knew things had gotten worse with the codegen but seriously... wow.
ReplyDeleteI wonder how 64bit code generation compares between versions (where applicable)?
ReplyDeleteVin Colgin Hey, when was obsessed with that, i compiled 2KB size DLLs in Delphi 5 :-) It turned out, Windows just could not load them though :-D Perhaps they need at least 4KB of single i80386 virtual page :-)
ReplyDeleteVincent Parrett then vote for http://qc.embarcadero.com/wc/qcmain.aspx?d=121566 Not that i think it would help, i think non-LLVM Delphi is mostly abandoned, but who knows
ReplyDeleteVoted. Must be something seriously wrong with the codegen in that case. I guess problem is since it executes correctly it will not be prioritized by Embarcadero.
ReplyDeleteI have a feeling like they since XE took a policy of fixing Internal Compiler Errors by removing AST optimizations instead of fixing the optimizer
ReplyDeleteArioch The : I think, from what I've heard elsewhere, Delphi does not use LLVM right now for Windows. C++64 does, C++32 doesn't, the mobile compilers do (? not sure.)
ReplyDeleteI am very excited about what LLVM could bring to Delphi if only it was used in the Windows compilers - it produces great optimisations, and from what I know would almost certainly really help the performance of compiled code.
David Millington Delphi (not BCB) does not use LLVM for intel processors (Windows and MacOS and iOS Simulator).
ReplyDeleteLLVM is much slower (or do you believe there would be incremental compilation in Delphi, where you recompile a single procedure of all the project in bacground?), would ruin all the DCU/DCP/BPL infrastructure (hence al the partners like DevExpress and TMS), would ruin all the current code with their "every object is interface" and "we do not warrant exceptions catched by try-except". It might be interested as an option of course.
However. releasing it now would prevent EMBT from selling Premium Mobile For Android/x86 for extra $500 later, when they would undo the binding of LLVM to ARM-only. So, it would not happen.
And since they focus on LLVM now, they would not enhance classic for-intel compiler, except for most simplistic fixes like "remove that procedure altogether - it throws exceptions"
Why does it generate calls to UStrLAsg and UStrClr? The string arguments are const declared, nothing of that should be needed. And no finally blocks either.
ReplyDeleteArioch The Slowness I'd be happy with when optimization is turned on. But the rest I don't understand: why would it ruin the DCU/DCP/BPL structure? What is "every object is an interface" with LLVM? And exceptions? Can you explain or link to pages about these, please? I'm keen to learn more, mostly because from what I currently know I really like the idea of LLVM as a backend for Delphi.
ReplyDeleteNicholas Ring added link to comparison of Win64 codegen
ReplyDeleteDavid Millington LLVM has it's own frameworks for half-compiled routines, for ASTs for generics, for keeping arguments list, for keeping class declaration hashes, for keeping Win32 resources, etc, etc, etc.
ReplyDeleteTry to use Delphi DCU in Lazarus. Try to use Delphi 7 DCU in Delphi 2007. When succed - you can try to use DCU in much more different LLVM infrastructure.
For the rest for example - http://docwiki.embarcadero.com/RADStudio/XE4/en/Migrating_Delphi_Code_to_iOS_from_Desktop and also a lot of blogs and articles
Arioch The I'm afraid I am probably missing the point you're trying to make, and I'm sorry. I am trying to understand. I'm still not sure why LLVM's custom info is any different to having different-format DCUs (say) every version. A DXE4 DCU isn't compatible with a DXE5 DCU. So, even if LLVM does produce its own, very different metadata, why does that matter? If the whole system uses LLVM then it's integrated - the format is opaque, we as users of the IDE don't need to know.
ReplyDeleteI mean, the LLVM compiler works for iOS. Why, fundamentally, can't it for another platform?
So far the only obstacles I see (that is, that I understand) are some of the design decisions made in the next-gen compiler, such as 0-based strings, and even they could be fixed or changed. I do remember that they would have to write structured exception handling for LLVM for a 32-bit version, but Borland invented it, so I'm sure they can manage. Also C++64 uses LLVM, quite successfully...
David Millington maybe you're right, I don't know LLVM internals. So maybe there really is a 1 to 1 mapping of metadata and all intermediate formats. However all C++ compilers I saw did not had analogs of tpl/tpu-dcu/dcp. They had obj and lib files - compiled code without interface like datatypes and constants. They had "precompiled headers" - but that is interface separated from the code and it is "all modules used by the project" rather than per-module (dpk,dcp,lib) files. Also they don't have half-compiled AST, with is used to implement inline functions and generics (there's no generics in C++). All in all EMBT wanted an easy ride rather than a real complex work. They took LLVM to minimize and localize their work by only writing Pascal parser to LLVM IL. Like there is a hobbyist who did it for FPC. rearranging the internal layers of LLVM, separating and decoupling community-maintained pipeline and designing a reliable way to store half-compiled stages... possible in theory, but EMBT has no resources for much easier tasks...
ReplyDeleteArioch The Ok. Thanks for the longer explanation :)
ReplyDelete