[cfe-commits] Fix handling of ARM homogenous aggregates
Bob Wilson
bob.wilson at apple.com
Fri Mar 30 11:37:34 PDT 2012
On Mar 30, 2012, at 11:08 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote:
> Hi Bob
>
>> * Given that ABIArgInfo::Expand will only be used for unions that are homogeneous, does it really make sense to put code in CodeGenTypes::GetExpandedTypes and CodeGenFunction::ExpandTypeToArgs to search through members of a union to find the largest field? For the current usage, it should be sufficient to just grab the first one.
> No. Consider e.g.
>
> union {
> float bar[3];
> struct {
> float baz[4];
> };
> };
>
> Here we should select float[4] as proper h. aggregate.
You're right. I didn't think about that case.
>> * When I first implemented this, I intentionally limited it for C++ to aggregate-like types. Can you give an example of a non-aggregate-like C++ type that you think should be passed as a homogeneous aggregate? Certainly anything with a vtable pointer isn't going to work.
> Easily. Consider e.g.
>
> class Vector2 {
> float32x2_t vec;
> };
>
> Vector2 foo(const Vector2 &v) { return v; }
>
> Vector2 is not C++ aggregate, because it contains private fields.
> However, it's h. aggregate per ARM specs, because check for
> homogeneity should be performed w/o language-specific restrictions.
It seems that I misunderstood the meaning of the "isAggregate" method. I didn't realize that having private fields would cause that to return false. As long as you exclude classes with vtables, that should be fine.
More information about the cfe-commits
mailing list