Discussion:
LLVM code generator
(too old to reply)
Jonas Maebe
2018-12-02 10:26:16 UTC
Permalink
Hi,

The LLVM code generator is more or less ready, including Dwarf-EH-based
exception handling support. It's currently only supported on
Darwin/x86-64 and Linux/x86-64, but it can do a "make all" and the
testsuite can be finished as well. There are still some extra failures
that do not happen with the built-in code generator, but most tests work
fine.

What still needs to be done:
* investigate the RTE 217 when you compile a program with an error in it
* add support for a volatile() built-in function similar to how we have
unaligned(), to fix e.g. the endless loop in tests/test/tmt1 (or in
general: global variables used for cross-thread synchronisation)
* add support for specifying the target LLVM version. Currently it's
hard-coded to LLVM 3.9, although it works all the way up to at least
LLVM 7.0. Specifying the version number would mainly be necessary (for
now) to target older LLVM versions
* check some remaining test failures
* add support for more platforms. Windows will be harder (and not
something I plan on working any time soon), because I have not yet added
support for generating LLVM-based exception handling code that is needed
for SEH-based exception handling. Other 64 bit platforms should be
"reasonably" easy (the parameter handling needs to be generalised more
though). 32 bit platforms will probably require either some compiler
re-engineering, hacking, or a translation of the tcg64 code generator to
some kind of high-level code generator as well.
* add support for generating debug info
* add support for generating more meta-information for optimizations
(e.g. range information about subrange types and enums)
* add support for saving the bitcode in addition to the native object
files, and subsequently using link-time optimisation
* add support for some custom calling conventions
* pass on more FPC-related code generation options to LLVM (currently,
mainly -CfXXX and -Ox get passed on)
* add support for TLS-based threadvars

Known limitations:
* hardware exceptions are unsupported. They will be caught, but
unwinding is hit-and-miss because the state of the registers may be
completely different than what LLVM expects (higher optimisation levels
= more chance it will fail). This is an LLVM limitation and not
something that can be fixed in FPC. It's also a major source of extra
tests failures.

The support is currently only on the
https://svn.freepascal.org/FPC/svn/fpc/branches/debug_eh branch.

To test:
* make sure you have clang on your system (the ones from Xcode work fine
too) and that it's in your path. If not, you can download one from
http://releases.llvm.org/download.html#7.0.0
* build FPC as follows
** Darwin (can also use a higher version than 10.6, but the built-in
default --10.5--- won't work):
make LOCALOPT="-dllvm -Fullvm" OPT="-WM10.6" all
** Linux: you may also have to specify the library path to libgcc_s.
E.g. on Ubuntu 16.04:
make LOCALOPT="-dllvm -Fullvm -Fl/usr/lib/gcc/x86_64-linux-gnu/5"
OPT="-Fullvm -Fl/usr/lib/gcc/x86_64-linux-gnu/5" all -j 4 FPMAKEOPT="-T
4"

The LOCALOPT flags are only used while building the compiler. They're
separate here because otherwise you get errors while building the IDE
(the -Fullvm doesn't work there while -dllvm would still make it use
llvm units). This does mean that IDE will be built without the LLVM code
generator, and hence its built-in compiler won't generate working code
because it won't use Dwarf-EH-based exception handling, while the RTL
will only contain support for that kind of exception handling.

Note that on Linux, all generated binaries will be dynamically linked
and depend on libc (and libgcc_s), unlike with the regular code
generator.


Jonas
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailma
Ryan Joseph
2018-12-03 06:57:28 UTC
Permalink
The LLVM code generator is more or less ready, including Dwarf-EH-based exception handling support. It's currently only supported on Darwin/x86-64 and Linux/x86-64, but it can do a "make all" and the testsuite can be finished as well. There are still some extra failures that do not happen with the built-in code generator, but most tests work fine.
What does this mean for end users? Do we get better debugging support in LLDB?

Regards,
Ryan Joseph

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/l
Jonas Maebe
2018-12-03 17:22:34 UTC
Permalink
Post by Ryan Joseph
Post by Jonas Maebe
The LLVM code generator is more or less ready, including
Dwarf-EH-based exception handling support. It's currently only
supported on Darwin/x86-64 and Linux/x86-64, but it can do a "make
all" and the testsuite can be finished as well. There are still some
extra failures that do not happen with the built-in code generator,
but most tests work fine.
What does this mean for end users?
An option to exchange (a lot of) compilation speed for faster code.
Post by Ryan Joseph
Do we get better debugging support in LLDB?
Unlikely. That would at best be a trade-off (possibly better support as
long as you consider the source as C++ instead of Pascal), and something
for which you don't need an LLVM-based code generator. That mainly
requires patches to LLDB to add support for Pascal-specific types and
features.


Jonas
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.or

Marģers . via fpc-devel
2018-12-02 16:25:40 UTC
Permalink
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Jonas Maebe
2018-12-03 17:18:56 UTC
Permalink
Post by Jonas Maebe
** Linux: you may also have to specify the library path to libgcc_s.
make LOCALOPT="-dllvm -Fullvm -Fl/usr/lib/gcc/x86_64-linux-gnu/5"
OPT="-Fullvm -Fl/usr/lib/gcc/x86_64-linux-gnu/5" all -j 4 FPMAKEOPT="-T
4"
compilation does not work for me with those options. I keep getting following error
Fatal: Cannot open whole program optimization feedback file "/home/blabla/src/llvm/compiler/pp1.wpo"
Fatal: Compilation aborted
Makefile:3912: recipe for target 'system.ppu' failed
Problem is LOCALOPT. As soon it is as parameter for make, then wpo files are not created.
Strange. You can add NOWPOCYCLE=1 to disable the cycle with wpo.

Jonas
Loading...