RFC: min/max/abs IR intrinsics

[Owen Anderson]

We already have @llvm.minnum and @llvm.maxnum for floating point types.

—Owen

> On Apr 23, 2015, at 7:42 AM, James Molloy <james at jamesmolloy.co.uk> wrote:
> 
> 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 think:
>   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?
> 
> Cheers,
> 
> James
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits