similar to: [RFC] Use of saturating intrinsics

Hello, This is an RFC for adding intrinsics which perform saturating signed/unsigned left shift. There is currently a patch on Phabricator here: https://reviews.llvm.org/D83216 The intrinsics are of the form i32 @llvm.sshl.sat.i32(i32, i32) i32 @llvm.ushl.sat.i32(i32, i32) <4 x i32> @llvm.sshl.sat.v4i32(<4 x i32>, <4 x i32>) <4 x i32>

Hi all, The patches linked below introduce a new family of intrinsics, for integer saturation: @llvm.usat, and @llvm.ssat (unsigned/signed). Quoting the added documentation: %r = call i32 @llvm.ssat.i32(i32 %x, i32 %n) is equivalent to the expression min(max(x, -2^(n-1)), 2^(n-1)-1), itself implementable as the following IR: %min_sint_n = i32 ... ; the min. signed integer of

On Thu, Jan 15, 2015 at 12:42 AM, Philip Reames <listmail at philipreames.com> wrote: > At a very high level, why do we need these intrinsics? In short, to catch sequences you can't catch in the SelectionDAG. > What is the use case? What are typical values for N? Typically, you get this from (a little overlapping) compression, DSP, or pixel-handling code. Off the top of my

On Thu, Jan 15, 2015 at 2:33 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > A couple of questions: > > 1) Should this really be an intrinsic and not a flag on add? The add > instruction already allows overflow to be either undefined or defined to > wrap. Making it defined to saturate seems a natural extension. > I don't think this should be a flag on

Hi everyone! The fptoui/fptosi instructions are currently specified to return a poison value if the rounded-towards-zero floating point number cannot be represented by the target integer type. The motivation for this behavior is that overflowing float to int casts in C are undefined behavior. However, many newer languages prefer to have a float to integer cast that is well-defined for all input

I have encountered a need for float-to-int casts that saturate to min/max when the value is out of the range of the target type. It seems that there is no intrinsic to do this, currently, but on IRC it was pointed out that a patch [1] has been proposed to implement this functionality in exactly the way that I was looking for. It looks like the discussion has died out but I was hoping maybe to

I would be interested in learning what the set of used semantics for float-to-int conversion is. If the only two used are 1) undefined behavior if unrepresentable and 2) saturate to int_{min,max} with NaN going to zero, then I think it makes sense to expose both of those natively in the IR. If the set is much larger, I think separate intrinsics for each behavior would make sense. It would be nice

On 2018-08-22 11:32, John McCall wrote: > >> On Aug 22, 2018, at 4:38 AM, Bevin Hansson <bevin.hansson at ericsson.com> wrote: >> >> >> >> On 2018-08-22 05:56, John McCall via llvm-dev wrote: >>>> On Aug 21, 2018, at 6:20 PM, Leonard Chan <leonardchan at google.com> wrote: >>>> If we were to create a new type down the line, I

Chris Lattner wrote: > On Feb 8, 2009, at 5:54 PM, Paul Schlie wrote: >> Are overflow behavior tags meant to enable the specification of a >> particular instruction's required or presumed overflow behavior? > > I'm not sure what you mean. The overflow tags specify what happens if > overflow happens (defined wrapping, defined saturating, or undefined > behavior),

Are overflow behavior tags meant to enable the specification of a particular instruction's required or presumed overflow behavior? If a required overflow behavior, then it follows that the target must correspondingly implement the behavior; neither natively or emulated? If a presumed overflow behavior, is the target meant to preferably implement or emulate the same; or is it merely meant to

On Fri, Jun 17, 2011 at 3:08 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Hi all, > > I'm proposing integer saturation intrinsics. > > def int_ssat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; > def int_usat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; > > The first operand is the integer value

On 01/14/2015 04:16 PM, Ahmed Bougacha wrote: > On Thu, Jan 15, 2015 at 12:42 AM, Philip Reames > <listmail at philipreames.com> wrote: >> At a very high level, why do we need these intrinsics? > In short, to catch sequences you can't catch in the SelectionDAG. > >> What is the use case? What are typical values for N? > Typically, you get this from (a little

If we were to create a new type down the line, I think the main features that would distinguish them from other types are the arbitrary width and scale. Saturation can be handled through instructions since saturation really only takes effect after an operation and doesn’t really describe anything about the bits in the resulting type. Signage can similarly be managed through operations and would be

On Jun 17, 2011, at 3:42 PM, Eli Friedman wrote: > On Fri, Jun 17, 2011 at 3:08 PM, Evan Cheng <evan.cheng at apple.com> wrote: >> Hi all, >> >> I'm proposing integer saturation intrinsics. >> >> def int_ssat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; >> def int_usat : Intrinsic<[llvm_anyint_ty],

On 5/16/2017 6:30 AM, Sanjay Patel wrote: > Thanks for posting this question, Julia. > > I had a similar question about a signed min/max variant here: > http://lists.llvm.org/pipermail/llvm-dev/2016-November/106868.html > > The 2nd version in each case contains a canonical max/min > representation in IR, and this could enable more IR analysis. > A secondary advantage is

We would like to discuss the possibility of adding support for fixed point operations, either through new types, instructions, or intrinsics. This is an extension to a previous proposal (http://lists.llvm.org/pipermail/cfe-dev/2018-April/057756.html) for implementing fixed point arithmetic entirely in clang, but John McCall brings up good points in the comments thread of

> The plan is to form calls to these intrinsics in InstCombine. Legalizer > can expand these intrinsics if they are not legal. The expansion should > be fairly straight forward and produce code that is at least as good as > what LLVM is currently generating for these code sequence. SSAT/USAT may set the Q (saturation) flag, which might cause problems for anyone relying on explicitly

On Wed, Dec 1, 2010 at 8:11 AM, me22 <me22.ca at gmail.com> wrote: > On Tue, Nov 30, 2010 at 05:48, Jonas Paulsson <jnspaulsson at hotmail.com> wrote: >> May I ask then, what could one expect from various optimizations when using >> intrinsics to support the fixed point type? LTO, Value optimizations, mem ?? >> > > Can you not just lower your fixed-point

Hi all, I'm proposing integer saturation intrinsics. def int_ssat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; def int_usat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; The first operand is the integer value being saturated, and second is the saturation bit position. For scalar integer types, the semantics are: int_ssat: x <

On 2018-08-22 05:56, John McCall via llvm-dev wrote: >> On Aug 21, 2018, at 6:20 PM, Leonard Chan <leonardchan at google.com> wrote: >> If we were to create a new type down the line, I think the main >> features that would distinguish them from other types are the >> arbitrary width and scale. Saturation can be handled through >> instructions since saturation