This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

aliasing between const and non-const objects


Hi,

Suppose you wanted to fix such testcase:
-------
int *t;
const int *c;
void f (void)
{
  t[0] = c[0] + c[1] + c[2];
  t[1] = c[0] + c[1] + c[2];
}
-------

With fixing I mean to make CSE recognize the redundant second summation.
This is possible because the write to t[0] can't alias with the values
load from c[].

Currently GCC can't recognize this, because the mem's accessing the c
array look like so:
    (set (reg:SI 61)
         (mem/s:SI (plus:DI (reg/f:DI 59) (const_int 4 [0x4])) [3 S4 A32]

And the mems for writing to 't' look like:
    (set (mem/s:SI (plus:DI (reg/f:DI 67)
                    (const_int 4 [0x4])) [3 S4 A32])
         (reg:SI 75))

I.e. same alias set and everything, so they conflict, and 'c' has to be
assumed changed, so no CSE possible.  One possibility would for instance
be to set the RTX_UNCHANGING_P flag on the MEMs accessing 'c'.  When I do
this trivially by simply setting lang_hook.honor_readonly to true the
compiler completely bootstraps.  This fixes the testcase because the
'c[x]' indirect_refs have "readonly"  set (in tree form).  But all hell
breaks loos in the testsuite.  I looked at some of the failures in C, and
tried to fix those too, but it's cumbersome and I'm not sure if I'm not
barking up the wrong tree.  FWIW the particular test I looked at was
930513-2.c, which boils down to:

  for (i = 0; i < 4; i++)
    {
      const int j = i;
      int k;
      sub3 (&j);
      k = j;
      eq (k, k);
    }

this is miscompiled because the addressof machinery generates new mems for
the stackslot of 'j' which misses the RTX_UNCHANGING_P attribute, because
'j' itself doesn't have it.  Changing maybe_set_unchanging() to simply set
this flag for all readonly trees make this check pass again, but of course
doesn't fix the other testcase ;-)  The compiler still bootstraps then,
though.

So, question: is RTX_UNCHANGING_P worth fiddling with at all?  One
particular comment in maybe_set_unchanging() points to that flag better
get rid of.

How should one fix this otherwise?  Another possibility would be to
introduce a new "readonly" flag for the MEM_ATTR tacked to each MEM rtl,
and set it inside set_mem_attributes.

And the third possibility seems to be fiddling with aliasing sets to cover
also constness, although I'm not sure this is possible at all.


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]