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

[Amaury SECHET via llvm-dev]

2016-01-04 23:28 GMT+01:00 Philip Reames <listmail at philipreames.com>:

>
>
> On 01/04/2016 09:55 AM, Amaury SECHET 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.
>
> 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?
>

No, you are not missing anything. I was simply able to confirm this by
dumping the guts of GVN.


>
> 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.
>
>
I'm afraid that, depending on the way the software is built, you may end up
with a function marked as not accessing any visible memory can end up
modifying visible memory after modules are merged. I think this is the kind
of thing that may be exposed by LTO (I may be wrong on that one), this is
also something that can be exposed by languages like D, where people are
going to compile by D module, D packages or the whole program at once.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160105/f401dac0/attachment.html>