On Fri, Nov 07, 2014 at 12:54:44PM -0700, Jeff Law wrote:
> On 11/07/14 08:58, Thomas Preud'homme wrote:
> >Trunk revision 216971 introduced LROTATE_EXPR as the canonical
> >representation for a byte swap of a 2 bytes value, as per [1]. However,
> >backend expects bswaphi patterns for such operation as these operation are
> >more specific than a rotation. This led to a number of testcases starting to
> >fail such as gcc.target/arm/builtin-bswap16-1.c and
> >gcc.target/aarch64/builtin-bswap-2.c (these were skipped with my
> >configuration). This patch adds a check in expmed to expand such
> >LROTATE_EXPR into bswaphi pattern.
> >
> >[1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00616.html
> >
> >Note that this is unrelated to PR63761 (but I have diagnosed the root cause).
> >
> >ChangeLog entry is as follows:
> >
> >2014-11-03 Thomas Preud'homme <thomas.preudho...@arm.com>
> >
> > * expmed.c (expand_shift_1): Expand 8 bit rotate of 16 bit value to
> > bswaphi if available.
> Why restrict this to 8 bit rotate of a 16 bit value? Shouldn't it apply to
> a 16 bit rotate of a 32 bit value, or 32 bit rotate of 64 bit value?
That isn't a byteswap, but halfword swap or wordswap.
32 bit byteswap reverses 0x01020304 byte ordering into 0x04030201, while rotate
16 is 0x03040102.
Jakub
