[llvm-dev] Proposed new min and max intrinsics

[Thomas Lively via llvm-dev]

I just wanted to bump this to see if anyone has any input. I would really
like to get these landed soon if there are no objections.

On Tue, Oct 2, 2018 at 10:59 AM Thomas Lively <tlively at google.com> wrote:

> Hi everyone,
>
> I have implemented a pair of new target-independent intrinsics and it
> would be great if I could get some feedback about whether we want to merge
> them in. The intrinsics are @llvm.minimum and @llvm.maximum, and are IEEE
> 754-2018 analogues to @llvm.minnum and @llvm.minnum. The differences are
> that the new intrinsics propagate NaNs and consider -0.0 to be strictly
> less than 0.0. The names are taken from the corresponding operations in the
> IEEE 754-2018 draft specification. You can find the patches implementing
> the intrinsics in the stack starting at https://reviews.llvm.org/D52764.
>
> The context for this proposed change is that the WebAssembly backend needs
> these intrinsics to make its min and max instructions available at the IR
> level, since they follow the draft IEEE 754-2018 semantics. Originally I
> was thinking of implementing the intrinsics as @wasm.min and @wasm.max, but
> since these operations are in the draft standard, I thought they might be
> more appropriate as target-independent. If the community does not want to
> merge these intrinsics now, I can always go back to making them
> wasm-specific.
>
> The way I have currently implemented the intrinsics, they lower directly
> to the fminnan and fmaxnan ISel DAG nodes, which already existed. As far as
> I can tell, these DAG nodes are only used in the ARM, AArch64, SystemZ, and
> WebAssembly backends and lower to instructions that follow the draft IEEE
> 754-2018 semantics, so these targets do not need to take any action to
> support the new intrinsics. Before this change, the only way an ISel DAG
> could contain fminnan or fmaxnan nodes was if they were produced by a
> select pattern. The select pattern matching code does not produce mins or
> maxes if it would be possible that both arguments could be zeros, so
> tightening the semantics of fminnan and fmaxnan to match IEEE 754-2018 will
> not invalidate any existing code.
>
> Best,
>
> Thomas Lively
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181010/50988250/attachment.html>