search for: saturation

On 11.01.2015 20:19, Ilia Mirkin wrote: > On Sun, Jan 11, 2015 at 12:27 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> >> On 11.01.2015 01:58, Ilia Mirkin wrote: >>> On Fri, Jan 9, 2015 at 8:24 PM, Tobias Klausmann >>> <tobias.johannes.klausmann at mni.thm.de> wrote: >>>> Folding for conversions:

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...

> One thing I've noticed so far in the filter_mem2 code is the calls to > SATURATE(x, 805306368). 805306368 is 0x30000000. I was expecting that > to be on a bit boundary, say 0x3fffffff? In which case the arithmetic > saturation logic could be used. I don't think it would make that big of a difference, since the saturation is outside of the inner loop. If it's that critical, you could probably remove the saturation completely and just make sure your signals are scaled properly (i.e. not too close to saturation)....

On 11.01.2015 01:58, Ilia Mirkin wrote: > On Fri, Jan 9, 2015 at 8:24 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> Folding for conversions: F32->(U{16/32}, S{16/32}) and (U{16/32}, {S16/32})->F32 >> >> Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> >> --- >> V2: beat me, whip me, split

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 being saturated, and second is the saturation...

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 sca...

> -----Original Message----- > From: r-help-bounces at stat.math.ethz.ch > [mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of David Firth > Sent: Tuesday, March 16, 2004 1:12 PM > To: Paul Johnson > Cc: r-help at r-project.org > Subject: Re: [R] glm questions > > > Dear Paul > > Here are some attempts at your questions. I hope it's of some help.

Hi all, While tinkering with saturation instructions, I hit problems with the cost model calculations. The loop vectorizer cost model accumulates the individual TTI cost model of each instruction. For saturating arithmetic, this is a gross overestimate, since you have 2 sexts (inputs), 2 icmps + 2 selects (for the saturation), and a tr...

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], [LLVMMatchType<0>, llvm_i32_ty]>; >> >> The first operand is the integer value being saturated, and se...

Hello all again, take 2. Over in D68651 I would like to make code that attempt to saturate an value (using higher bitwidth integers) use a saturating intrinsic instead. Something like this: https://godbolt.org/z/9knBnP As can be seen, the unsigned cases are already being matched to llvm.uadd.sat intrinsics. I am hoping to extend that to the signed cases. This has numerous benefits including

...s, Frank -----Urspr?ngliche Nachricht----- Von: "Jean-Marc Valin" <jean-marc.valin@usherbrooke.ca> Gesendet: 02.02.08 06:26:08 An: speex-dev <speex-dev@xiph.org> Betreff: Re: FW: Re: [Speex-dev] Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation??? Frank Lorenz a ?crit : > And yes, the same "overflow" happens even when I disable Blackfin ASM > optimizations. Indeed, that shouldn't happen. Just to make sure I understand, so far there's two problems: 1) DIV32_16() in Blackfin assembly causes problems 2) The resampl...

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>

...ome potentially beneficial > optimisations. > > David > > > On 14 Jan 2015, at 22:08, Ahmed Bougacha <ahmed.bougacha at gmail.com> > wrote: > > > > 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: &...

On 11.01.2015 20:57, Ilia Mirkin wrote: > On Sun, Jan 11, 2015 at 2:56 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> >> On 11.01.2015 20:19, Ilia Mirkin wrote: >>> On Sun, Jan 11, 2015 at 12:27 PM, Tobias Klausmann >>> <tobias.johannes.klausmann at mni.thm.de> wrote: >>>> >>>> On 11.01.2015 01:58,

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 consistent with the separation in signed and unsigned int oper...

Folding for conversions: F32->(U{16/32}, S{16/32}) and (U{16/32}, {S16/32})->F32 Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 109 +++++++++++++++++++++ 1 file changed, 109 insertions(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp

...Urspr?ngliche Nachricht----- Von: "Jean-Marc Valin" <jean-marc.valin@usherbrooke.ca> Gesendet: 06.02.08 11:07:46 An: Frank Lorenz <Frank_wtal@web.de> CC: speex-dev@xiph.org Betreff: Re: [Speex-dev] Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation??? Frank Lorenz a ?crit : > I just started to examine the DIV32_16 function (Blackfin ASM > version), and wondered why the return value of the function inside > 'fixed_bfin.h' is of type 'spx_word16_t', but the local variable > 'res' which is returned by this f...

...; to get 1.2rc1 (or latest git) working. Hi, I found the problem preventing to use version >= 1.2beta3. After the patch for SSE, resampler_basic_direct_single() has been modified to use float instead of the generic spx_word16_t type... Anyway, float implementation is perfect, because handling saturation when converting back to int. After reconverting to spx_word16_t, the fixed point version is now good, except for saturation. Using MULT16_16 for convolution, we have 1 guard bit, which seems to be enough in resampler_basic_direct_single(), so we can saturate before storing. But in resampler_basi...

...Von: "Jean-Marc Valin" > <jean-marc.valin@usherbrooke.ca> Gesendet: 01.02.08 12:11:39 An: > Frank Lorenz <Frank_wtal@web.de> CC: speex-dev@xiph.org Betreff: Re: > FW: Re: [Speex-dev] Problem with Blackfin assembly optimizations -- > bug in fixed_bfin.h / resampler saturation??? > > > Frank Lorenz a ?crit : >> didn't get a reply to my last post (see below) -- do you have no >> idea what happens here? > > Sorry, been quite busy lately. Still have a backlog of things to > respond to (sorry to others as well), some of it quite old. >...

Folding for conversions: F32->(U{16/32}, S{16/32}) and (U{16/32}, {S16/32})->F32 Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- V2: beat me, whip me, split out F64 .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 81 ++++++++++++++++++++++ 1 file changed, 81 insertions(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp