On Thu, 22 Jan 2015, Richard Henderson wrote: > On 01/21/2015 11:52 PM, Richard Biener wrote: > > On January 21, 2015 10:23:56 PM CET, Richard Henderson <r...@redhat.com> > > wrote: > >> 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. > > > > I was asking for the generic expander to consider bswapHI. Rotates are > > certainly more likely to get combined with sth else.
Sorry for being GIMPLE centric here - but I meant canonicalization on GIMPLE. For RTL the expander will hopefully canonicalize it to whatever is canonical on RTL. > Maybe. Alternately, don't we canonicalize byte-swapping memory ops as > > (set (reg:HI) (bswap:HI (mem:HI))) > > (set (mem:HI) (bswap:HI (reg:HI))) > > Certainly this is true for powerpc. > > (It appears that both sparc and s390 are missing similar patterns, > despite having instructions that can perform this operation...) That makes sense, it looks easier to match than a form with rotates. I wonder when CPUs start to make a load-with-byte-shuffle instruction available... Richard.