> -----Original Message-----
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Thursday, January 22, 2015 5:24 AM
> To: Thomas Preud'homme; gcc-patches@gcc.gnu.org; 'Richard Biener'
> Subject: Re: [PATCH] Don't check for optab for 16bit bswap
>
> On 12/29/2014 06:04 AM, Thomas Preud'homme wrote:
> > Since 16bit byteswap can be done via an 8 bit rotation (and it is the
> canonical form),
> > the check for an optab only serves to prevent the bswap optimization
> for
> > targets that don't have a 16bit byteswap (but do have a rotation
> instruction). See
> > PR63259 (comments 6 and onwards) for more details.
>
> I question the choice to have rotate be the canonical form.
>
> Doesn't this make things more complicated for targets that
> don't have rotate? Or, equivalently, no 16-bit rotate?
> That would seem to cover 99% of all 32-bit risc machines.
Here is the difference between the two (see [1]):
/* Rotation of 16bit values by 8 bits is effectively equivalent to a bswaphi.
Note that this is not the case for bigger values. For instance a rotation
of 0x01020304 by 16 bits gives 0x03040102 which is different from
0x04030201 (bswapsi). */
if (rotate
&& CONST_INT_P (op1)
&& INTVAL (op1) == BITS_PER_UNIT
&& GET_MODE_SIZE (scalar_mode) == 2
&& optab_handler (bswap_optab, HImode) != CODE_FOR_nothing)
return expand_unop (HImode, bswap_optab, shifted, NULL_RTX,
unsignedp);
[1]
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/expmed.c?revision=219718&view=markup#l2208
It doesn't look much more complicated. There was also some change in
the bswap pass but some code was both added and removed. As to the
bug raised by H.J. Lu, I just wrote a patch and testing is underway.
Given this, I don't think it's a problem. That being said, I'm happy to
change the canonical representation if there is consensus for that.
Best regards,
Thomas
