[Bug tree-optimization/33404] Predictive commoning + ivopts possibly introducing extra sign extensions.

[ramana at gcc dot gnu dot org]

--- Comment #5 from ramana at gcc dot gnu dot org  2009-05-13 14:33 ---
(In reply to comment #4)
 (In reply to comment #3)
  (In reply to comment #2)
   Also IV-opts is messing up anyways, it should have done out+1 as the base
   instead of out, blah.
  
  Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36905 .
 
 Can we close this bug, then, or is there some other problem reported in this
 testcase?  As far as I can tell, predictive commoning does not introduce any
 new sign extensions (it does not eliminate any, either, but that is not its
 job).
 

I am closing this because the problem is not in predictive commoning which is
doing the right thing and the problem is as per PR36905.


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33404

[Bug tree-optimization/33404] Predictive commoning + ivopts possibly introducing extra sign extensions.

[rakdver at gcc dot gnu dot org]

--- Comment #4 from rakdver at gcc dot gnu dot org  2008-07-25 07:56 ---
(In reply to comment #3)
 (In reply to comment #2)
  Also IV-opts is messing up anyways, it should have done out+1 as the base
  instead of out, blah.
 
 Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36905 .

Can we close this bug, then, or is there some other problem reported in this
testcase?  As far as I can tell, predictive commoning does not introduce any
new sign extensions (it does not eliminate any, either, but that is not its
job).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33404

[Bug tree-optimization/33404] Predictive commoning + ivopts possibly introducing extra sign extensions.

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-23 01:55 ---
Hmm, I think the sign/zero extension is needed.
Even doing:
void fred(unsigned short in, unsigned short *out1)
{
int i;
for (i=0;i100;i++)
out1[i+1] = out1[i]*in;
}
--- CUT ---
We will get a zero extension in the assembly (on Powerpc-linux-gnu).
.L2:
add 9,4,11
addi 11,11,2
mullw 0,3,0
sth 0,2(9)
rldicl 0,0,0,48
bdnz .L2
--- CUT ---
But it is needed.  If we look at -O2 case:
.L2:
lhz 0,0(4)
mullw 0,3,0
sthu 0,2(4)
bdnz .L2
You will see that we load the code as zero extended.

Also I get:
bb 3:
  D.1263 = (short unsigned int) D__lsm0.41 * pretmp.27;
  D__lsm0.41 = (short int) D.1263;
  MEM[base: out1 + ivtmp.49, offset: 2] = D__lsm0.41;
  ivtmp.49 = ivtmp.49 + 2;
  if (ivtmp.49 != 200)

for the loop on the trunk.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33404

[Bug tree-optimization/33404] Predictive commoning + ivopts possibly introducing extra sign extensions.

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-07-23 02:01 ---
for the loop on the trunk.

I think the trunk improved fold somewhere along the way, because the 4.3 I have
from January has the extra sign extension.

We will get a zero extension in the assembly (on Powerpc-linux-gnu).

Also IV-opts is messing up anyways, it should have done out+1 as the base
instead of out, blah.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||missed-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33404

[Bug tree-optimization/33404] Predictive commoning + ivopts possibly introducing extra sign extensions.

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-07-23 02:10 ---
(In reply to comment #2)
 Also IV-opts is messing up anyways, it should have done out+1 as the base
 instead of out, blah.

Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36905 .


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33404