RFC: min/max/abs IR intrinsics

Owen Anderson resistor at mac.com
Thu Apr 23 11:50:26 PDT 2015


It’s not really about strictness/orderedness, just that different standards mandate different things.  They match the IEEE definition, as well as C99 and most GPU languages.  Other languages (notably, Java) disagree.

—Owen

> On Apr 23, 2015, at 11:46 AM, James Molloy <james at jamesmolloy.co.uk> wrote:
> 
> Hi Owen,
> 
> So my impression was that minnum and maxnum aren't exactly min/max, depending on strictness and ordered-ness. For example, AArch64 has both FMIN and MINNUM instructions that behave subtly differently on NaN and -0.0.
> 
> My intention was to select minnum where possible, but it's useful to have a strict corollary.
> 
> James
> 
> On Thu, 23 Apr 2015 at 19:28 Owen Anderson <resistor at mac.com <mailto:resistor at mac.com>> wrote:
> 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 <mailto: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 <mailto:llvm-commits at cs.uiuc.edu>
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
> 

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


More information about the llvm-commits mailing list