search for: saturate

...t;>>> + bld.setPosition(i, true); /* make sure bld is init'ed */ >>>> + switch(i->dType) { >>>> + case TYPE_U16: >>>> + switch (i->sType) { >>>> + case TYPE_F32: >>>> + if (i->saturate) >>>> + res.data.u16 = util_iround(CLAMP(imm0.reg.data.f32, 0, >>>> + UINT16_MAX)); >>> Where did this saturate stuff come from? It doesn't make sense to >>> saturate to a non-float dtype. I...

...nsics. >From there, we can generate several new instructions, more efficient than their expanded counterpart. Locally, I have worked on: - ARM: the SSAT/USAT instructions (scalar) - AArch64: the SQ/UQ ADD/SUB AArch64 instructions (vector/scalar saturating arithmetic) - X86: PACK SS/US (vector, saturate+truncate) - X86: PADD/SUB S/US (vector, saturating arithmetic) Anyway, let's first agree on the intrinsics, so that further development is done on trunk. Thanks! -Ahmed

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

...case OP_CVT: { >> + Storage res; >> + bld.setPosition(i, true); /* make sure bld is init'ed */ >> + switch(i->dType) { >> + case TYPE_U16: >> + switch (i->sType) { >> + case TYPE_F32: >> + if (i->saturate) >> + res.data.u16 = util_iround(CLAMP(imm0.reg.data.f32, 0, >> + UINT16_MAX)); > Where did this saturate stuff come from? It doesn't make sense to > saturate to a non-float dtype. I'd go ahead and just > asse...

...t; 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 < -(1 << (bit-1)) ? -(1 << (bit-1)) : (x > (1 << (bit-1))-1 ? (1 << (bit-1))-1 : x) > int_usat: x < 0 ? 0 : (x > (1 << bit)-1 : (1 &...

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 < -(1 << (bit-1)) ? -(1 << (bit-1)) : (x > (1 << (bit-1))-1 ? (1 << (bit-1))-1 : x) int_usat: x < 0 ? 0 : (x > (1 << bit)-1 : (1 << bit)-1 : x) e....

...> Dear Paul > > Here are some attempts at your questions. I hope it's of some help. > > On Tuesday, Mar 16, 2004, at 06:00 Europe/London, Paul Johnson wrote: > > > Greetings, everybody. Can I ask some glm questions? > > > > 1. How do you find out -2*lnL(saturated model)? > > > > In the output from glm, I find: > > > > Null deviance: which I think is -2[lnL(null) - lnL(saturated)] > > Residual deviance: -2[lnL(fitted) - lnL(saturated)] > > > > The Null model is the one that includes the constant only > (plus...

...all fold alway. With an intrinsic, you'd end up with a better estimate; however, I'm trying to see what problems we would encounter without intrinsics, and I think this is the biggest one. Note that AFAICT, costs for min/max patterns (icmp+iselect) are also overestimated, but not as much as saturate. Proposal: Add a method, part of the vector API of TargetTransformInfo, for multi-instruction cost computation. It would take a scalar Instruction, and a reference to a set of Instruction. If it's able to match a min/max/saturate/.., it adds all the matched instructions to the set, so the...

...nteger 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 < -(1 << (bit-1)) ? -(1 << (bit-1)) : (x > (1 << (bit-1))-1 ? (1 << (bit-1))-1 : x) >> int_usat: x < 0 ? 0 : (x > (1...

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

...lue and the biggest >> possible positive value. > > This is definitely bad. Can you send me an example file. Also, can > you reproduce that problem without the Blackfin assembly? > >> Does the resampler use the hardware saturation available on >> Blackfin, or does it saturate by software? Can you point me to the >> place I have to look at inside the resampler function for >> saturation? > > Saturation is entirely done in software. The resampler does the > conversion using the WORD2INT macro. > > Jean-Marc > > > > ____________...

...rand. As with regular left shift instructions, the second operand is an unsigned quantity and must be less than the integer bitwidth. If the true result of the operation (given infinite precision) lies outside of the maximum or minimum representable value of the signed/unsigned integer, the result saturates to the maximum or minimum depending on the sign of the shifted value. These are useful for implementing the Embedded-C fixed-point arithmetic support in Clang, as previously detailed and discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-August/125433.html http://lists.llvm.org/piperma...

...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 add. Flags are designed such that the middle-end may be ignorant of them and nothing bad might happen, it is always safe to ignore or drop flags when doing so is convenient (for a concrete example, take a look at reassocia...

...true); /* make sure bld is init'ed */ >>>>>> + switch(i->dType) { >>>>>> + case TYPE_U16: >>>>>> + switch (i->sType) { >>>>>> + case TYPE_F32: >>>>>> + if (i->saturate) >>>>>> + res.data.u16 = util_iround(CLAMP(imm0.reg.data.f32, 0, >>>>>> + UINT16_MAX)); >>>>> Where did this saturate stuff come from? It doesn't make sense to >>>>> sa...

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

...p;imm0, int s) i->op = OP_MOV; break; } + case OP_CVT: { + Storage res; + bld.setPosition(i, true); /* make sure bld is init'ed */ + switch(i->dType) { + case TYPE_U16: + switch (i->sType) { + case TYPE_F32: + if (i->saturate) + res.data.u16 = util_iround(CLAMP(imm0.reg.data.f32, 0, + UINT16_MAX)); + else + res.data.u16 = util_iround(imm0.reg.data.f32); + break; + case TYPE_F64: + if (i->saturate) +...

...> biggest possible positive value. >> This is definitely bad. Can you send me an example file. Also, can >> you reproduce that problem without the Blackfin assembly? >> >>> Does the resampler use the hardware saturation available on >>> Blackfin, or does it saturate by software? Can you point me to >>> the place I have to look at inside the resampler function for >>> saturation? >> Saturation is entirely done in software. The resampler does the >> conversion using the WORD2INT macro. >> >> Jean-Marc >> >&g...

...ntation 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_basic_interpolate_single(), we can also saturate in the cubic interpolation part. So I propose shifting the 32 bits accumulators 1 bit right before this operation. --> Implemented and tested in resample4.patch About the 4 accumulators: Simple DSPs have only 2...

...lue and the biggest >> possible positive value. > > This is definitely bad. Can you send me an example file. Also, can > you reproduce that problem without the Blackfin assembly? > >> Does the resampler use the hardware saturation available on >> Blackfin, or does it saturate by software? Can you point me to the >> place I have to look at inside the resampler function for >> saturation? > > Saturation is entirely done in software. The resampler does the > conversion using the WORD2INT macro. > > Jean-Marc > > > > ____________...

...p;imm0, int s) i->op = OP_MOV; break; } + case OP_CVT: { + Storage res; + bld.setPosition(i, true); /* make sure bld is init'ed */ + switch(i->dType) { + case TYPE_U16: + switch (i->sType) { + case TYPE_F32: + if (i->saturate) + res.data.u16 = util_iround(CLAMP(imm0.reg.data.f32, 0, + UINT16_MAX)); + else + res.data.u16 = util_iround(imm0.reg.data.f32); + break; + default: + return; + } + i...