[Bug c/40060] New: casts loose alignment info

[Bug c/40060] New: casts loose alignment info

[matz at gcc dot gnu dot org]

These testcase on powerpc:
  gcc.target/powerpc/405-dlmzb-strlen-1.c scan-assembler dlmzb\\\\.  (-m32)
  gcc.target/powerpc/440-dlmzb-strlen-1.c scan-assembler dlmzb\\\\.  (-m32)
fail since expand from SSA.  That's because TER can't work around a frontend
deficiency anymore.  The code therein is:

size_t strlen8(const long long *s)
{ return strlen((const char *)s); }

the parameter is "long long *" to make the alignment known to the compiler.
There are of course other ways, but this is not what this report is about.
In any case the target type of *s is aligned(8).
The cast is there to be type-correct for strlen, but the destination type
of that cast simply is "const char *", where "char" of course is aligned(1).

For the middle-end the case to char* is not useless, hence we can't get
rid of it, so the pointer alignment as far as strlen is concerned is 1, which
is why the transformation doesn't happen anymore.  TER could work around this
in some case (single use of that temporary), but not always.  Now it doesn't
do that work-around in any case.

What IMO needs to happen is that the frontend construct a new type as
destination type of the cast, as if the user had written:

typedef char alignedchar __attribute__((aligned(8)));
x = (const alignedchar *)s;

Unfortunately this can't be easily transformed into a testcase using
__alignof__, because __alignof__((*(char*)s)) is already transformed by
the frontend looking through the casts.  That disregards that the same 
can't be done by the middle-end.


-- 
           Summary: casts loose alignment info
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: matz at gcc dot gnu dot org


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

[Bug c/40060] casts loose alignment info

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-07 12:56 -------
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |missed-optimization
   Last reconfirmed|0000-00-00 00:00:00         |2009-05-07 12:56:14
               date|                            |


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

[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

[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 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]

-- 

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

[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]

------- 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/4.6 Regression] casts loose alignment info

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2010-07-31 09:29 -------
GCC 4.5.1 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.1                       |4.5.2


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