[LLVMdev] struct passing on X86-64
nicholas at mxc.ca
Tue Jun 14 23:09:39 PDT 2011
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
> 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.
>> 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 *.
More information about the llvm-dev