[llvm-dev] Can someone give me some pointer on alias analysis ?

[Philip Reames via llvm-dev]

On 01/04/2016 09:55 AM, Amaury SECHET wrote:
>
>
> 2016-01-04 18:21 GMT+01:00 Philip Reames <listmail at philipreames.com 
> <mailto:listmail at philipreames.com>>:
>
>     On 01/04/2016 07:32 AM, Amaury SECHET wrote:
>>     After a bit more investigation, it turns out that because %0 is
>>     stored into %1 (after bitcast) and so %3 may have access to it
>>     and clobber it.
>     Can you give a bit more context?  I'm not sure which of the
>     examples you're talking about.
>
>
> Sure. Let's look at http://pastebin.com/K0J9yGq1
>
> Because of the store line 7, it is assumed that the call line 8 may 
> see %0 and even modify the memory it points to. As a result, it is 
> assumed that the load line 11 may not be eliminated.
>
> Which seems actually correct in the general case.
This seems like a restatement of what I said in my original response:
"You have to teach the alias analysis that an unescaped noalias pointer 
can't alias the global state allocmemory might access. Slightly 
surprised we don't get this today, but oh well. "

Or am I missing something?
>
>
>>
>>     After a bit of thought, it is correct in the general case, but
>>     definitively something stricter is needed here. Looking at
>>     inaccessiblememonly I'm not sure this is what is needed. What if
>>     the memory allocator is defined is the current module ?
>     At the moment, inaccessiblememonly would require separate
>     compilation of the allocation function.
>>
>>     This leads me to conclude this is way more linked to the memory
>>     allocation pass than I expected it to be in the first place. Can
>>     I ask what you plan to use inaccessiblememonly for ? Should the
>>     semantic be refined to fit the bill better ?
>     Well, I didn't introduce the attribute, so I can't speak for the
>     original intent.  For me, I plan on applying it to some of our out
>     of line allocation functions and other helper routines which
>     modify runtime state, but not java visible state.
>
>     If you have specific suggestions for how to refine the semantics,
>     please make them.  Getting the details right is always the hard
>     part.  :)
>
>     You might also consider using a variant of your allocation
>     function which takes a pointer to the global state it needs to
>     modify.  Doing this would allow you to use argmemonly to restrict
>     the aliasing while still allowing whole program optimization.  I
>     haven't tried this in practice, but it seems like it would
>     probably work...
>
>
> I do not wish to make suggestion before I understand where this is 
> coming from. So far, from what I've collected, use cases are:
>  - Memory allocation
>  - Runtime isolation for managed languages.
>
> I have some more though to put into this, but to boot, would that be 
> possible to only use this attribute on method that are declared, but 
> not defined and remove it when merging modules ?
This seems semi reasonable.  I haven't thought through the implications, 
but it might be worth considering.

> It doesn't look like it is necessary to have it when the function may 
> be exposed depending on the way the software is built.
Er, not sure what you meant here.

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160104/03dff2e1/attachment.html>