[PATCH/RFC] New TLI option for fast selects

[Eric Christopher]

This seems fairly reasonable, couple of nits:

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.

b) Argument names: Can you make them a little more descriptive and document
them?

c) Got an in-tree user where this would be useful?

-eric

On Thu, Apr 30, 2015 at 1:47 PM escha <escha at apple.com> wrote:

> 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.
>
> 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.
>
> 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?
>
> Any thoughts on the implementation?
>
> — escha
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150504/181dc4cd/attachment.html>