RFC: min/max/abs IR intrinsics

[James Molloy]

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> 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>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150423/572951aa/attachment.html>