[Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-03-11 09:46 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-03-11 09:37 ---
Subject: Bug 31358

Author: rguenth
Date: Tue Mar 11 09:36:51 2008
New Revision: 133102

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133102
Log:
2008-03-11  Andrew Pinski  <[EMAIL PROTECTED]>
Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/31358
* tree-ssa-loop-manip.c (create_iv): Call force_gimple_operand for
the step with a NULL_TREE.
* tree-ssa-loop-ivopts.c (find_bivs): Convert the step
to sizetype if type is a pointer type.
(add_candidate_1): Don't convert the base and step to
the generic type if the orginal type is a pointer type.
(add_iv_value_candidates): Use sizetype for the step
if type is a pointer type.
(cand_value_at): Likewise.
* tree-ssa-address.c (add_to_parts): Use POINTER_PLUS_EXPR
for pointer types.
* tree-affine.c (tree_to_aff_combination ):
Don't convert the tem affine to the type.
(add_elt_to_tree): Use sizetype for the step if a pointer.
Use POINTER_PLUS_EXPR for pointers.
(aff_combination_to_tree): Use sizetype for the step if a
pointer.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-affine.c
trunk/gcc/tree-ssa-loop-ivopts.c
trunk/gcc/tree-ssa-loop-manip.c


-- 


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

[Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-08-06 05:58 ---
Yes this does cause some of PR 28690.

Anyways, mine.
A patch for this was posted at 
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg6.html

I need to update it for the comments still.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||28690
  nThis||
 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-08-06 05:58:46
   date||


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

[Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-06-08 07:52 ---
(In reply to comment #1) 
> no, this is OK (whether it is a good design choice is another thing, I will
> think about that).

I actually have a fix for this issue (the MEM with just index: and offset:) but
it is going to wait until after the pointer_plus merge.


-- 


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

[Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-03-26 22:27 ---
3.2.3 produced:
.L6:
slwi 0,9,2
add 9,9,5
cmpw 0,9,4
stwx 11,3,0
bgelr- 0
b .L6

While 4.1.0 and above produces:
.L4:
add 9,9,5
stw 10,-4(3)
add 3,3,11
subf 0,5,9
cmpw 7,4,0
bgt 7,.L4


If we change "int *" to "char *" and set c to be 2, we get even worse code gen.
3.2.3:

.L9:
stbx 11,3,9
addi 9,9,2
bdnz .L9
blr


4.1.0:
.L4:
add 9,3,11
addi 11,11,2
cmpw 7,4,11
stb 0,-1(9)
bgt 7,.L4

What happened to bdnz and we are now doing *(r9+r3-1) = r0 inside the loop?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.1.0 4.2.0 4.3.0


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

[Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-03-26 17:35 ---
Even if this MEM is ok, we still get bad results as we have *(a+b-4) inside the
loop now.


-- 


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

[Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF

[rakdver at gcc dot gnu dot org]

--- Comment #1 from rakdver at gcc dot gnu dot org  2007-03-26 10:17 ---
(In reply to comment #0)
> For:
> int *f(int *a, int b, int c)
> {
>   int i;
>   a --;
>   *a = 1;
>   for (i = 0;i (a[i]) = 0;
>   return a;
> }
> CUT
> I get in the final_cleanup:
>   MEM[index: ivtmp.35, offset: 4294967292] = 0;
> 
> 
> And I noticed that ivtmp.29 is of type "long unsigned int" which seems wrong 
> as
> it is actually the pointer.

no, this is OK (whether it is a good design choice is another thing, I will
think about that).


-- 


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