RFC: min/max/abs IR intrinsics

[Gerolf Hoflehner]

Hi James,

I had looked into this recently and prepared a patch to recognize vmin/vmax idioms on AArch64 at the target ISEL level. Just put it out there for consideration. 

I had also tried to add a pattern in the td file but eventually decided against more complex patterns involving BSL.

There are many min/max optimizations and intrinsics spread across the code. With your approach do you plan to clean up and unify the bits and pieces?

I was wondering if there were a performance advantage to have a higher level representation of min/max. My hunch is that recognizing the idiom at the low-level is ‘good enough’.


Cheers
Gerolf


> 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