<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><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><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><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>