On Fri, Jan 03, 2014 at 05:04:39PM +0100, Uros Bizjak wrote:
> On a second thought, the crossing of 16-byte boundaries is mentioned
> for the data *access* (the instruction itself) if it is not naturally
> aligned (please see example 3-40 and fig 3-2), which is *NOT* in our
> case.
>
> So, we don't have to align 32 byte structures in any way for newer
> processors, since this optimization applies to 64+ byte (larger or
> equal to cache line size) structures only. Older processors are
> handled correctly, modulo nocona, where its cache line size value has
> to be corrected.
>
> Following that, my original patch implements this optimization in the
> correct way.
Sorry for catching this late, but on the 4.8 and earlier branches
there is no opt argument and thus any ix86_data_alignment change is
unfortunately an ABI change. So I'd think we should revert
r206433 and r206436. And for the trunk we need to ensure even for
opt we never return a smaller number from ix86_data_alignment than
we did in 4.8 and earlier, because otherwise if you have 4.8 compiled
code that assumes the alignment 4.8 would use for something that is defined
in a compilation unit built by gcc 4.9+, if we don't align it at least
as much as we did in the past, the linked mix of 4.8 user and 4.9 definition
could misbehave.
Jakub
