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