<div dir="ltr">This seems fairly reasonable, couple of nits:<br><br><div>a) Routine name: theoretically it should begin with a lower case letter. I know it probably doesn't match anything around it then. I don't know what we want to do about this, but I wouldn't complain much.</div><div><br></div><div>b) Argument names: Can you make them a little more descriptive and document them?</div><div><br></div><div>c) Got an in-tree user where this would be useful?</div><div><br></div><div>-eric</div></div><br><div class="gmail_quote">On Thu, Apr 30, 2015 at 1:47 PM escha <<a href="mailto:escha@apple.com">escha@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There’s a number of DAG transforms that are suboptimal on architectures with extremely fast selects, e.g. those with actual select instructions mapping relatively cleanly to select_cc. An example would be integer abs(): on an ideal architecture without a select it might be three instructions (cmp, sub, cmov), so the three-operation canonicalization likely won’t hurt even in the worst case. But on an architecture with a select, we’re going from 2 instructions to 3, which significantly increases instruction count, and it’s difficult to “go back” from the new instruction sequence to the select.<br>
<br>
I’m not sure this patch actually caught all of them; there might be others, since I didn’t check them all. My logic here was to put a check on every transform which creates more nodes than it consumes in order to eliminate a select. On an out of tree target this saves a number of instructions (with no regressions on any test) by making the included TLI return “false” for that target.<br>
<br>
This could also open up more optimizations in the future that assume selects are fast, e.g. one select DAG node is roughly equivalent to one real instruction. I wonder if any of the in-tree GPU backends would find something like this useful?<br>
<br>
Any thoughts on the implementation?<br>
<br>
— escha<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</blockquote></div>