llvm dev - Jul 2007 - [LLVMdev] How to access llvm Types from the codegen?

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

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.

Evan

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

On 27/07/07, Evan Cheng <evan.cheng at apple.com>
wrote:
> 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.
>
> Evan
Sorry for the delay. I am back from a vacation and have been busy
catching up....

That is why I need the types (just for the size). This is necessary to
implement both the current behavior and the correct ABI.

consider the llvm code
---------------------------------------
%struct.s = type { i64 }

define i64 @f(%struct.s* byval %a) {
entry:
        %tmp2 = getelementptr %struct.s* %a, i32 0, i32 0
 ; <i64*> [#uses=1]
        %tmp3 = load i64* %tmp2         ; <i64> [#uses=1]
        ret i64 %tmp3
---------------------------------------

When the DAG is constructed it will contain a load from formal_args.
It looks like a lot of work to modify the DAG so that instead it uses
a copy. Even if we decide to do this, we would need to pass the size
of the structure to the DAG, which currently is not available.

I propose that structures that are passed on registers should be slip
into many DAG level arguments (for now this would be all structs) and
the DAG should contain copies instead of loads. The nice thing about
this proposal is that for structures that are passed on the stack, the
DAG doesn't need to know the size. All that we need to add to add to
the DAG is a flag so that the code generators know that the struct
pointer should be computed based on the stack pointer.

Thoughts?

Thanks,
--
Rafael Avila de Espindola

Google Ireland Ltd.
Gordon House
Barrow Street
Dublin 4
Ireland

Registered in Dublin, Ireland
Registration Number: 368047