RFC: min/max/abs IR intrinsics

[James Molloy]

Hi Owen,

Thanks for the clarification. I'm happy using maxnum/minnum (for floats) in
that case!

James

On Thu, 23 Apr 2015 at 19:50 Owen Anderson <resistor at mac.com> wrote:

> 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> 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/2865655e/attachment.html>