Re: Testers needed for GCC patch

[David Edelsohn <dje%watson.ibm.com@localhost>]

        The definition of SLOW_UNALIGNED_ACCESS is correct for the
definition of preferred load/store alignment in the PowerPC architecture
document.  If you are suggesting that the alignment values used as
arguments to the macro are too optimistic, that very well may be the case.
In functions such as expr.c:store_field(), expmed.c:store_bit_field(), and
expmed.c:extract_bit_field(), some of the alignment values probably do not
take all of the alignment issues into account.

        One probably wants to use a computation along the lines of:

abs (align - ((bitpos % GET_MODE_ALIGNMENT(mode)) / BITS_PER_UNIT))

for the alignment to test, where GET_MODE_ALIGNMENT(mode) might also be
TYPE_ALIGN (TREE_TYPE (exp)) in some cases.

        Currently SLOW_UNALIGNED_ACCESS only tests the alignment of the
parent object in those cases.  The alignment requirements of the holder
often are dictated by the alignment of the interior objects.  For AIX and
its PowerOpen ABI, the simple test gets the right result; maybe 32-bit
PowerPC SVR4/ELF needs more detail.  If you would investigate something
like the proposal above for the "align" argument of SLOW_UNALIGNED_ACCESS
in fragments like:

      /* If the field isn't aligned enough to store as an ordinary memref,
         store it as a bit field.  */
      || (mode != BLKmode && SLOW_UNALIGNED_ACCESS (mode, align)
          && (align * BITS_PER_UNIT < GET_MODE_ALIGNMENT (mode)
              || bitpos % GET_MODE_ALIGNMENT (mode)))
      || (mode == BLKmode && SLOW_UNALIGNED_ACCESS (mode, align)
          && (TYPE_ALIGN (TREE_TYPE (exp)) > align * BITS_PER_UNIT
              || bitpos % TYPE_ALIGN (TREE_TYPE (exp)) != 0))

and let me know what you find as the appropriate expression, I would be
happy to improve this area.  I think that this is area is more likely to
be the culprit for the alignment traps that you continue to observe.

Thanks, David

        P.S. Re-opening a conversation with comments like "They don't
work" and "I am sorry for wanting gcc to not have these problems" are not
very productive and do not encourage cooperation.
===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje%watson.ibm.com@localhost                                  P.O. Box 218
+1 914 945 4364 (TL 862)                            Yorktown Heights, NY 10598