On Fri, 11 Nov 2016, Thomas Preudhomme wrote: > Hi, > > To fix PR69714, code was added to disable bswap when the resulting symbolic > expression (a load or load + byte swap) is smaller than the source expression > (eg. some of the bytes accessed in the source code gets bitwise ANDed with 0). > As explained in [1], there was already two pieces of code written > independently in bswap to deal with that case and that's the interaction of > the two that caused the bug. > > [1] https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00948.html > > PR69714 proves that this pattern do occur in real code so this patch set out > to reenable the optimization and remove the big endian adjustment in > bswap_replace: the change in find_bswap_or_nop ensures that either we cancel > the optimization or we don't and there is no need for offset adjustement. As > explained in [2], the current code only support loss of bytes at the highest > addresses because there is no code to adjust the address of the load. However, > for little and big endian targets the bytes at highest address translate into > different byte significance in the result. This patch first separate cmpxchg > and cmpnop adjustement into 2 steps and then deal with endianness correctly > for the second step. > > [2] https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00119.html > > Ideally we would want to still be able to do the adjustment to deal with load > or load+bswap at an offset from the byte at lowest memory address accessed but > this would require more code to recognize it properly for both little endian > and big endian and will thus have to wait GCC 8 stage 1. > > ChangeLog entry is as follows: > > *** gcc/ChangeLog *** > > 2016-11-10 Thomas Preud'homme <thomas.preudho...@arm.com> > > * tree-ssa-math-opts.c (find_bswap_or_nop): Zero out bytes in cmpxchg > and cmpnop in two steps: first the ones not accessed in original > gimple > expression in a endian independent way and then the ones not accessed > in the final result in an endian-specific way. > (bswap_replace): Stop doing big endian adjustment. > > > Testsuite does not show any regression on an armeb-none-eabi GCC > cross-compiler targeting ARM Cortex-M3 and on an x86_64-linux-gnu bootstrapped > native GCC compiler. Bootstrap on powerpc in progress. > > Is this ok for trunk provided that the powerpc bootstrap succeeds?
Ok. Thanks, Richard.
