[PATCH, GCC] Recognize partial load of source expression on big endian targets

[Richard Biener]

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.preudhomme@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.