Jonas Maebe
2018-12-02 10:26:16 UTC
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
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