On Mon, 28 Oct 2013, Jeff Law wrote:
On 10/28/13 16:05, Marc Glisse wrote:
I checked and it does the wrong thing (I don't have the testcase handy
anymore, but it shouldn't be hard to recreate one), I even wrote a patch
(attached) but it is related to:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02238.html
so it can't go in. A more limited fix (still missing many cases) would
be possible. I didn't test VA_END, but it doesn't look as bad (it is the
SSA_NAME case that is wrong for memcpy
Actually, it's fairly easy to see with memset. Something like this:
/* { dg-do compile } */
/* { dg-options "-O1 -fdump-tree-optimized" } */
void f (long *p) {
*p = 42;
p[4] = 42;
__builtin_memset (p, 0, 100);
}
/* { dg-final { scan-tree-dump-not "= 42" "optimized" } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */
Indeed. Do you want to commit it xfailed or put it in bugzilla so we don't
lose it? (it becomes harder if you replace p with p-1 in the memset
arguments).
While I am posting non-submitted patches, does the following vaguely
make sense? I couldn't find a testcase that exercised it without some
local patches, but the idea (IIRC) is that with:
struct A { struct B b; int i; }
we can easily end up with one ao_ref.base that is a MEM_REF[p] and
another one a MEM_REF[(B*)q] where p and q are of type A*, and that
prevents us from noticing that p->i and q->b don't alias. Maybe I should
instead find a way to get MEM_REF[q] as ao_ref.base, but if q actually
points to a larger structure that starts with A it is likely to fail as
well...
I've never looked at the alias oracle stuff, but ISTM that offsets from the
base ought to be enough to disambiguate?
Yes, the issue here is making them notice that they can be seen as having
bases of the same type (and thus that it is meaningful to compare
offsets), since there are multiple possible base choices when a structure
starts with a structure which starts with...
In the category "ugly hack that I won't submit", let me also attach this
patch that sometimes helps notice that malloc doesn't alias other things
(I don't know if the first hunk ever fires).
Well, one thing that can be done here (I think it comes from Steensgaard and
I'm pretty sure it's discussed in Morgan's text) is you assign a storage
class and propagate that. Once you do so, you can eliminate certain things.
You use a vrp-like engine with a fairly simple meet operator to handle
propagation of the storage class.
Once you have storage classes for all the pointers, you can make certain
deductions about aliasing relationships. Including what things in the malloc
storage class can and can not alias.
Sounds good, but I am not really up to rewriting the points-to analysis at
the moment...
Thanks,
--
Marc Glisse
