[LLVMdev] struct passing on X86-64

[Nick Lewycky]

David A. Greene wrote:
> Nick Lewycky<nicholas at mxc.ca>  writes:
>
>> Why should the backends know about the frontend language? It seems
>> sensible to me that if I create a new language and a new ABI for my
>> language then I can expect to need to teach the backend about my new
>> ABI.
>
> And so the backend has to be taught about the language.

Only if that's what the ABI says. If my hypothetical ABI says that in a 
Z-context, the CR6 register controls whether floating point values are 
passed in registers or in memory, then the ABI-note says whether we're 
in a Z-context or not.

   To me, it is
> about conveying the necessary information in a more portable way so the
> mapping code only has to be written once.

Making which part portable? Your proposed solution is specific to C/C++ 
isn't it? I'd like LLVM to continue abstracting away the high-level 
language. We even added TBAA without baking in any frontend knowledge 
into LLVM, it's the frontend that defines the alias sets.

>> with only a few special cases. We could add ABI notes to the
>> llvm::Function which specify that parameter 3 is an arm-abi-name
>> "foo-style-passing", and the ARM backend would have to be taught how
>> to handle that. (It would also be nice if TargetData could tell you
>> whether a given ABI note applies to your current target.)
>
> How are those ABI notes different from source language information?

In every ABI I know of, that's what they'll be.

I guess what I'm objecting to is tying the ABI decision to a front-end 
language type system specifically. I also think that storing the ABI 
details as separate from the rest of the IR (ie., getting rid of 
"zeroext" -- just use the right (eg. i8) type please, and leave the fact 
it's passed in a 32-bit register to the ABI note) is a good idea in 
general. I meant to throw this out there and collect some feedback, not 
make a proposal to be implemented as-is.

Nick

>> That's orthogonal to the concern of PR4246 which talks about providing
>> a generic layer for lowering from the C type system to the ABI.
>
>> Does this sound like a sensible start?
>
> Comment 1 of PR4246 is something like what I was getting at.  What's not
> specified in the bug is how the type mapping is represented.  I'm with
> Eli in that it should be a dirt-simple structure to convey the necessary
> information.  Something that just says, for example, this use of i8 * is
> a char * and this other use of i8 * is a void *.
>
>                               -Dave
>