[Bug middle-end/40060] [4.5 Regression] casts loose alignment info

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-04-06 11:20 ---
GCC 4.5.0 is being released.  Deferring to 4.5.1.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.5.0   |4.5.1


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

[Bug middle-end/40060] [4.5 Regression] casts loose alignment info

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-01-14 16:57 ---
Note that with the current middle-end setup we cannot really ever derive
anything about alignment when just seeing a pointer type.  We only can
ever derive alignment information when having access to the pointed-to
decl or when encountering an actual dereference of a pointer (though as
with this middle-end problem I'm sure we have bugs where the alignment
of the access is not that of the type of the dereferenced pointer).

Thus get_pointer_alignment is overly optimistic.

We could establish some C rules in the middle-end namely that pointer
function arguments have proper alignment, likewise passing a pointer
to a function is as good as a dereference of it.  But as other people
have noted we simply need to propagate alignment information
somewhere and the frontends need a way to communicate constraints to
the middle-end.

The operand scanner could set a flag in the SSA names pointer information
whether it is dereferenced or passed as function argument, points-to
information can constrain alignment based on the pointed-to objects
(but never can derive larger alignment than the pointed-to types).


-- 


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

[Bug middle-end/40060] [4.5 Regression] casts loose alignment info

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/40060] [4.5 Regression] casts loose alignment info

[matz at suse dot de]

--- Comment #5 from matz at suse dot de  2009-05-07 15:13 ---
Subject: Re:  [4.5 Regression] casts loose alignment
 info

On Thu, 7 May 2009, rguenth at gcc dot gnu dot org wrote:

> And if something should look through conversions it is get_pointer_alignment

Yes, this is actually used in the ppc testcase to get hold of the 
pointer alignment of the mem buffer.  The conservatively typed cast is 
confusing it then, and as explained we aren't allowed to look through it 
(and if we were we would have to use the _lowest_ not largest alignment in 
the those conversion sequence).


-- 


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

[Bug middle-end/40060] [4.5 Regression] casts loose alignment info

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-05-07 15:06 ---
And if something should look through conversions it is get_pointer_alignment
which funnily has

  /* We rely on TER to compute accurate alignment information.  */
  if (!(optimize && flag_tree_ter))
return 0;

eh.  That's probably trying to work around the alignment wrong-code bugs ... :/


-- 


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

[Bug middle-end/40060] [4.5 Regression] casts loose alignment info

[matz at gcc dot gnu dot org]

--- Comment #3 from matz at gcc dot gnu dot org  2009-05-07 13:28 ---
How alignment is dealt with in was explained by Joseph in 
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954#c10
A conversion sequence implicitely maintains the largest found alignment.
Looking through casts would not be correct for the middle-end, as a different
frontend could very well use such conversions to implement what you suggested,
namely forcefully reducing alignment for whatever reason.  Looking through
the cast would deafeat that, it's really the frontend that needs to establish
the expected semantics here (retaining the large alignment through casts).

As usual with the problems exposed by the more limited TER it's not really
a regression.  Trivially modifying the testcase to have two uses of the same
cast would have made TER not work around the situation and you would have
ended up with the missed optimization already since introduction of tree-ssa
(and TER of course).


-- 


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

[Bug middle-end/40060] [4.5 Regression] casts loose alignment info

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-05-07 13:15 ---
Actually a cast to a lower alignment is valid (to an bigger alignment is
questionable if the pointer is not already aligned).
And this is a regression from the 4.4 as these testcases passed.  Really expand
should look through NOPs.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|enhancement |normal
  Component|c   |middle-end
Summary|casts loose alignment info  |[4.5 Regression] casts loose
   ||alignment info
   Target Milestone|--- |4.5.0


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