[LLVMdev] struct passing on X86-64

[David A. Greene]

Nick Lewycky <nicholas at mxc.ca> writes:

> David A. Greene wrote:
>> 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.

Of course.

>   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.

Oh, absolutely the source language should be abstracted as much as
possible.  If we can represent C/C++ ABI requirements without talking
about char * and void *, I'm all for it!  I was responding to cases
where the LLVM type is not enough to distinguish between two or more
source language types that are handled differently by the ABI.  In those
cases the language/ABI requirements have to be conveyed somehow.  Maybe
it's metadata (or something equivalent) that specifies struct field
offsets, for example.

>>> 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.

Ok, yep.

> 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.

Sure.  I think everything you've said makes sense.  We're in violent
agreement.  :)

                               -Dave