<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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="gmail-h5">> If you generate that, you will eliminate the store a, 5 again, and you should not.<br>
<br>
</div></div>Interesting, but slightly confusing. </blockquote><div><br></div><div>This is what i get for trying to reduce an algorithm quickly.</div><div>I'm sure i incorrectly removed some postdominance frontier checks or something.</div><div><br></div><div>It's probably easiest to take one of the working PDSE patches and look at that.</div><div><br></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">Assume you change the previous program slightly:<br>
<br>
  define void @foo(float* %a) {<br>
     ....<br>
  }<br>
<br>
  define void @foo(i1 %cond, float* %a) {<br>
  block1:<br>
     store float 5.0, float* %a<br>
     br i1 %cond, label %block2, label %block3<br>
<br>
  block2:<br>
    call foo(float* %a)<br>
    br i1 true, label %block2, label %block1   <---- Only this line has changed<br>
<br>
  block3:<br>
    store float 6.0, float* %a<br>
  }<br>
<br>
You get a CFG very similar to the one I posted earlier:<br></blockquote><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="gmail-"><br>
F3887544: Post Dominance.png <<a href="https://reviews.llvm.org/F3887544" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>F3887544</a>> <br></span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
</span>In your case the PDT is the first of the three you just mentioned:<br>
<br></blockquote><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">
> 3<br>
><br>
>  |<br>
><br>
><br>
> 1<br>
><br>
>  |<br>
><br>
><br>
> 2<br>
<br>
This is the post-dominator tree which we compute today and which won't be changed by this proposal (as no reverse-unreachable blocks exist). </blockquote><div><br></div><div>This program should be illegal, and as far as i can tell, it is :)</div><div><br></div><div>-> % bin/opt -view-cfg foo2.ll</div><div><div>Entry block to function must not have predecessors!</div><div>label %block1</div><div>bin/opt: foo2.ll: error: input module is broken!</div></div><div><br></div><div>Let's assume that's trivial to fix though, because it is.<br></div><div><br></div><div><br></div><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">
One other slightly related question. Do you assume that A post-dominates B means that a program that reaches B eventually must reach A?<br></blockquote><div><br></div><div>You can't say anything block wise, only edge wise.</div><div>That is, C is dependent on edge A->B if C postdominates B and C does not strictly postdominate A.</div><div><br></div><div>In any case, i'm sure i screwed up my translation of the algorithm, sorry ;)</div><div><br></div><div><br></div><div> <br></div></div></div></div>