On 01.03.2013 10:23, Mark Morgan Lloyd wrote:
Sven Barth wrote:
An llvm target will move the optimisation burden away from fpc, which
would be very interesting.
While we would welcome a LLVM backend it is basically a consent in the
development team that this would only be an additional alternative to
the normal backends FPC provides.
LLVM's target list doesn't look particularly brilliant compared with
FPC's :-/
Yes, that's another reason why we wouldn't use it as default :)
Are there any practical advantages to having both? Could inspecting LLVM
output help in getting a native code generator off the ground, or does
it output enough debugging info to suggest novel optimisations?
The point is: if we introduce a LLVM backend then why not use it for the
LLVM supported targets as well. The current (as in "in the last few
weeks") driving point for a LLVM backend is the possiblity to use
Emscripten to convert the generated LLVM code to JavaScript and run the
resulting executable in a browser.
Also if we have a backend independant of FPC we could check whether only
our backend optimizations are bad (LLVM can generate very optimized
target assembler code) or whether we should improve our frontend
optimizations (those that are done on the Abstract Syntax Tree). So the
introduction of LLVM could be seen as a step closer to better optimized
code.
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
