Re: free is a killer

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Oct 29, 2013 at 6:35 AM, Jeff Law <law@redhat.com> 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" } } */
>
>
> I'm sure it can be made to work with memcpy as well, it's just harder
> because you have to ensure the source/dest args don't alias.
>
>
>
>>
>>
>> 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?
>
>
>>
>>
>>
>> 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.

Of course in the example we have the "global memory" storage class
(incoming function argument) and "malloc memory" which is really
the same storage class.  It only becomes a different storage class
if you factor in flow analysis (for which the current PTA code is weak
once you leave the SSA web).

Richard.

> Jeff
>
>