https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #21 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Tue Jan 6 11:51:16 2015
New Revision: 219256
URL: https://gcc.gnu.org/viewcvs?rev=219256&root=gcc&view=rev
Log:
2015-01-06 Thomas Preud'homme
gcc/
PR tree-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #20 from Oleg Endo ---
BTW, PR 42587 contains a few other cases. I've created PR 64376 for the SH
specific parts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #19 from thopre01 at gcc dot gnu.org ---
Yeah, when doing something like (x[0] << 8) | x[1]) << 8) | x[2]) << 8) |
x[3] there is already a depth proportional to the size of the value being byte
swapped with a coefficient due to cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #18 from Oleg Endo ---
(In reply to Oleg Endo from comment #17)
> (In reply to thopre01 from comment #16)
> >
> > Did we? All I can find is you and Andreas mentionning that it should work
> > because it will be sign extended to int w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #17 from Oleg Endo ---
(In reply to thopre01 from comment #16)
>
> 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.
>
> Wha
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #15 from Oleg Endo ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #14 from thopre01 at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #13)
> (In reply to thopre01 from comment #12)
> >
> > That's good, it means the pattern is recognized. Is there an optab defined
> > for bswap16?
>
> Nope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #13 from Oleg Endo ---
(In reply to thopre01 from comment #12)
>
> That's good, it means the pattern is recognized. Is there an optab defined
> for bswap16?
Nope. Just this:
(define_insn "rotlhi3_8"
[(set (match_operand:HI 0 "ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #12 from thopre01 at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #11)
> (In reply to thopre01 from comment #10)
> >
> > I have the same gimple and for me the bswap is correctly detected. Can you
> > break at find_bswap_or_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #11 from Oleg Endo ---
(In reply to thopre01 from comment #10)
>
> I have the same gimple and for me the bswap is correctly detected. Can you
> break at find_bswap_or_nop just after calling find_bswap_or_nop_1 on the if
> (!source_st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #10 from thopre01 at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #9)
> (In reply to thopre01 from comment #7)
> >
> > Strange, could you show the output of -fdump-tree-bswap?
>
> Not so strange at all.
What is strange i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #9 from Oleg Endo ---
(In reply to thopre01 from comment #7)
> (In reply to Oleg Endo from comment #6)
> > With r218705 on SH (-O2 -m4 -ml) I get the following:
> >
> > unsigned short test_099 (unsigned short a, unsigned short b)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #8 from Andreas Schwab ---
(a & 0xFF00) >> 8 with short a = 0x8001 evaluates to 0x80, since all operands
are first promoted to int.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #7 from thopre01 at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #6)
> With r218705 on SH (-O2 -m4 -ml) I get the following:
>
> unsigned short test_099 (unsigned short a, unsigned short b)
> {
> return (((a & 0xFF00) >>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #6 from Oleg Endo ---
With r218705 on SH (-O2 -m4 -ml) I get the following:
unsigned short test_099 (unsigned short a, unsigned short b)
{
return (((a & 0xFF00) >> 8) | ((a & 0xFF) << 8));
}
compiles to:
extu.wr4,r4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #5 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Fri Oct 31 11:55:07 2014
New Revision: 216971
URL: https://gcc.gnu.org/viewcvs?rev=216971&root=gcc&view=rev
Log:
2014-10-31 Thomas Preud'homme
gcc/
PR tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #4 from thopre01 at gcc dot gnu.org ---
I detect no noticeable difference when bootstrapping gcc with or without the
patch so I think we're in for a fix. :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
thopre01 at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
Hans-Peter Nilsson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
21 matches
Mail list logo
