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

[Amaury SECHET via llvm-dev]

Can't the GlobalsAA pass figure that out without requiring the annotation ?

2016-01-04 21:54 GMT+01:00 Mehdi Amini <mehdi.amini at apple.com>:

>
> On Jan 4, 2016, at 12:53 PM, Mehdi Amini via llvm-dev <
> 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> wrote:
>
>
>
> 2016-01-04 18:21 GMT+01:00 Philip Reames <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.
>
>
>>
>> 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 ? 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…
>
> —
> Mehdi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160104/cfccc93c/attachment.html>