<div dir="ltr">This looks fine to me, though note that PRE would not normally do this because it's not "lifetime optimal" (since it extends the lifetime of the multiply), which is PRE's goal.  Doing what you are doing can at least theoretically be a lose for performance in some cases due to increasing register pressure.<div>
<div><br></div><div>I'm curious if this was driven just by that comment, or if it helps some case you are thinking about.</div><div> </div><div>If the latter, you also can't go much farther than this though without ending up writing a general code motion implementation (like <a href="https://courses.cs.washington.edu/courses/cse501/06wi/reading/click-pldi95.pdf">https://courses.cs.washington.edu/courses/cse501/06wi/reading/click-pldi95.pdf</a>), which i'm not aware of really being used very much in practice.</div>
<div><br></div><div>As an aside, GCC eventually implemented hoisting a problem that shares GVNPRE's dataflow for the most part (see <a href="https://gcc.gnu.org/bugzilla/attachment.cgi?id=26665">https://gcc.gnu.org/bugzilla/attachment.cgi?id=26665</a>)</div>
<div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 15, 2014 at 3:36 AM, Erik Verbruggen <span dir="ltr"><<a href="mailto:erikjv@me.com" target="_blank">erikjv@me.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When PRE detects a common operation after a basic diamond case and in<br>
one predecessor in that diamond, then hoist that operation in the common<br>
dominator of the predecessors instead of moving the operation into the<br>
predecessor lacking it.<br>
<br>
</blockquote></div><br></div>