This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, rs6000] Fix aggregate alignment ABI issue
- From: Eric Christopher <echristo at gmail dot com>
- To: David Edelsohn <dje dot gcc at gmail dot com>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, Mike Stump <mikestump at comcast dot net>, Dominique Dhumieres <dominiq at lps dot ens dot fr>, Jack Howarth <howarth at bromo dot med dot uc dot edu>, GCC Patches <gcc-patches at gcc dot gnu dot org>, "William J. Schmidt" <wschmidt at linux dot vnet dot ibm dot com>
- Date: Wed, 9 Jul 2014 11:29:46 -0700
- Subject: Re: [PATCH, rs6000] Fix aggregate alignment ABI issue
- Authentication-results: sourceware.org; auth=none
- References: <201407091604 dot s69G4qnj020440 at d06av02 dot portsmouth dot uk dot ibm dot com> <CAGWvnykpMBFRs_vy6MhujPmebAyg_kdiWKt-gQ8ywCxqLkyz3Q at mail dot gmail dot com>
On Wed, Jul 9, 2014 at 11:25 AM, David Edelsohn <email@example.com> wrote:
> On Wed, Jul 9, 2014 at 12:04 PM, Ulrich Weigand <firstname.lastname@example.org> wrote:
>> last year, Bill added a patch to address PR 57949 by aligning aggregates
>> requiring at least 128-bit alignment at a quadword boundary in the
>> parameter save area:
>> Unfortunately, to implement this check, Bill's patch used a pre-existing
>> piece of code originally used only on Darwin, which uses a "mode == BLKmode"
>> check to test for aggregate types.
>> However, GCC may sometimes choose non-BLKmode modes to represent aggregate
>> types. One case the single-element float/vector aggregates; that's OK,
>> because those are handled separately by the ABI anyway.
>> But there are more cases: many structures get some integer mode simply
>> because their size happen to be 1, 2, 4, 8, or 16 bytes. The precise
>> rules *which* aggregates GCC uses such a mode for are intricate, and
>> even differ slightly between types created by the C vs. C++ front-ends.
>> This normally doesn't matter since the mode used to back an aggregate
>> type only matters for internal code generation (basically, whether GCC
>> may use a register to hold a local variable of that type, or whether
>> they must all go to memory).
>> Due to this check in rs6000_function_arg_boundary, however, those GCC
>> internal details have now leaked into the public ABI. We have thought
>> of simply accepting that ABI as the de-facto ABI now and documenting
>> it, but that turned out to be too fragile; it is hard to precisely
>> describe the mode selection in a way that it can be reliably implemented
>> by another (non-GCC based) compiler.
>> After various off-line discussions, we came to the conclusion that the
>> best way is to fix the GCC implementation to actually align *all* aggregate
>> types, not just those backed by BLKmode. [ The exception remain single-
>> element (or ELFv2 homogeneous) float/vector aggregates, which are handled
>> as before: float is doubleword aligned, vector is quadword aligned. ]
>> This change does break the ABI in certain cases. However, we hope that
>> this is acceptable because:
>> - The change only affects rare cases: passing a struct by value that is
>> * not a float/vector special case, and
>> * has a size of 1, 2, 4, 8, or 16 bytes, and
>> * has an alignment requirement of 16 bytes or more
>> [ Not *all* these cases will see change, but all cases that change
>> will share these properties. ]
>> - This aspect of the ABI already changed recently with Bill's patch,
>> and the current version hasn't seen very widespread use yet.
>> Note that patch below only changes the ABI for the AIX/ELFv1 and ELFv2
>> cases; the Darwin ABI (which shared the same problem) is left as-is.
>> It's up to the Darwin maintainers whether they prefer to change as well
>> or rather keep everything as it has been on Darwin for a long time.
>> Tested on powerpc64-linux and powerpc64le-linux.
>> OK for mainline?
>> [ The patch should then also go into the 4.8 and 4.9 branches for
>> consistency. ]
>> * config/rs6000/rs6000.c (rs6000_function_arg_boundary): In the AIX
>> and ELFv2 ABI, do not use the "mode == BLKmode" check to test for
>> aggregate types. Instead, *all* aggregate types, except for single-
>> element or homogeneous float/vector aggregates, are quadword-aligned
>> if required by their type alignment.
> I copied the Darwin maintainers and active testers so that they are
> explicitly aware of the ABI issue. They can decide if they want to fix
> the ABI alignment issue on Darwin.
Thanks David, In general I'd personally prefer to fix the ABI issues,
but PPC darwin is beyond EoL by the original company and I don't have
any hardware for it myself - in which case I'll leave it up to our
more active testers or someone with hardware. (Mike? Have old ppc
hardware sitting around?)