This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/63259] Detecting byteswap sequence
- From: "thopre01 at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 19 Dec 2014 14:40:59 +0000
- Subject: [Bug rtl-optimization/63259] Detecting byteswap sequence
- Auto-submitted: auto-generated
- References: <bug-63259-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #16 from thopre01 at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #15)
> (In reply to thopre01 from comment #14)
>
> > 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.
Did we? All I can find is you and Andreas mentionning that it should work
because it will be sign extended to int when doing the bitwise AND with 0xFF00.
What did I miss?
>
> 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.
Oh yeah right.
>
> >
> > 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.
I'm surprised that it's not the semantic of a bswaphi.
Best regards,
Thomas