http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ebotcazou at gcc dot gnu.org
--- Comment #22 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> After thinking it over some more, I think you are right, Martin. We should
> go ahead with the optimization with the corrected alignment attached to the
> type. Please go ahead with your patch. I will run a round of regression
> testing on PowerPC (an architecture for which the generic test produces
> misaligned but legal memory references) as well.
>
> Sorry for going back and forth on this. I try to avoid wasting compile time
> on useless transformations, but in this case we will still see some benefit
> in some cases, and the code should be no worse than before when we don't.
We should be very wary of generating unaligned accesses during optimization for
targets that define SLOW_UNALIGNED_ACCESS. And note that most architectures
supported by GCC are STRICT_ALIGNMENT, not the other way around, so it's the
common case.
