https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #15 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to thopre01 from comment #14)
>
> It's rather the contrary. The bswap pass will replace the statements by a 8
> bit rotation if the value is 16bit and the expander will choose a bswaphi
> pattern for that if the backend has one, otherwise it will keep the rotation.
>
> The problem is that currently the bswap pass still bails out if there is no
> 16 bit bswap available. I shall fix that.
Ah, I see.
> You mean with the added bswaphi2 pattern the pattern is still unchanged?
>
After adding bswaphi2, the bswap pass does the transformation. Except for the
non-working 'signed short' mentioned above. But we already figured that out
earlier.
> > On SH the bswap:HI HW insn actually doesn't modify the upper 16 bit of the
> > 32 bit register. What it does is:
> >
> > unsigned int test_0999 (unsigned int a, unsigned int b)
> > {
> > return (a & 0xFFFF0000) | ((a & 0xFF00) >> 8) | ((a & 0xFF) << 8);
> > }
> >
> > I was afraid that using a bswap:HI will result in unnecessary code around
> > it:
> >
> >
> > mov.l .L6,r0 ! r0 = 0xFFFF0000
> > and r4,r0
> > extu.w r4,r4
> > swap.b r4,r4
> > rts
> > or r4,r0
>
> Looks good to me, what exactly is the problem?
The expected sequence for the function above is:
rts
swap.b r4,r0
i.e. no anding and oring of lower/higher 16 bit word, since the swap.b insn
operates on a SImode value and does not alter the high 16 bits.
>
> If you have a bswap instruction it seems better to define a pattern for that
> which the expander will use. That's the job of the bswap pass to detect a
> bswap, it shouldn't be done by combine.
The combine parts I was talking about are to eliminate the anding and oring of
higher 16 bits when a 16 bit byte swap is done on a 32 bit value.
>
> Ok so the limit ought to be increased and the check for bswaphi removed.
> I'll take a stab at that but that will probably make it only after Christmas.
No problem.
