This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Aliasing: look through pointer's def stmt
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jeff Law <law at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 25 Oct 2013 11:29:16 +0200 (CEST)
- Subject: Re: Aliasing: look through pointer's def stmt
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1310250707430 dot 14734 at stedding dot saclay dot inria dot fr> <526A0269 dot 8030407 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1310250809590 dot 4165 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc27=sN1itn+N09rpmm8tWGt-Khu7oASLd0ODsdZh=ofzw at mail dot gmail dot com> <CAFiYyc2EtayY0tiW1pz4t-zf0uVC24UcF5s7yaUrY3f7_jxoVg at mail dot gmail dot com>
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?
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.
If memcpy gets turned to an assignment (which alignment should prevent),
my testcase becomes useless.
--
Marc Glisse