[llvm-dev] What is the status regarding min/max intrinsics?

[Sanjay Patel via llvm-dev]

We're getting closer to canonicalizing to the intrinsics...
But there are still some missing optimizations (mostly in instcombine I
think) that we are hoping to address to reduce the chance of regressions:

This is the most current view of what's left:
https://reviews.llvm.org/D98152

We've also been tracking the work with:
https://llvm.org/PR46915

On Tue, May 4, 2021 at 4:59 AM Björn Pettersson A via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> The llvm.smin, llvm.smax, llvm.umin and llvm.umax intrinsics were
> introduced quite some time ago.
>
> As far as I known we still don't canonicalize IR to use those
> intrinsics (but I suppose that is the end goal), nor do we
> canonicalize by doing a reverse transform into a select.
>
> Are there any known limitations in support for the min/max intrinsics
> that prevents us from using them or trying to canonicalize IR into
> using the intrinsics?
> (and if so, shouldn't we canonicalize into a select-pattern if that
> form still is "better")
>
> Main reason for asking is that I'd like to know if it is safe
> to simplify clang/opt to use the min/max intrinsics directly
> instead of emitting a select-kind-of-pattern. Or is it a huge risk
> that I end up with regressions due to optimizers not understanding
> the min/max intrinsics yet?
>
> Regards,
> Björn
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210504/afb60d25/attachment.html>