On Fri, Oct 25, 2013 at 10:59 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse <marc.gli...@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.gli...@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?
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 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. Richard. > Thanks, > Richard. > >> -- >> Marc Glisse
