[Bug tree-optimization/29751] not optimizing access a[0] , a[1]

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-25 
09:14:07 UTC ---
(In reply to comment #9)
 Created attachment 25847 [details]
 more correct patch
 
 An updated patch which is more correct than the previous patch and it works
 correctly with MEM_REF which has an offset.  Also moves some code to do
 addition of the bit offset to a function.
I just noticed it does not have the fix for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838 in it really.

Will retest and submit tomorrow.

[Bug tree-optimization/29751] not optimizing access a[0] , a[1]

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.6.0
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-25 
10:30:28 UTC ---
The original testcase is fixed during early FRE since we have MEM_REF, and
DCE makes main empty even in 4.7.

[Bug tree-optimization/29751] not optimizing access a[0] , a[1]

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #18307|0   |1
is obsolete||

--- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-17 
22:03:34 UTC ---
Created attachment 25847
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25847
more correct patch

An updated patch which is more correct than the previous patch and it works
correctly with MEM_REF which has an offset.  Also moves some code to do
addition of the bit offset to a function.

[Bug tree-optimization/29751] not optimizing access a[0] , a[1]

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-23 
22:09:14 UTC ---
(In reply to comment #7)
 Created attachment 18307 [details]
 Patch which I am testing

There is one bug in that patch which I have a fix for.

[Bug tree-optimization/29751] not optimizing access a[0] , a[1]

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2009-08-05 17:52 ---
Created an attachment (id=18307)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18307action=view)
Patch which I am testing

This patch fixes the problem including a+1 and a+2 not aliasing each other.
It adds two testcases and removes a xfail on one.
It also fixes a bug in cfgexpand.c (update_alias_info_with_stack_vars) so that
it does not create SSA_NAMES with a define statement of NULL.


-- 


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

[Bug tree-optimization/29751] not optimizing access a[0] , a[1]

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-06-09 02:35 ---
I have a simple patch (which needs some cleanups but it works).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rguenth at gcc dot gnu dot  |pinskia at gcc dot gnu dot
   |org |org


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

[Bug tree-optimization/29751] not optimizing access a[0] , a[1]

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-04-07 08:51 ---
Only if you extend refs_may_alias_p, as for pointers you have

 p_2 = p_1 + 1;
 *p_2
 *p_1

and it doesn't follow def-use chains to see the pointer-plus to disambiguate
both pointer de-references.  With arrays you see

 a[0]
 a[1]

which it handles fine.  It also should handle

 (*p_2)[0]
 (*p_2)[1]

fine (if you convert p_! to (int *)[] first).


-- 


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

[Bug tree-optimization/29751] not optimizing access a[0] , a[1]

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-04-07 01:28 ---
Hmm, if we change r to be an array, fre does the correct thing but shouldn't it
do the correct thing for the non array case too?


-- 


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

[Bug tree-optimization/29751] not optimizing access a[0] , a[1]

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-03-14 21:21 ---
Related to PR34172, but not fixed.  MEM_REF will get this right as we
effectively
have array refs on pointers there.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-06-11 00:30:03 |2008-03-14 21:21:32
   date||


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

[Bug tree-optimization/29751] not optimizing access a[0] , a[1]

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-06-11 00:30 ---
Confirmed, this is only a tree level missed optimization.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||alias, TREE
   Last reconfirmed|-00-00 00:00:00 |2007-06-11 00:30:03
   date||


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

[Bug tree-optimization/29751] not optimizing access a[0] , a[1]

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-11-14 01:06 ---
This is a problem of our VOPs not having base+offset and has nothing to do with
restrict.


int f(int *r)
{
  r[0] = 0;
  r[1] = 0;
  if(r[0]) foo();
}

is enough to reproduce the issue.  Also I think there might be a couple dups of
this with respect of structs instead.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|Missed optimization of  |not optimizing access a[0] ,
   |restrict pointer assigned   |a[1]
   |value   |


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