https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
Jiu Fu Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #15 from CVS Commits ---
The master branch has been updated by Jiu Fu Guo :
https://gcc.gnu.org/g:222f312a773157f53396ba4cb287deb07f84cc34
commit r11-4033-g222f312a773157f53396ba4cb287deb07f84cc34
Author: guojiufu
Date: Mon Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #13 from Li Jia He ---
In this optimization we assume n is either positive or divisible by the nth
power of 2.
So the result of the % is non-negative. However, it is not reasonable for
translating (a % 32)) to (a & 31). If a is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #12 from Segher Boessenkool ---
Sure, but what makes shift amount special here? This works just fine in
any other expression as well. That is, for unsigned n; for negative numbers
modulo works differently: it returns 0 or negative,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #11 from Li Jia He ---
The reason is that it is the remainder of the nth power of 2. In x >> (n% 32),
32 is the fifth power of 2. The hexadecimal representation of 32 is 0x100.
Taking the remainder of 0x100, the data range is 0 ～
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #10 from Segher Boessenkool ---
What makes shift amount special at all, for those gimple simplifications?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #9 from Li Jia He ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > (In reply to Andrew Pinski from comment #6)
> > > (In reply to Li Jia He from comment #5)
> > > > Could we consider
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > (In reply to Li Jia He from comment #5)
> > > Could we consider doing this optimization on gimple? I use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Li Jia He from comment #5)
> > Could we consider doing this optimization on gimple? I use the following
> > code on gimple to produce optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #6 from Andrew Pinski ---
(In reply to Li Jia He from comment #5)
> Could we consider doing this optimization on gimple? I use the following
> code on gimple to produce optimized results on powerpc64.
It might make sense. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
Li Jia He changed:
What|Removed |Added
CC||helijia at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #4 from Segher Boessenkool ---
Trunk does (both -m32 and -m64)
srawi 9,4,5
addze 9,9
slwi 9,9,5
subf 4,9,4
srw 3,3,4
and
rlwinm 4,4,0,27,31
srw 3,3,4
so the original problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #3 from Martin Sebor msebor at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #2)
I opened bug 66706.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
Segher Boessenkool segher at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
15 matches
Mail list logo
