On 31/08/16 05:11, African Wild Dog wrote:
Thanks for the detailed explanation. I asked about it because apparently
it is a good idea to adopt the LLVM as the backend for FPC compiler.
This would free the FPC's core developers from the task of maintain the
backend portion of the compiler, which is not a trivial task,
considering the dozens of architectures and operating systems which is
currently supported, and other details such as the code optimizer.
The code optimizers, yes. The rest, not so much.
Will the FPC team, somewhere in the future, adopt the LLVM as the
backend on all platforms ?
No, for various reasons:
* LLVM will almost certainly never support all targets that we support
(Gameboy Advance, OS/2, WinCE, ...), or at some point drop support for
targets that we still support (as already happened with Mac OS X for
PowerPC/PowerPC64).
* the native FPC code generators require very little maintenance once
written, as they are quite well insulated via abstractions from the rest
of the compiler
* you still need some of the hardest parts of the FPC native code
generators anyway for LLVM (entry/exit code handling, parameter
manager), to be able to deal with assembler routines and because LLVM
does not fully abstract parameter passing
* a hardware architecture seldom changes in backward-compatibility
breaking ways once released, while LLVM makes no such promises. They do
seem to have finally settled more or less on the binary bitcode format
(even there are no guarantees, but maybe I'll add support for that after
all)
* LLVM changes a lot, all the time. That means a high chance of
introducing regressions. I don't know how likely it would be that
FPC-with-LLVM would one day be admissible to be run as part of LLVM's
buildbots and automatic regression tests, but if not then it's possible
that maintaining the LLVM backend may become more work than the regular
code generators and optimizers combined (at least if we want to keep up
with the latest LLVM versions, and not stick with a particular version
for long times like most out-of-tree "consumers" of LLVM do)
* most OS-specific support is in the run time library, not in the
compiler. As a result, LLVM will not save much time there
* our native code generators are much faster than LLVM's (even if you
would neglect the overhead of FPC generating bitcode and the LLVM tool
chain reading it back in), so especially while developing it may be more
interesting to use our code generators
Jonas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
