<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 15, 2016 at 12:21 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Daniel,<span class=""><br>
<br>
Daniel Berlin wrote:<br>
> As a starting point, LLVM will conservatively not speculate such<br>
> loads and stores; and will leave open the potential to upstream<br>
> logic that will have a more precise sense of when these loads and<br>
> stores are safe to speculate.<br>
><br>
><br>
> I think you need to define what you mean by control dependence here. If<br>
> you mean speculation, you should say speculation :)<br>
<br></span>
Apologies for being non-specific -- this is really just "don't<br>
speculate".<span class=""><br>
<br>
> As you describe below, it is not enough to simply not speculate them.<br>
<br></span>
I'm not sure where I said that?</blockquote><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br>
<br>
> You also are saying you don't want to change the conditions on which<br>
> they execute.<br>
> That is very different from speculation.<br>
<br></span>
If I implied that somehow then I (or the example) was wrong. :)<br></blockquote><div><br></div><div>:)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
We can't speculate these instructions (without special knowledge of<br>
the GC and the Java type system), and that's it.</blockquote><div>Okey.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br>
<br>
> FWIW: This raises one of the same issues we have now with may-throw,<br>
> which is that, if all you have is a flag on the instruction, now you<br>
> have to look at every instruction in every block to know whether a *CFG*<br>
> transform is correct.<br>
><br>
> That means any pass that wants to just touch the CFG can't do so without<br>
> also looking at the instruction stream. It will also make a bunch of<br>
> things currently O(N), O(N^2) (see the sets of patches fixing may-throw<br>
> places, and extrapolate to more places).<br>
<br></span>
As I said, I'm only proposing a "don't speculate" flag, so this does<br>
not (?) apply.<br></blockquote><div><br></div><div>As long as it applies only to the instructions, and they do not act as "barriers" to hoisting/sinking, then yes, it should not apply.<br></div><div><br></div><div>(In theory it still means things have to look at instructions, but they had to look at them anyway at that point :P) <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
However, I didn't quite understand your point about may-throw -- how<br>
is may-throw different from a generic side-effect (volatile store,<br>
syscall etc.)? All of those can't be hoisted or sunk -- we have to<br>
make sure that they execute in semantically the same conditions that<br>
they did in the original program.<div><div class="h5"><br></div></div></blockquote><div>may-throw is, AFAIK, worse. They act as barriers to sinking *other things*. You cannot sink a store past a may-throw, or hoist a load above them. You can't optimize stores across them either:<br></div><div><br></div><div>See:<br><div>[PATCH] D21007: DSE: Don't remove stores made live by a call which unwinds.</div></div><div><div>for the latter </div><div><br></div><div>[llvm] r270828 - [MergedLoadStoreMotion] Don't transform across may-throw calls</div></div><div>for the former.</div><div><br></div><div>"<span style="font-size:12.8px">It is unsafe to hoist a load before a function call which </span><span class="" style="font-size:12.8px">may</span><span style="font-size:12.8px"> </span><span class="" style="font-size:12.8px">throw</span><span style="font-size:12.8px">, the</span></div><span class="" style="font-size:12.8px;background-color:rgb(255,255,255)">throw</span><span style="font-size:12.8px"> might prevent a pointer dereference.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Likewise, it is unsafe to sink a store after a call which </span><span class="" style="font-size:12.8px;background-color:rgb(255,255,255)">may</span><span style="font-size:12.8px"> </span><span class="" style="font-size:12.8px;background-color:rgb(255,255,255)">throw</span><span style="font-size:12.8px">.</span><br style="font-size:12.8px"><span style="font-size:12.8px">The caller might be able to observe the difference."</span></div><div class="gmail_quote"><div><br></div><div>This then leads to the problem i mentioned - because the may-throwness is not expressed at the bb level (or in the CFG, by having the call end the block, or at the least, a fake abnormal CFG edge), everything has to go checking every instruction along the entire path they want to hoist, whereas hoisting is normally just a simple dataflow problem with BB level properties :)</div><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><div class="h5"><br></div></div></blockquote></div><br></div></div>