On 11/11/16 14:45, 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?
Bootstrap for C, C++ and fortran succeeded. Best regards, Thomas
