[LLVMdev] libc dependencies, code generation questions

[Chris Lattner]

On Thu, 7 Jun 2007, Jonas Maebe wrote:
> I'm looking into creating an llvm backend for the Free Pascal
> Compiler (<http://www.freepascal.org>). After reading a bit through
> the documentation and looking at some code generated by llvm-gcc, I
> have a couple of questions:

Cool, I'll add a couple comments, others have covered most of your 
questions.

> 2) I assume llvm sometimes adds implicit calls to functions in the C

LLVM doesn't do this unless you ask for it.  However, it does produce 
calls to functions in libgcc.  For example, if your cpu doesn't support 
64-bit division, the code generator emits a call to __udivdi (or something 
like that).  At some point, LLVM may have its own codegen library, but 
none is planned and libgcc works fine.

> 3) we support inline assembler in the same way that Turbo Pascal and
> Delphi did: you just type in code without telling the compiler what
> registers or memory locations this routine clobbers, and the compiler
> thus cannot make any assumptions about them (other than what the ABI/
> calling convention specifies). As far as llvm is concerned, they
> should be semantically equivalent to calling an external routine
> which was not compiled to llvm ir. Is there generic a way to tell
> this to llvm, or should one simply specify all volatile registers as
> read and clobbered, and the same for memory?

No, this is purely a front-end issue.  LLVM supports the semantic 
equivalent of GCC-style inline assembly, where you have to tell the code 
generator about register constraints etc.

If your front-end supports a different dialect of inline asm, it has to be 
smart enough to map it onto the LLVM style.  In particular, llvm-gcc 
contains code that maps "microsoft style" inline asm (which also doesn't 
have explicit register constraints) to the LLVM style.  This is enabled 
with -fasm-blocks.

> 4) to what extent is the front end (i.e., our compiler) responsible
> for code selection and optimization? In other words, should we spend
> a lot of time on converting if-statements to select-based predicates
> and things like this, or will this be done by llvm afterwards anyway?

You shouldn't have to do any of this stuff.

> What about vectorization?

LLVM doesn't currently support autovectorization, but it would make a lot 
more sense to implement this in LLVM than in your frontend.

> Are there particular kinds of optimizations which llvm will probably 
> never be very good at (or which are not llvm's focus in the near to 
> middle term), and which thus should definitely be done at a higher 
> level?

There is a class of very high-level optimizations that LLVM isn't 
currently very good at.  However, LLVM should be extended to handle these 
things.  I'd suggest keeping your front-end simple and letting the llvm 
optimizers grind on it.  If you see performance problems or optimizations 
missing, contact the list and we can find the best way to fix specific 
issues (be it in LLVM or in your front-end).

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/