<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 12, 2015 at 10:08 AM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<div>On 01/11/2015 10:35 PM, Daniel Berlin
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Looking at what LLVM does, the failing on the
PRE side is that our PRE/GVN models are not strong
enough to handle this. I'm not sure at all why we
think anything else is necessary. </div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>By this i mean we don't actually perform real PRE for
loads. It's a known deficiency and one that does not
require any duplicate heuristics to solve.</div>
<div>Right now we perform some availability based removal
that happens be willing to do an insertion here or there
to try to move a load in some cases (it will only do a
single insertion). It's not also based on real
availability, but on finding nearest dependencies of loads
and squinting at them (which is not even really the same
as finding where a load stops being available) funny.</div>
<div><br>
</div>
<div>It's also not real PRE, just some code that is willing
to insert one load to move a load.</div>
</div>
</div>
</div>
</blockquote></span>
Er, I think we have a terminology problem here. From what I can
gather, our current implementation *is* an implementation of classic
PRE. It's more or less directly organized around the classic
"available" and "anticipated" concepts from the literature. The
*implementation* has some limitations, but the conceptual framework
is there*. One of the key invariants in classic PRE is that you do
not change program behaviour on any path. As a result, moving (or
at most duplicating) loads is pretty much all that happens.<br>
<br>
* It took me a few hours of squinting at the code to recognize that
weird backwards walk as being an implementation of "anctipated", but
it is. The "available" part comes from MemoryDependenceAnalysis and
the forward dataflow algorithm based on those inputs.<br>
<br>
If you want to start inserting loads on paths which didn't
previously have them - for example the loop preheader in your
example in the previous email - this is not classic PRE as I'm
familiar with it. It can be very profitable and worthwhile, but is
not classic PRE. I'm not sure what this variant is known as in the
literature. <br>
<br>
(If I'm being overly pedantic here, or just flat out wrong, please
say so. I'm still exploring related material and am trying to
categorize things in my own head.)<br>
<br>
I think we actually in reasonable agreement that we do need to move
beyond 'classic PRE' as I called it above. If you have specific
suggestions, positive or negative examples, or other thoughts to
share, I'd very much value the input. <br><span class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>If you want this case to work, what you need is a real
Load PRE implementation, not one based on simple memdep
based load moving.</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Trying to hack this one up with profile guided code
duplication, etc, to get it to kinda sorta work seems to
me to be a bad idea.</div>
</div>
</div>
</div>
</blockquote></span>
Not sure I really agree here, but I'm open to pushing as far as we
can with static heuristics first. I suspect that's likely to be
more stable w.r.t. optimization effect and applicable to more
cases. <br></div></blockquote><div><br></div><div><br></div><div>I agree with Danny. Profile data is useful for code placement, and profitability computation in speculative PRE. I don't see how your proposed code movement can be an enabler for more PRE.</div><div><br></div><div>David</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>It's certainly not requiring special code
duplication heuristics, etc.</div>
<div><br>
</div>
<div>So either you are thinking of a case that is
different from the above, or I am seriously
confused :)</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</span></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>