[PATCH/RFC] New TLI option for fast selects

[Eric Christopher]

On Tue, May 5, 2015 at 10:36 AM escha <escha at apple.com> wrote:

>
> > On May 4, 2015, at 3:40 PM, Eric Christopher <echristo at gmail.com> wrote:
> >
> > 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?
>
> One thing I was curious about with regards to this is we *already* have a
> “fast select” boolean TLI option — but it seems to represent something a
> bit different, that is (I think) whether we have a cmov-equivalent or
> selects will have to be turned into branches.
>
> Thus, we have three levels of speed:
> 1) an actual select instruction
> 2) we have a fast compare + cmov
> 3) selects are slow
>
> and this patch is kind of adding 1) to the existing 2) and 3). Do we need
> to have an entire function to decide whether a given select is fast (might
> be useful on architectures that have somewhat-limited select instructions?)
> or should we just make a third speed level in addition to the current two?
>
> I found it kind of gross that I had to pass all five arguments (instead of
> just one select node) to the TLI, but unfortunately a lot of the time it
> seems we don’t have an actual select node already created at this point :-/
>
>
*nod* Ideally I think we'd want to have a cost function, blah blah blah,
maybe a tri-state is good enough for now (1, 0, -1 or an enum).


> >
> > c) Got an in-tree user where this would be useful?
>
> I was kinda hoping someone from R600 would know, since I think I recall
> R600 having a select instruction? I figure it’d be useful to have some
> feedback from another architecture to see what they’d find useful here,
> since I’m not big on the idea of shoving in something solely based on an
> OOT arch’s needs (plus, I probably haven’t even fully thought through its
> possible benefits either).
>

Yeah. Maybe poke them and the nvptx guys?

-eric


>
> — escha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150505/e8ed6222/attachment.html>