similar to: [LLVMdev] Arithmetic right shift emulation folding

The documentation for SHL, LSHR, and ASHR is unclear. What is the result of shifting by the number of bits in the left operand. For example, <result> = shl i32 1, 32 <result> = ashr i32 1, 32 <result> = lshr i32 1, 32

Andy, Here is the left circular shift operator patch. I apologize to the reviewer in advance. The patch has a good bit of fine detail. Any comments/criticisms? Some caveats... 1) This is just the bare minimum needed to make the left circular shift operator work (e.g. no instruction combining). 2) I tried my best to select operator names in the existing style; please feel free to change them as

I'm designing a language that supports array slicing. Does LLVM allows conversions between array pointers? For example, can I cast a pointer-to-array-of-5-ints to a pointer-to-array-of-3-ints? Can I get the address of the third element of an array-of-5-ints and convert it to a pointer-to-array-of-3-ints? Then again, I suppose a pointer-to-int would work just as well since LLVM

I decided to pump some IR through the optimizers and was surprised to find that we don't choose to canonicalize any of the following functions to the other even though they are all roughly the same. define i32 @f1(i32 %x, i32 %m) #0 { entry: %and = and i32 %m, 32896 %tobool = icmp ne i32 %and, 0 %cond = select i1 %tobool, i32 8, i32 0 %shr = lshr i32 %x, %cond ret i32 %shr } ;

> On Apr 5, 2020, at 22:20, Stefanos Baziotis <stefanos.baziotis at gmail.com> wrote: > > > Any idea about how the compiler could remove the lshr and use a add -16? > Actually, I just figured that doing this test is like solving this: > > 8 <= x/2 <= 13 > 16 <= x <= 26 > 0 <= x - 16 <= 10 => 0 <= x < 11 > The left part is know since

I should mention a couple of useful self-explanatory LLVM flags for triage: -enable-misched=false -verify-misched -Andy On Oct 15, 2013, at 4:43 PM, Eric Christopher <echristo at gmail.com> wrote: > Grats on the work, a long time coming! > > Beware the incoming register allocation bugs ;) > > -eric > > On Tue, Oct 15, 2013 at 4:33 PM, Andrew Trick <atrick at

How do you determine if a shift is signed or not? ashr = always signed? lshr = always unsigned? shl = always signed? The CmpInst has the "isSigned()" function, but it appears that every other Instruction I've looked at doesn't seem to have this. -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Wed, Nov 11, 2009 at 11:11 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 10, 2009, at 4:10 PM, Talin wrote: > > I realize that most users of LLVM aren't affected by this, because most > frontends aren't target-neutral, and thus know in advance how big a pointer > is. At least, that's my impression. > > I believe that. > > >

Hi, > I think the IR in both of your examples makes things harder for the compiler than expected from the original C source. Note that both versions are from clang with -O2. The first is with version 9.0 and the second is with the trunk. > but in the branch only %0 is used. Sinking the lshr too early made the analysis harder. Yes, exactly! That's what I figured too. > The version

David Greene wrote: > Is my analysis correct? If so, is the PHI code the culprit (for not returning > the min of the KnownZero bits) or is the Shl code the culprit (for not paying > attention to the Mask passed in (it right shifts it)? I think your analysis is correct, and that Shl -- and many of the other operations (AShr, LShr, SExt, Add?, Call?) -- should be modified to always

On Wed, Feb 22, 2012 at 4:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: On Wed, Feb 22, 2012 at 4:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > How do you determine if a shift is signed or not? > > ashr = always signed? Essentially, yes. > lshr = always unsigned? Essentially, yes. > shl = always signed? Signed left shift and unsigned left shift are both

Adding a nuw to the add -8 is incorrect. From the perspective of the unsigned math, -8 is treated a very large positive number. The input to the add is [8,13) and adding a large positive number to it wraps around past 0. So that is guaranteed unsigned wrap. On the other hand, a sub nuw 8 would be correct. ~Craig On Sun, Apr 5, 2020 at 3:27 PM Stefanos Baziotis via llvm-dev < llvm-dev at

Hello, >From [1], trunc does not seems to have a nsw/nuw attribute. Is it possible to have that? Or do we have that and it is not up-to-date? The definition would be: If the nuw keyword is present, the result value of the trunc is a poison value if the truncated high order bits are non-zero. If the nsw keyword is present, the result value of the trunc is a poison value if the truncated high

On 12/16/11 12:24 PM, Kostya Serebryany wrote: > Hello, > > We've just got a bug report from Mozilla folks about AddressSanitizer > false positive with -O2. > Turns out there is a conflict between load widening and AddressSanitizer. > > Simple reproducer: > % cat load_widening.c&& echo =========&& clang -O2 -c load_widening.c -flto&&

Hi all, > On 2 Oct 2019, at 14:34, Sanjay Patel <spatel at rotateright.com> wrote > Providing target options/overrides to code that is supposed to be target-independent sounds self-defeating to me. I doubt that proposal would gain much support. > Of course, if you're customizing LLVM for your own out-of-trunk backend, you can do anything you'd like if you're willing to

Hello, We've just got a bug report from Mozilla folks about AddressSanitizer false positive with -O2. Turns out there is a conflict between load widening and AddressSanitizer. Simple reproducer: % cat load_widening.c && echo ========= && clang -O2 -c load_widening.c -flto && llvm-dis load_widening.o && cat load_widening.o.ll void init(char *); int foo() {

On Friday 18 July 2008 00:36, Nick Lewycky wrote: > David Greene wrote: > > Is my analysis correct? If so, is the PHI code the culprit (for not > > returning the min of the KnownZero bits) or is the Shl code the culprit > > (for not paying attention to the Mask passed in (it right shifts it)? > > I think your analysis is correct, and that Shl -- and many of the other

On Fri, Dec 16, 2011 at 12:19 PM, John Criswell <criswell at illinois.edu> wrote: > On 12/16/11 12:24 PM, Kostya Serebryany wrote: > > Hello, > > We've just got a bug report from Mozilla folks about AddressSanitizer false > positive with -O2. > Turns out there is a conflict between load widening and AddressSanitizer. > > Simple reproducer: > > % cat

Jon Sargeant wrote: > Chris Lattner wrote: >> On Mon, 31 Mar 2008, Jon Sargeant wrote: >>> I'm attaching another round of changes. Please verify that they are correct. >> Applied with edits: >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080331/060556.html >> >> I figured out what your patches don't apply. Something (your web

On Fri, Dec 16, 2011 at 12:37 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Fri, Dec 16, 2011 at 12:19 PM, John Criswell <criswell at illinois.edu> > wrote: > > On 12/16/11 12:24 PM, Kostya Serebryany wrote: > > > > Hello, > > > > We've just got a bug report from Mozilla folks about AddressSanitizer > false > > positive with