RFC: min/max/abs IR intrinsics

James Molloy james at jamesmolloy.co.uk
Thu Apr 23 07:42:50 PDT 2015

Hi all,

I've just started again on trying to solve the problem of getting decent
code generation for min, max and abs idioms as used by the programmer and
as emitted by the loop vectorizer.

I've been looking at doing this as a target DAGCombine, but actually I
  1. it's incredibly complex to do at that stage and it limits all the work
I do to just one target.
  2. It's also much more difficult to test.
  3. The loop and SLP vectorizers still don't have a cost model for them -
they're just seen as compare+selects.

So my proposal is:
  * To add new intrinsics for minimum, maximum and absolute value. These
would have signed int/unsigned int/float variants and be valid across all
numeric types.
  * To add a pass fairly early in the pipeline to idiom recognize and
create intrinsics. This would be controllable per-backend - if a backend
doesn't have efficient lowering for these operations, perhaps it's best not
to do the idiom recognition.

The cost model would then fall out in the wash, because we already have a
cost model for intrinsics, it would be as simple as adding new
instructions. Because we idiom recognize at the IR stage instead of the
SDAG stage, we also wouldn't have to rely on the min/max idioms being in
canonical "select" form; we could match a branch sequence also.

What do you think? Is this an acceptable proposal?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150423/e513c7e5/attachment.html>

More information about the llvm-commits mailing list