<div dir="ltr"><div><div>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.<br><br></div>After a bit of thought, it is correct in the general case, but definitively something stricter is needed here. Looking at <tt class=""><span class="">inaccessiblememonly</span></tt> I'm not sure this is what is needed. What if the memory allocator is defined is the current module ?<br><br></div>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 <tt class=""><span class="">inaccessiblememonly</span></tt> for ? Should the semantic be refined to fit the bill better ?<br><br><div><div class="gmail_extra"><div class="gmail_quote">2016-01-04 12:29 GMT+01:00 Amaury SECHET <span dir="ltr"><<a href="mailto:deadalnix@gmail.com" target="_blank">deadalnix@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2015-12-26 18:32 GMT+01:00 Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div><div>
<div>On 12/26/2015 02:17 AM, Amaury SECHET
via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>I'm trying to fix that bug: <a href="https://llvm.org/bugs/show_bug.cgi?id=20049" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=20049</a><br>
<br>
</div>
It turns out this is the kind of optimization that I really
need, as when it isn't done, all kind of other optimizations
opportunities down the road are not realized as they are not
exposed.<br>
<br>
</div>
I have no idea where to start digging for this. I assume there
is some kind of interaction between memory dependency and alias
analysis that is overly conservative. Can someone gives me some
infos on how the 2 interact together ? What is the code that is
supposed to remove these kind of loads ?<br>
</div>
</blockquote></div></div>
First, it looks like you're using an older version of LLVM (the load
syntax has changed). That's definitely not recommended since it
will greatly limit your choices when encountering an issue like
this.<br>
<br></div></blockquote><div><br></div></span><div>I just reused an old code sample. The problem still exists in recent version of LLVM.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
Second, the aliasing problem has to do with the effects of the
"allocmemory" callsite on a memory location associated with an
earlier alloca. There's nothing that prevents your allocmemory
function from writing to global state. 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. Take a look at the
isNonEscapingLocalObject predicate in BasicAA. Then look at
"getModRefInfo(ImmutableCallSite CS, const MemoryLocation
&Loc)". Double check to make sure this is the one that MDA
actually calls. <br>
<br></div></blockquote><div><br></div></span><div>I don't think this is the problem. When there is only 2 calls to allocmemory, loads are optimized away as expected. But it seems that the analysis is confused with 3+ calls.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
Third, you might want to take a look the new <tt><span>inaccessiblememonly</span></tt><span><span> attribute. Depending
on how you're modelling your allocation, this might help resolve
the aliasing problem in different way. However, be aware that
this is *very* new. In particular, I triggered an optimizer bug
by adding the new attribute to your particular example. :( <br>
<br>
Fourth, have you considered implementing a simple escape
analysis pass? I notice that the store-load forwarding would
just fall out once you removed the last allocation. I believe
the fixed point would then become a function which returns the
constant answer and does nothing else. <br>
</span></span><tt><span></span></tt><br></div></blockquote><div><br></div></span><div>Yes I did. More specifically, there is a pass that try to recognize memory allocation like calls and optimize them, which right now have libc and some overloads of operator new hardcoded in it but not much more. This could be greatly improved IMO, to be language agnostic (and better support C++ in the process), but really, I do think relying on this to get the load eliminated, when noalias already provide this information to the optimizer, is overkill.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
Fifth, some pointers on debugging this yourself. GVN (which is the
one which does complicated *-load forwarding) calls MDA
(MemoryDepedenceAnalysis). Using the appropriate -debug-only
options will likely get you to the right area. You can also
consider using the MemDepPrinter pass to bypass GVN. I don't know
of a way to issue raw AA queries for testing. That would be useful,
but I don't know that we have it. <br>
<br>
Hope that helps.<br><br></div></blockquote><div><br></div></span><div>Yes, thanks. I'll probably come back with more question once I've played with these options a bit. Sorry for the late answer, I was mostly off the grid the past 2 weeks.<br></div><div><br></div></div></div></div>
</blockquote></div><br></div></div></div>