Aliasing: look through pointer's def stmt

[Richard Biener]

On Fri, Oct 25, 2013 at 11:29 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Fri, 25 Oct 2013, Richard Biener wrote:
>
>> On Fri, Oct 25, 2013 at 10:59 AM, Richard Biener
>> <richard.guenther@gmail.com> wrote:
>>>
>>> On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse <marc.glisse@inria.fr>
>>> wrote:
>>>>
>>>> On Thu, 24 Oct 2013, Jeff Law wrote:
>>>>
>>>>> On 10/24/13 23:23, Marc Glisse wrote:
>>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I noticed that in some cases we were failing to find aliasing
>>>>>> information because we were only looking at an SSA_NAME variable,
>>>>>> missing the fact that it was really an ADDR_EXPR. The attached patch
>>>>>> passes bootstrap+testsuite, does it make sense? (I am a bit afraid of
>>>>>> losing some type information for instance)
>>>>>>
>>>>>> I didn't investigate the 2 tests where I had to remove dg-bogus,
>>>>>> because
>>>>>> removing dg-bogus sounds like a bonus...
>>>>>>
>>>>>> 2013-10-25  Marc Glisse  <marc.glisse@inria.fr>
>>>>>>
>>>>>> gcc/
>>>>>>      * tree-ssa-alias.c (ao_ref_init_from_ptr_and_size): Look for an
>>>>>>      ADDR_EXPR in the defining statement.
>>>>>
>>>>>
>>>>> Shouldn't the ADDR_EXPR have been propagated into the use?
>>>>
>>>>
>>>>
>>>> Maybe when the address is a constant, but here it comes from malloc.
>>>
>>>
>>> points-to should have "propagated" the alias info, so no, looking at
>>> def-stmts in random places like this isn't ok.  Where does alias info
>>> get lost?
>
>
> By "points-to", do you mean in pt_solution? That's very rough information,
> and in particular here it can't tell me that 2 fields of the same struct
> don't alias, can it?

No, it cannot.

>> It doesn't get lost, but this is the missed optimization that malloc
>> results still alias with global pointers (here a function argument).
>> Taking into account the offset shouldn't change anything.
>
>
> I think this is a different issue (but if you say improving malloc would
> help, maybe).
>
>
>> I suppose you are looking for the memcpy to be folded into an
>> assignment?  Which ao_ref_from_ptr_and_size is critical for
>> the transform - it doesn't seem to be the one in memory op folding.
>
>
> No, I only used memcpy as an example, my goal is for the compiler to notice
> that the call (memcpy here, possibly other functions with some new attribute
> later) doesn't clobber the counter (i) and thus the counter value is the
> same after the call as it was before.

Ah, so you are looking at call_may_clobber_ref_p_1 and its pointer handling
when special-casing builtins?  Note that fields can only be disambiguated
if the size of the access is known (not sure what fancy attribute you
are going to invent here ...).  Generally the simple alias machinery
is written to be cheap, walking use-def chains isn't.  Users do not have
to expect use-def chains to be walked (we can change that rule of course,
but for example the RTL alias machinery also shares the core of the
gimple alias machinery.

But I can see that in this particular case the patch makes sense.  Still,

+  if (TREE_CODE (ptr) == SSA_NAME)
+    {
+      gimple stmt = SSA_NAME_DEF_STMT (ptr);
+      if (gimple_assign_single_p (stmt)
+         && !gimple_has_volatile_ops (stmt)
+         && gimple_assign_rhs_code (stmt) == ADDR_EXPR)
+       ptr = gimple_assign_rhs1 (stmt);
+    }

no need to look at gimple_has_volatile_ops (stmt).  Also you want to
handle

 p_2 = p_1 + CST;
 foo (p_2);

which has a related canonical form,

 p_2 = &MEM[p_1, CST];

The patch is ok with the volatile check removed, you can followup
with handling POINTER_PLUS_EXPR if you like.

Thanks,
Richard.

> If memcpy gets turned to an assignment (which alignment should prevent), my
> testcase becomes useless.
>
> --
> Marc Glisse