On Wed, Jul 9, 2014 at 11:25 AM, David Edelsohn <dje....@gmail.com> wrote: > On Wed, Jul 9, 2014 at 12:04 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote: >> Hello, >> >> 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: >> https://gcc.gnu.org/ml/gcc-patches/2013-08/msg00803.html >> >> 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. ] >> >> Bye, >> Ulrich >> >> >> ChangeLog: >> >> * 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. > > Okay. > > 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?) -eric
