<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 01/04/2016 07:32 AM, Amaury SECHET
wrote:<br>
</div>
<blockquote
cite="mid:CANGV3T0E91VD0JGb3ZvX73oORmG-o7QkT_0MJZZO=Kub=F=jBA@mail.gmail.com"
type="cite">
<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>
</div>
</div>
</div>
</blockquote>
Can you give a bit more context? I'm not sure which of the examples
you're talking about.<br>
<blockquote
cite="mid:CANGV3T0E91VD0JGb3ZvX73oORmG-o7QkT_0MJZZO=Kub=F=jBA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div><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>
</div>
</div>
</blockquote>
At the moment, inaccessiblememonly would require separate
compilation of the allocation function. <br>
<blockquote
cite="mid:CANGV3T0E91VD0JGb3ZvX73oORmG-o7QkT_0MJZZO=Kub=F=jBA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><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>
</div>
</blockquote>
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. <br>
<br>
If you have specific suggestions for how to refine the semantics,
please make them. Getting the details right is always the hard
part. :)<br>
<br>
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...<br>
<blockquote
cite="mid:CANGV3T0E91VD0JGb3ZvX73oORmG-o7QkT_0MJZZO=Kub=F=jBA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div>
<div class="gmail_extra">
<div class="gmail_quote">2016-01-04 12:29 GMT+01:00 Amaury
SECHET <span dir="ltr"><<a moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:listmail@philipreames.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:listmail@philipreames.com">listmail@philipreames.com</a></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
moz-do-not-send="true"
href="https://llvm.org/bugs/show_bug.cgi?id=20049"
target="_blank"><a class="moz-txt-link-freetext" href="https://llvm.org/bugs/show_bug.cgi?id=20049">https://llvm.org/bugs/show_bug.cgi?id=20049</a></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>
</blockquote>
<br>
</body>
</html>