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

[Thomas Preudhomme <thomas dot preudhomme at foss dot arm dot com>]

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.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?

Bootstrap for C, C++ and fortran succeeded.

Best regards,

Thomas