[PATCH/RFC] New TLI option for fast selects

[escha]

> 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 :-/

> 
> 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).

— escha