<div dir="ltr">On Wed, Mar 12, 2014 at 6:38 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<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">+      Constant *Cmp = ConstantExpr::getICmp(ICmpInst::ICMP_SLT,<br>

InitVal, OtherVal);<br>
+      Constant *One = ConstantInt::get(LI->getType(), 1);<br>
+      Value *Vals[] = {<br>
+        ConstantExpr::getSelect(Cmp, InitVal, OtherVal),<br>
+        ConstantExpr::getAdd(ConstantExpr::getSelect(Cmp, OtherVal,<br>
InitVal), One)<br>
+      };<br>
+      MDNode *MD = MDNode::get(LI->getContext(), Vals);<br>
<br>
This is assuming the comparisons folds. It would probably be a bit<br>
nicer to work with the integer values directly.<br></blockquote><div><br></div><div>If the comparison doesn't fold and it remains a ConstantExpr, this code still works. A ConstantExpr isn't as nice of a range bound as a ConstantInt, but if that's all we have, that's all the select would have. If we converted it to use integer values directly, or APInts rather, it wouldn't handle that case. Also, the inputs and outputs are already both Constants, and there's not that much code here.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The comment<br>
<br>
;; check that global opt turns integers that only hold 0 or 1 into bools<br>
<br>
is now out of date.<br></blockquote><div><br></div><div>Attached is an updated patch which fixes this.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The new optimization is a bit simpler and a bit less likely to upset<br>
other optimizations, but it is also a bit less powerful. Can you<br>
explain why you want the change? Have you hit a case where the select<br>
was detrimental?<br>
</blockquote><div><br></div><div>Yes, I have a benchmark where the select disrupts other optimizations and is detrimental. Also, it seems intuitively bad to speculatively create selects hoping that it'll help subsequent optimizations more than it hurts.<br>

<br></div><div>This patch is still powerful enough to optimize the bzip2 benchmark that originally motivated this optimization. It's only less powerful in that it indicates a range of values instead of just the two discrete values, but it seems most existing optimizations just care about the range. If more precise information is desired, it would make sense to augment the range metadata to be able to provide that. If that is done, then this optimization could easily be augmented to support it.<br>

<br></div><div>Dan<br><br></div></div></div></div>