<div dir="ltr">OK, I did some search, and the closest thing I could find was SSAUpdater, which doesn't apparently have the functionality.<div>I'm thinking about putting </div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace, monospace">BasicBlock::updatePHIs(BasicBlock* OldIncoming, BasicBlock* NewIncoming) </font></div></blockquote><div>function in BB (the other name that comes to my mind is <font face="monospace, monospace">fixPHIs</font>).</div><div>While searching, another question came to my mind:</div><div>In BB, there is the getFirstNonPHI function. Is there some kind of requirement for the PHINodes to be placed only at the beginning of BBs? I had this impression while reading through some parts of SSAUpdater, but I might have misunderstood that part of the code. IRBuilder seemed to not care about their placement.</div><div><br></div><div>I also had a brief look at MBB and MI and I suppose they could get a similar treatment, but I don't think there could be much direct code reuse here, as PHIs are handled differently in both cases.</div><div><br></div><div>Cheers,</div><div>Marcin</div><div class="gmail_extra"><br><div class="gmail_quote">2017-05-16 9:22 GMT+02:00 Marcin Słowik <span dir="ltr"><<a href="mailto:me@marandil.pl" target="_blank">me@marandil.pl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>while experimenting with various switch-instruction optimizations, I have stumbled upon a trivial task of updating PHI Nodes, when possible predecessors could have changed. A simple example would be splitting switch into two parts:</div><div><br></div><div>switch (a) {<br></div>  default: BB0;<br class="m_5842630099553786981gmail-Apple-interchange-newline">  case 0: BB0;<br class="m_5842630099553786981gmail-Apple-interchange-newline">  case 1: BB1;<br class="m_5842630099553786981gmail-Apple-interchange-newline">  case 2: BB2;<br class="m_5842630099553786981gmail-Apple-interchange-newline">  case 19: BB0;<br class="m_5842630099553786981gmail-Apple-interchange-newline">  case 20: BB1;<br class="m_5842630099553786981gmail-Apple-interchange-newline">  case 21: BB2;<div>}</div><div><br></div><div>changed into:</div><div><br></div><div>if (0 <= a <=2) {</div><div>  switch (a) {</div><div>    default: unreachable;</div>    case 0: BB0;<div>    case 1: BB1;<br class="m_5842630099553786981gmail-Apple-interchange-newline">    case 2: BB2;<div>  }</div></div><div>} else {</div><div><div>  switch (a-19) {</div><div>    default: BB0;</div>    case 0: BB0;<br class="m_5842630099553786981gmail-Apple-interchange-newline">    case 1: BB1;<br class="m_5842630099553786981gmail-Apple-interchange-newline">    case 2: BB2;<div>  }</div></div><div>}</div><div><br></div><div>Now, if the blocks contained any PHI Nodes, their predecessors are no longer valid, since we had to include new BBs for the switch instructions inside the virtual if/else.</div><div>I have a rather straightforward function that scans BB for PHINode instructions and given two additional BBs: OldIncoming and NewIncoming checks whether OldIncoming is still a possible predecessor (it may happen in many cases) and based on this either replaces all PHINode incomings from OldIncoming to NewIncoming, or adds NewIncoming with the same value as in case of OldIncoming.</div><div><br></div><div>I currently have 3 questions:</div><div>1) Is this functionality already implemented somewhere in the LLVM (on IR level)?</div><div>2) If not 1), what would be the best place to put it? BasicBlock class?</div><div>3) If not 1), should I submit a patch?</div><div><br></div><div>Ad. 2) I currently use it as a part of my pass, but I see other potential uses in other parts of the code.</div><div><br></div><div>Best Regards,</div><div>Marcin Slowik</div></div>
</blockquote></div><br></div></div>