RFC: Removing ABIArgInfo::Expand from Clang ABI lowering

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Removing ABIArgInfo::Expand from Clang ABI lowering

John McCall
Hey, all.  I’d like to remove ABIArgInfo::Expand from Clang’s function lowering logic.  It is essentially ABIArgInfo::Direct except (1) it is less flexible about the actual types to coerce to and (2) it requires some awkward redundant code to do recursive walks through types.  The redundancy can be fixed, but I’d rather just remove the code completely.

In principle, Expand can be used to expand structures with internal padding, but in practice nobody seems to be using it that way, probably because structures like that tend to be passed on the stack or need some other careful handling.

I’ve looked at our currently-supported in-tree uses of Expand, and I feel confident that they can all be easily switched to Direct.  However, I am willing to maintain Expand if anyone is maintaining an out-of-tree target and cannot simply switch to Direct, or if anyone has some other compelling reason Expand needs to stay.  Otherwise, I’ll be removing it relatively soon.

John.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Removing ABIArgInfo::Expand from Clang ABI lowering

Tim Northover-2
Hi John,

On 3 February 2015 at 21:40, John McCall <[hidden email]> wrote:
> I’ve looked at our currently-supported in-tree uses of Expand, and I feel confident
> that they can all be easily switched to Direct.  However, I am willing to maintain
> Expand if anyone is maintaining an out-of-tree target and cannot simply switch to
> Direct, or if anyone has some other compelling reason Expand needs to stay.
> Otherwise, I’ll be removing it relatively soon.

I think removing it is a good idea too (assuming no OOT user has a
compelling scenario).

By default a struct coercion gets expanded to something equivalent
before lib/Target in the backend sees it anyway (modulo possible weird
union behaviour, which would almost certainly be unintended).

Cheers.

Tim.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev