[PATCH] Add Integer Saturation Intrinsics.

[Ahmed Bougacha]

On Sat, Mar 21, 2015 at 3:01 AM, Renato Golin <renato.golin at linaro.org> wrote:
> My problem with implementing this on the ARM side is that the code won't be useful anywhere else.

If that's what you're referring to, when I mentioned keeping the ARM
intrinsics, I meant converting the already-existing arm.usat/ssat
intrinsics to the new target-independent ones (they have similar
semantics).

Same thing as all the AutoUpgrades for target-specific intrinsics that
now have proper IR representations.

> Maybe, a better approach would be to have them just as special DAG nodes, created by a special DAG pass that only run for selected back-ends, instead of an IR intrisic, or an ARM-specific late pass.

The way I see it, there are two solutions:
- the intrinsics proposed here and in the RFC, and equivalent ISD
nodes.  The intrinsics would be generated with InstCombines.
- no intrinsic, just ISD nodes, with matching done in DAGCombines
(perhaps with CodeGenPrepare's help).

The backend part is the same.  The only difference is that with
intrinsics you need to legalize them [0] (and support them in
fast-isel?).


At first it seemed obvious to me the intrinsic solution was the best,
but now I'm not so sure.  Reading the .with.overflow thread, I'm more
and more convinced intrinsics should only be used to completely bypass
the mid-level optimizers, and this isn't what we're doing here.
One solution could be to have a dedicated intrinsic-generating
combiner, that runs later than the first round of InstCombine.
"later" is the tricky part.

So, yeah, I could be convinced either way, more opinions welcome!

The way I'd frame the question is: we don't have intrinsics for
max/min/abs;  why would we have them for sat?  The obvious answer is
that it's a bit more involved: is that enough?

-Ahmed

[0] http://reviews.llvm.org/D6977

> I'm assuming the semantics of such pass would be very similar on other back-ends...
>
>
> REPOSITORY
>   rL LLVM
>
> http://reviews.llvm.org/D6976
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>