[LLVMdev] Argument Lowering

dag at cray.com dag at cray.com
Tue Feb 12 09:24:07 PST 2013


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



More information about the llvm-dev mailing list