[LLVMdev] How to access llvm Types from the codegen?

Evan Cheng evan.cheng at apple.com
Thu Jul 26 16:10:29 PDT 2007

Code generator shouldn't introspect the LLVM type at all, except to  
get the size of the type.  Anything needed should be encoded by the  
front-end.  In the short term, please focus on getting parity with  
what we already have.  This means x86-64 will be wrong, but it  
already is.  As a second step we can then worry about x86-64-specific  
param attributes that should be added to handle this stuff correctly.


On Jul 18, 2007, at 10:01 AM, Rafael Espindola wrote:

> In order to the code generators to lower functions arguments that have
> the "byval" attribute, they would have to access the original argument
> Type. For example, on linux x86_64 {i64, i64} should be passed on
> registers and {i64, i64, i64} goes on the stack.
> The problem is that when looking at (for example) FORMAL_ARGUMENTS,
> the only thing that is present is the type of the pointer itself (i64
> for example).
> I can see three options to solve the problem:
> 1) Make FORMAL_ARGUMENTS have one SrcValueSDNode per argument in
> addition to the flags and make CALL use SrcValueSDNode for the
> arguments. The calling convention functions (CC_X86_64_C) can then be
> modified to take a Type as an additional argument.
> 2) Implement part of the ABI on the DAG construction. In this approach
> a struct that should be passed on registers would result on a series
> of arguments at the DAG level, similar to what is done by llvm-gcc
> today, but one lever lower (llvm -> DAG instead of C -> llvm).
> Arguments that should go on the stack result in an argument tagged as
> a implicit pointer that the code generators can compute as an offset
> from the frame pointer. In order to find the offset only the size of
> the struct has to be added to the DAG somehow.
> 3) Similar to 2, but, for arguments that should go on registers, let
> llvm-gcc do the splitting. In this approach the "byval" argument would
> be a much simpler extension. It would mean: this pointer is to be
> computed as an offset from the frame pointer.
> In order to implement options 2 or 3 we have to add the structure size
> to the DAG somehow. Suggestions?
> I prefer option 3, but I would like to know the opinion from other  
> developers.
> Thanks,
> -- 
> Rafael Avila de Espindola
> Google Ireland Ltd.
> Gordon House
> Barrow Street
> Dublin 4
> Ireland
> Registered in Dublin, Ireland
> Registration Number: 368047
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list