search for: sexted

Displaying 20 results from an estimated 656 matches for "sexted".

Did you mean: setted
2017 Jun 02
5
RFC: Killing undef and spreading poison
Sanjoy, My answer is that step 3, commuting the multiply with the sign-extends, is invalid, As this is what causes the `udiv` to fault. I think it is invalid with or without the “freeze”, why do you think step 3, the commute, without the “freeze" is valid ? Also, do you think you can come up with an example that does not depend on signed overflow being “undefined” ? Peter
2016 Nov 11
2
RFC: Killing undef and spreading poison
Hi John, John McCall wrote: >> On Nov 10, 2016, at 10:37 PM, Sanjoy Das<sanjoy at playingwithpointers.com> wrote: >> As a concrete example, say we have: >> >> i32 sum = x *nsw y >> i64 sum.sext = sext sum to i64 >> ... >> some use of sum.sext >> >> >> Pretending "x +nsw 1" does not sign-overflow, we can commute the sext
2008 Oct 06
3
[LLVMdev] sext..to instruction
Hi, I have a question about the "sext..to" instruction. In the document, I found two examples: %x = sext i8 -1 to i16 It means: i8 -1 = 1111 1111 --> 1111 1111 1111 1111 = i16 how can it determinate, that the i16 value %x positive is (65535)? And the second example: %y = sext i1 true to i32 1 --> 1111 1111 1111 1111 1111 1111 1111 1111 In this example, %y is -1 I'm not sure
2013 Jun 20
2
[LLVMdev] Error in the example of sext instruction in reference manual
Hi all, There might be a simple error in the LLVM reference manual. The example for sext instruction: %X = sext i8 -1 to i16 ; yields i16 :65535 %X should yield i16: -1, as opposed to 65535. Here is the simple patch (also attached): Index: docs/LangRef.rst =================================================================== --- docs/LangRef.rst (revision 184496) +++ docs/LangRef.rst
2017 Jun 07
2
RFC: Killing undef and spreading poison
Since most add/sub operations compiled from C have the nsw attribute, we cannot simply restrict movement of these instructions. Sure, we could drop nsw when moving these instructions, but there are still many other problems left. Please read more about the topic here: https://blog.regehr.org/archives/1496 For example, doing loop unswitching, followed by inline (just to illustrate that the
2015 Apr 01
2
[LLVMdev] Cast to SCEVAddRecExpr
Thanks Sanjoy. > To be pedantic, "var[i<<1]" is not an add recurrence, but "&var[i << > 1]" is an add recurrence. I'll assume that's that you meant. Yes, I meant the same. > I think that is because in C, multiplication is nsw but left shift is > not and so "i << 1" can legitimately sign-overflow but i * 2 cannot >
2013 Jun 21
0
[LLVMdev] Error in the example of sext instruction in reference manual
On Jun 20, 2013, at 4:39 PM, Bin Tzeng <bintzeng at gmail.com> wrote: > Hi all, > > There might be a simple error in the LLVM reference manual. The example for sext instruction: > > %X = sext i8 -1 to i16 ; yields i16 :65535 > > %X should yield i16: -1, as opposed to 65535. > Here is the simple patch (also attached): These are the same value. -Chris >
2019 Sep 27
2
Shift-by-signext - sext is bad for analysis - ignore it's use count?
In https://reviews.llvm.org/D68103 the InstCombine learned that shift-by-sext is simply a shift-by-zext. But the transform is limited to single-use sext. We can quite trivially get a case where there are two shifts by the same sext: https://godbolt.org/z/j6mO3t <- We should handle those cases. In https://reviews.llvm.org/D68103#1686130 Sanjay Patel notes that this sext is intrusive for
2019 Oct 01
2
Shift-by-signext - sext is bad for analysis - ignore it's use count?
Thanks for taking a look! On Tue, Oct 1, 2019 at 9:09 PM Philip Reames <listmail at philipreames.com> wrote: > On 9/27/19 1:40 PM, Roman Lebedev via llvm-dev wrote: > > In https://reviews.llvm.org/D68103 the InstCombine learned that shift-by-sext > > is simply a shift-by-zext. > > Just to make sure I'm following, the reasoning here is that the shift > amount must
2016 Oct 20
2
RFC: Killing undef and spreading poison
Hi Alexandre, On Wed, Oct 19, 2016 at 6:27 PM, Alexandre Isoard <alexandre.isoard at gmail.com> wrote: > Really interesting read. I am perplexed now, and am not even sure what is > the meaning of undef anymore. Welcome aboard. :) > Example (unrelated to your blog post, but still weird): > %x = sext i1 undef to i2 > > I understand that I can replace it by either of: >
2012 Jun 16
2
[LLVMdev] SCEV not simplifying
I have a pair of SCEVs that appear different to me. However, when I compute the difference, it's not known to be non-zero. src = (sext i32 %n to i64) dst = (sext i32 (1 + %n) to i64) delta = ((sext i32 %n to i64) + (-1 * (sext i32 (1 + %n) to i64))) Is this behavior expected? If I repeat the experiment with 64-bit ints (or unsigned), things work out like I expect. 32-bit
2015 Apr 29
2
[LLVMdev] [LoopVectorizer] Missed vectorization opportunities caused by sext/zext operations
Hi, This is somewhat similar to the previous thread regarding missed vectorization opportunities (http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084765.html), but maybe different enough to require a new thread. I'm seeing some missed vectorization opportunities in the loop vectorizer because SCEV is not able to fold sext/zext expressions into recurrence expressions (AddRecExpr). This
2016 Apr 23
2
[IndVarSimplify] Narrow IV's are not eliminated resulting in inefficient code
Hi Sanjoy, Thank you for looking into this! Yes, your patch does fix my larger test case too. My algorithm gets double performance improvement with the patch, as the loop now has a smaller instruction set and succeeds to unroll w/o any extra #pragma's. I also ran the LLVM tests against the patch. There are 6 new failures: Analysis/LoopAccessAnalysis/number-of-memchecks.ll
2015 Mar 19
2
[LLVMdev] Cast to SCEVAddRecExpr
Hi Nick, Thanks for looking into it. I have tried that as well but it didn't worked. "AddExpr->getOperand(0))" node is: " (4 * (sext i32 {2,+,2}<%for.body4> to i64))<nsw>" When I cast this to "SCEVAddRecExpr" it returns NULL. Regards, Ashutosh -----Original Message----- From: Nick Lewycky [mailto:nicholas at mxc.ca] Sent: Thursday, March 19,
2008 Oct 06
0
[LLVMdev] sext..to instruction
> I'm not sure about it, when sext to results a positve/negative value? sext does signed-extension, zext does unsigned-extension. This means that zext always extends by zero bits, while with sext the additional bits are all copies of the top bit of the original value. So with sext, if it was negative in the original type when considered as a signed value, then it will be negative in the
2015 Mar 19
3
[LLVMdev] Cast to SCEVAddRecExpr
Yes, I can get "SCEVAddRecExpr" from operands of "(sext i32 {2,+,2}<%for.body4> to i64)". So whenever SCEV cast to "SCEVAddRecExpr" fails, we have drill down for such patterns ? Is that the right way ? Regards, Ashutosh -----Original Message----- From: Nick Lewycky [mailto:nicholas at mxc.ca] Sent: Thursday, March 19, 2015 1:02 PM To: Nema, Ashutosh Cc:
2013 Oct 28
2
[LLVMdev] loop vectorizer says Bad stride
Verifying function running passes ... LV: Checking a loop in "bar" LV: Found a loop: L0 LV: Found an induction variable. LV: We need to do 0 pointer comparisons. LV: Checking memory dependencies LV: Bad stride - Not an AddRecExpr pointer %13 = getelementptr float* %arg2, i32 %1 SCEV: ((4 * (sext i32 {(256 + %arg0),+,1}<nw><%L0> to i64)) + %arg2) LV: Src Scev: {((4 * (sext
2019 Oct 01
2
Shift-by-signext - sext is bad for analysis - ignore it's use count?
The thing is, we *don't* "not demand" those high bits. We *don't* not care what's in those bits - IR shifts don't mask their shift amounts. I.e we can't replace `x >> (32-y)` with `x >> (-y)`, which would be legal transform should we not demand those bits. We very much demand them. We just know those bits to be zero. And i'm not sure how to convey
2019 Oct 07
2
Shift-by-signext - sext is bad for analysis - ignore it's use count?
On Mon, Oct 7, 2019 at 11:32 AM Roman Lebedev <lebedev.ri at gmail.com> wrote: > > Bump. Any further thoughts here? > > To recap - i don't really see how this can be a demandedbits problem - we do > demand all those bits, we just know they must be zero. > (i would love to be proven wrong though!) > > Roman. > > On Tue, Oct 1, 2019 at 11:17 PM Roman Lebedev
2013 Jun 21
2
[LLVMdev] Error in the example of sext instruction in reference manual
Thanks for the reply. Just for a little more clarity, is i16, i32... signed, unsigned, or just a bit pattern? On Thu, Jun 20, 2013 at 9:17 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 20, 2013, at 4:39 PM, Bin Tzeng <bintzeng at gmail.com> wrote: > > > Hi all, > > > > There might be a simple error in the LLVM reference manual. The example