<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, Oct 27, 2018 at 8:47 AM Jonas Maebe <<a href="mailto:jonas@freepascal.org">jonas@freepascal.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 27/10/18 05:45, Ben Grasset wrote:</blockquote><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You also need "opt" if you want to perform full optimizations (or just <br>
use clang, which a.o. combines the functionality of llc and opt).<br>
<br>
There's one more problem I forgot to mention in my first post, and it is <br>
probably a deal breaker for the original bounty: LLVM does not support <br>
Borland's fastcall calling convention for i386. So you would need to add <br>
support for Borland fastcall on i386 to LLVM if it has to support <br>
existing i386 inline assembly routines written for FPC/Delphi.<br>
<br>
Finally, adding support for 32 bit targets in FPC's LLVM backend would <br>
also require some work due to how FPC's code generator is structured, <br>
and due to the fact that need to have two code generators in a single <br>
binary (the native one to support the generation of entry and exit code <br>
for pure inline assembler routines, and the LLVM one for the rest).<br></blockquote><div><br></div><div>LLC (at least now) statically links the necessary parts of LLVM and works independently of Opt, with a simpler set of command line options (it just has overall O1, O2, and O3 flags.)</div><div><br></div><div>As far as the point about assembly on 32 bit, while it does seem like that would be a problem for the bounty requirements, would it really be the end of the world in a more general sense? I can't imagine people who are still using 32-bit-hardware and writing 32-bit applications would complain if the LLVM backend was not available for 32-bit.</div><div><br></div><div>Anyways though, I do think code gen improvements for FPC, LLVM or not, are likely going to be a lot more widely helpful than just rewriting exception handling.... (not that rewriting exception handling is a bad idea.) I think there's a lot of people who would like FPC to generate faster code than it currently does. Can you recommend any known areas in need of improvement of the non-platform-specific parts of the code generators that might be a good place to start for someone who's an experienced Pascal developer but hasn't worked with the compiler codebase before?</div></div></div>