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

[Philip Reames via llvm-dev]

On 01/04/2016 12:54 PM, Mehdi Amini via llvm-dev wrote:
>
>> On Jan 4, 2016, at 12:53 PM, Mehdi Amini via llvm-dev 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>>>
>>> On Jan 4, 2016, at 9:55 AM, Amaury SECHET via llvm-dev 
>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> 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 athttp://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.
>>>
>>>
>>>>
>>>>     After a bit of thought, it is correct in the general case, but
>>>>     definitively something stricter is needed here. Looking
>>>>     atinaccessiblememonlyI'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 useinaccessiblememonlyfor ? 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 ? 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.
>>
>> We can imagine a function defined in the current module, that does 
>> not modify any global, but calls malloc. Could it be inferred the 
>> argmemonly?
>
> I meant inaccessiblememonly instead of argmemonly…
I believe that it should be yes.  (If we had malloc marked as 
inaccessiblememonly which we don't currently.)
>
> —
> Mehdi
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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