search for: matchselectpattern

...Tracking VectorUtils SelectionDAGBuilder But I don't think it's fair to view those additions as pure added cost. As an example, consider that we have to add hacks to EarlyCSE to recognize multi-IR-instruction min/max/abs patterns. Intrinsics just work as-is there. So if you search for 'matchSelectPattern', you get an idea (I see 32 hits in 10 files) of the cost of *not* having intrinsics for those operations that we've decided are not worthy of intrinsics. On Wed, May 16, 2018 at 2:20 PM, John Regehr via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 5/16/18 1:58 PM, Sanjay...

...onDAGBuilder > > But I don't think it's fair to view those additions as pure added cost. > As an example, consider that we have to add hacks to EarlyCSE to > recognize multi-IR-instruction min/max/abs patterns. Intrinsics just > work as-is there. So if you search for 'matchSelectPattern', you get an > idea (I see 32 hits in 10 files) of the cost of *not* having intrinsics > for those operations that we've decided are not worthy of intrinsics. > > > On Wed, May 16, 2018 at 2:20 PM, John Regehr via llvm-dev > <llvm-dev at lists.llvm.org <mailto:l...

On 5/16/18 1:58 PM, Sanjay Patel via llvm-dev wrote: > An informal metric might be: if the operation is supported as a > primitive op or built-in in source languages and it is supported as a > single target instruction, can we guarantee that 1-to-1 translation > through optimization? It seems perfectly reasonable for LLVM users to expect this to happen reliably. I'd like to

...#39;t think it's fair to view those additions as pure > added cost. As an example, consider that we have to add hacks > to EarlyCSE to recognize multi-IR-instruction min/max/abs > patterns. Intrinsics just work as-is there. So if you search > for 'matchSelectPattern', you get an idea (I see 32 hits in 10 > files) of the cost of *not* having intrinsics for those > operations that we've decided are not worthy of intrinsics. > > > On Wed, May 16, 2018 at 2:20 PM, John Regehr via llvm-dev > <llvm-dev at...

Hi all, Say we have this IR: %1 = icmp slt i16 %x, 0 %.x = select i1 %1, i16 0, i16 %x This is the canonical form of what is effectively max(x, 0). From what I can tell LLVM has no facilities to determine from this code that %.x >= 0, so (for example) an SExt on %.x will not be converted to a ZExt. I'm interested in seeing what sorts of changes would be needed to recognize this pattern

Thanks, Hal and Matt for the feedback. As usual, my instincts about canonicalization were probably wrong. :) I thought that @max1 vs. @max3 would be viewed as an unknowable trade-off between reducing the dependency chain and the pseudo-canonical min/max form, so we'd add intrinsics, and defer that decision to the backend. I'll wait to see if there are any other arguments presented.