Displaying 20 results from an estimated 9000 matches similar to: "[LLVMdev] overflow + saturation stuff"
2009 Feb 09
1
[LLVMdev] overflow + saturation stuff
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
2009 Feb 08
0
[LLVMdev] overflow + saturation stuff
Hi Chris,
Would it be better to split add into multiple opcodes instead of using
SubclassData bits? Compare this:
switch (I->getOpcode()) {
case Instruction::Add: {
switch (cast<Add>(I)->getOverflowBehavior()) {
case AddInstruction::Wrapping:
// ...
case AddInstruction::UndefinedSigned:
// ...
case
2009 Feb 07
6
[LLVMdev] overflow + saturation stuff
Edwin was asking about how we should handle PR3328, how we should make
GEP respect -fwrapv etc. I wrote up some thoughts here if anyone is
interested:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt
-Chris
2015 Jan 14
5
[LLVMdev] [RFC] Integer Saturation Intrinsics
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
2015 Jan 15
3
[LLVMdev] [RFC] Integer Saturation Intrinsics
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
2011 Jun 17
0
[LLVMdev] RFC: Integer saturation intrinsics
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
2015 Jan 15
2
[LLVMdev] [RFC] Integer Saturation Intrinsics
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
2011 Jun 17
2
[LLVMdev] RFC: Integer saturation intrinsics
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],
2009 Feb 08
0
[LLVMdev] overflow + saturation stuff
On 07 Feb 2009, at 23:17, Chris Lattner wrote:
> Edwin was asking about how we should handle PR3328, how we should make
> GEP respect -fwrapv etc. I wrote up some thoughts here if anyone is
> interested:
> http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt
The proposal suggests to change/split the existing sub/add/mul
opcodes. This makes me wonder to what extent it is
2009 Feb 08
0
[LLVMdev] overflow + saturation stuff
Sounds ambitious! A comprehensive, efficient trapv would be excellent.
gcc's implementation seems quite incomplete, for example it fails to trap
overflows in the constant folder.
John Regehr
2009 Feb 09
0
[LLVMdev] overflow + saturation stuff
Further, with respect to proposed rotate operations, as with add's etc.
carry semantics; all forms of shift/rotate may be specified with a single
shift instruction with a tag specifying the source of in-shift bits (being
that shifted out, dup, or 0); if an operation's tag is meant to affect the
semantics of the specified operation.
2009 Feb 09
0
[LLVMdev] overflow + saturation stuff
On Feb 8, 2009, at 11:33 AM, Chris Lattner wrote:
>
> On Feb 8, 2009, at 8:58 AM, Dan Gohman wrote:
>
>> Hi Chris,
>>
>> Would it be better to split add into multiple opcodes instead of
>> using
>> SubclassData bits?
>
> No, I don't think so. The big difference here is that (like type)
> "opcode" never changes for an instruction
2009 Feb 08
0
[LLVMdev] overflow + saturation stuff
On 08 Feb 2009, at 14:41, Gordon Henriksen wrote:
> On 2009-02-08, at 05:59, Jonas Maebe wrote:
>
>> The proposal suggests to change/split the existing sub/add/mul
>> opcodes. This makes me wonder to what extent it is (currently, or
>> ever) advisable for an external compiler to generate LLVM IR. Is
>> there a plan to stabilise at some point and guarantee backwards
2011 Jun 18
0
[LLVMdev] RFC: Integer saturation intrinsics
> 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
2009 Feb 08
2
[LLVMdev] overflow + saturation stuff
On Feb 8, 2009, at 8:58 AM, Dan Gohman wrote:
> Hi Chris,
>
> Would it be better to split add into multiple opcodes instead of using
> SubclassData bits?
No, I don't think so. The big difference here is that (like type)
"opcode" never changes for an instruction once it is created. I
expect that optimizations would want to play with these (e.g. convert
them to
2009 Feb 08
2
[LLVMdev] overflow + saturation stuff
On 2009-02-08, at 05:59, Jonas Maebe wrote:
> The proposal suggests to change/split the existing sub/add/mul
> opcodes. This makes me wonder to what extent it is (currently, or
> ever) advisable for an external compiler to generate LLVM IR. Is
> there a plan to stabilise at some point and guarantee backwards
> compatibility to a certain extent, or should compilers that are
2011 Jun 17
5
[LLVMdev] RFC: Integer saturation intrinsics
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 <
2017 May 16
2
[RFC] Canonicalization of unsigned subtraction with saturation
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
2019 Oct 10
2
[RFC] Use of saturating intrinsics
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
2017 May 16
2
[RFC] Canonicalization of unsigned subtraction with saturation
Hi,
This message is a result of a discussion of backend optimization for sub(max) pattern(https://reviews.llvm.org/D25987), which can be either converted to unsigned min-max or unsigned saturation instruction(if the target supports it).
Currently these versions of the code produce different IR(and we need to manage both types in backend):
(1.16)
void foo(unsigned short *p, unsigned short max,