llvm dev - Feb 2013 - [LLVMdev] Argument Lowering

Tim Northover <t.p.northover at gmail.com> writes:
>> Can anyone explain why LLVM can't do it?  I've read vague hints
of, "not
>> all the information is there," but I'd really like to
understand this
>> better.
>
> The most compelling example I've heard is the x86_64 ABI. It refers to
> POD types, unions and structs with non-aligned fields.
>
> I think POD is a red herring because Clang would have to deal with
> that anyway and the solution is essentially a byval pointer. Even the
> non-aligned fields thing looks similar: any struct with such gets
> passed in MEMORY, so a simple front-end test and a byval pointer
> should work.
This makes sense to me.  These kinds of things are special cases and I
think that's ok to leave to the language expert (the frontend).
> Unions are a much bigger problem. I can't see how a front-end could
> decide how to pass them without implementing the given rules itself
> (some unions have to have SSE type, some INTEGER, ...). At that stage
> you've got quite large duplication between front-end and back-end
> anyway. Probably more than is required by the current register
> counting front-ends.
Hmm.  Yes, unions are a problem and it seems like the frontend would
have to handle these.  At the very least it has to pick a type to
represent each of the overlapping regions.  Dang, I'll have to think
on this more.  :)
> At a purely implementation level, the first problem at the moment is
> that IR-level types are discarded by the time call lowering happens.
> Structures are split up into their constituent fields and those are
> all a backend has available for its decisions.
When you say, "Structures are split up into their constituent fields,"
what do you mean, exactly?
> But, because of the above concerns, the only properly viable solution
> would probably be to reintroduce union types to LLVM IR. Which is more
> complexity for optimisations to handle. I understand they never really
> worked properly in the first place.
Yeah, I don't think that's an option.

I ask because I just spent several days diagnosing an ABI problem here.
It struck me that a lot of time probably gets wasted fixing these kinds
of bugs over and over again.

                            -David

>> At a purely implementation level, the first problem at the moment is
>> that IR-level types are discarded by the time call lowering happens.
>> Structures are split up into their constituent fields and those are
>> all a backend has available for its decisions.
>
> When you say, "Structures are split up into their constituent
fields,"
> what do you mean, exactly?
By the time the backend gets to decide where arguments are going,
instead of seeing a prototype like

declare @foo({i32, i8, i64} %arg)

it gets presented with (essentially)

declare @foo(i32 %arg.1, i8 %arg.2, i64 %arg.3)

There's no hint that a structure was ever involved, let alone
information on its layout. I think that would be a fairly simple
matter to resolve though, if a little risky if not handled carefully.

Tim.

Tim Northover <t.p.northover at gmail.com> writes:
>>> At a purely implementation level, the first problem at the moment
is
>>> that IR-level types are discarded by the time call lowering
happens.
>>> Structures are split up into their constituent fields and those are
>>> all a backend has available for its decisions.
>>
>> When you say, "Structures are split up into their constituent
fields,"
>> what do you mean, exactly?
>
> By the time the backend gets to decide where arguments are going,
> instead of seeing a prototype like
>
> declare @foo({i32, i8, i64} %arg)
>
> it gets presented with (essentially)
>
> declare @foo(i32 %arg.1, i8 %arg.2, i64 %arg.3)
Ok, that's what I thought you meant, but wanted to make sure.
> There's no hint that a structure was ever involved, let alone
> information on its layout. I think that would be a fairly simple
> matter to resolve though, if a little risky if not handled carefully.
It's this loss of information I was hoping to avoid by passing the
structs and having CodeGen lower the passing correctly.  But unions are
a problem.

Damnable unions.

                        -David