search for: ashr

...that instcombine would zap everything. Depending on that would be an implicit pass dependency, which is against the rules. Ok, consider this LLVM IR code fragment: br i1 %overflow_check, label %no_overflow, label %end no_overflow: %t0 = add nsw i32 %a, %b %t1 = sext i32 %t0 to i64 %t2 = ashr i64 %t1, 31 %t3 = add i64 %t2, 1 %t5 = icmp ult %t3, 2 %t6 = udiv i1 1, %t5 Assume label %no_overflow has no other predecessors. And assume adding %a and %b can sometimes produce overflow, but only when %overflow_check is false. This code has no undefined behavior. It's a bit subtle, bu...

...l %L_entry L_entry: ; preds = %L_entry, %L_pre_head %L_ind_var = phi i64 [ 0, %L_pre_head ], [ %L_inc_ind_var, %L_entry ] %L_tid = phi i64 [ 0, %L_pre_head ], [ %L_inc_tid, %L_entry ] %sext = shl i64 %L_tid, 32 %idxprom = ashr exact i64 %sext, 32 %arrayidx = getelementptr inbounds float * %a, i64 %idxprom %0 = load float * %arrayidx, align 4 %arrayidx2 = getelementptr inbounds float * %b, i64 %idxprom %1 = load float * %arrayidx2, align 4 %add = fadd float %0, %1...

...ways. Consider the following C function: int f(int *p, int *q) { return q - p; } Here's the LLVM code generated by llvm-gcc (2.9): define i32 @f(i32* %p, i32* %q) nounwind readnone { entry: %0 = ptrtoint i32* %q to i32 %1 = ptrtoint i32* %p to i32 %2 = sub nsw i32 %0, %1 %3 = ashr exact i32 %2, 2 ret i32 %3 } And here is what clang (2.9) produces: define i32 @f(i32* %p, i32* %q) nounwind readnone { %1 = ptrtoint i32* %q to i32 %2 = ptrtoint i32* %p to i32 %3 = sub i32 %1, %2 %4 = ashr exact i32 %3, 2 ret i32 %4 } Thus, llvm-gcc added the nsw flag to the s...

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

...thmetic. On a related note, can I convert a pointer-to-int to a pointer-to-array-of-1-int and vice versa? BTW, I sent another post to this e-mail address, but never received a reply: ---------------------------------- Subject: Shifting by too many bits Body: 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 ---------------------------------- Regards, Jon

...i32 0, i32 1 ; <i32**> [#uses=1] %tmp23 = ptrtoint i32** %tmp1 to i32 ; <i32> [#uses=1] %x45 = ptrtoint [2 x i32*]* %x to i32 ; <i32> [#uses=1] %tmp6 = sub i32 %tmp23, %x45 ; <i32> [#uses=1] %tmp7 = ashr i32 %tmp6, 2 ; <i32> [#uses=1] ret i32 %tmp7 } The return value is 1. The ashr exposes the pointer size by shifting the 4 byte distance over by 2. For the analysis that I am doing, it would be nice to have an instruction that explicitly performs this distance calculat...

...* %input.addr, align 8 %0 = fptoui double %input to i64 %1 = fptrunc double %input to float %2 = mul i64 %0, %0 %3 = fptrunc double %input to float %4 = mul i64 %0, %0 %5 = fsub float %3, %3 store double* %o0, double** %o0.addr %6 = and i64 %0, %0 %7 = fptoui float %3 to i1 %8 = ashr i1 %7, %7 store double* null, double** %o0.addr %9 = fptosi double %input to i64 %10 = shl i1 %7, %7 %11 = sitofp i1 %8 to float %12 = icmp uge i64 %6, %4 %13 = and i64 %0, %6 %14 = fcmp ole float %11, %11 %15 = ashr i1 %10, %7 %16 = sext i1 %10 to i64 %17 = ashr i1 %7, %12 %1...

...bitcast i8* %arrayidx to i64* %1 = load i64* %0, align 16 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< %2 = trunc i64 %1 to i32 %sext = shl i32 %2, 24 %conv = ashr exact i32 %sext, 24 %3 = lshr i64 %1, 16 %.tr = trunc i64 %3 to i32 %sext3 = ashr i32 %.tr, 24 %add = add nsw i32 %sext3, %conv ret i32 %add } Here, the load widening replaces two 1-byte loads with one 8-byte load which partially goes out of bounds. Since the array is 16-byte aligned, t...

...*q) > { > return q - p; > } > > Here's the LLVM code generated by llvm-gcc (2.9): > define i32 @f(i32* %p, i32* %q) nounwind readnone { > entry: > %0 = ptrtoint i32* %q to i32 > %1 = ptrtoint i32* %p to i32 > %2 = sub nsw i32 %0, %1 > %3 = ashr exact i32 %2, 2 > ret i32 %3 > } > > And here is what clang (2.9) produces: > define i32 @f(i32* %p, i32* %q) nounwind readnone { > %1 = ptrtoint i32* %q to i32 > %2 = ptrtoint i32* %p to i32 > %3 = sub i32 %1, %2 > %4 = ashr exact i32 %3, 2 > r...

...; > With llvm 3.9: > > define <8 x i16> @foo(<8 x i16>, i32) #0 { > %3 = trunc i32 %1 to i16 > %4 = insertelement <8 x i16> undef, i16 %3, i32 0 > %5 = shufflevector <8 x i16> %4, <8 x i16> undef, <8 x i32> > zeroinitializer > %6 = ashr <8 x i16> %0, %5 > ret <8 x i16> %6 > } > > > With llvm 4.0: > > define <8 x i16> @foo(<8 x i16>, i32) #0 { > %3 = insertelement <8 x i32> undef, i32 %1, i32 0 > %4 = shufflevector <8 x i32> %3, <8 x i32> undef, <8 x i32&...

I need to read up on how nsw would make this different, but I see your point about the shift: %bf.result.shl = shl i8 %bf.value, 5 %bf.result.ashr = ashr i8 %bf.result.shl, 5 This should have splatted the sign bit across the upper 5 bits of the char, so the subsequent compare: %cmp = icmp slt i32 %bf.cast, 1 Can't be transformed to a check for 'equal to 0'. Thanks! On Fri, Nov 15, 2013 at 9:18 PM, Henrique Santos < henri...

...to i64* > %1 = load i64* %0, align 16<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > %2 = trunc i64 %1 to i32 > %sext = shl i32 %2, 24 > %conv = ashr exact i32 %sext, 24 > %3 = lshr i64 %1, 16 > %.tr = trunc i64 %3 to i32 > %sext3 = ashr i32 %.tr, 24 > %add = add nsw i32 %sext3, %conv > ret i32 %add > } > > Here, the load widening replaces two 1-byte loads with one 8-byte load > which partially goes out...

I actually think it is a problem with the optimizer like Kay first thought. -instcombine seems turning "((x and 6) shl 5) slt 32" into "(x and 6) slt 1". If the comparison were unsigned or the shl had a nsw flag, I think this would be okay. Since none of these is true, I don't think this transformation is correct. H. On Sat, Nov 16, 2013 at 1:41 AM, Mark Lacey

Since C doesn't specify whether >> is arithmetic or logical on signed numbers, portable code would have to emulate it. Is there a way that LLVM will fold down to ashr in the IR? I first tried this: int ashr(unsigned a, unsigned b) { return (signed)a < 0 ? ~((~a) >> b) : a >> b; } But that generates 4 BBs. Slightly better is this one: int qaz(unsigned a, unsigned b) { unsigned c = (signed)a < 0 ? ~0u : 0u;...

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

...lt;8 x i16> @foo(<8 x i16>, i32) #0 { >>> %3 = trunc i32 %1 to i16 >>> %4 = insertelement <8 x i16> undef, i16 %3, i32 0 >>> %5 = shufflevector <8 x i16> %4, <8 x i16> undef, <8 x i32> >>> zeroinitializer >>> %6 = ashr <8 x i16> %0, %5 >>> ret <8 x i16> %6 >>> } >>> >>> >>> With llvm 4.0: >>> >>> define <8 x i16> @foo(<8 x i16>, i32) #0 { >>> %3 = insertelement <8 x i32> undef, i32 %1, i32 0 >>> %4...

Dan Gohman <gohman at apple.com> writes: > Next, we perform a promotion transformation, converting the add nsw > from i32 to i64: > > %s0 = sext i32 %a to i64 > %s1 = sext i32 %b to i64 > %t0 = add nsw i64 %s0, %s1 > %t2 = ashr i64 %t0, 31 > %t3 = add i64 %t2, 1 > %t5 = icmp ult %t3, 2 > %t6 = udiv i1 1, %t5 > br i1 %overflow_check, label %no_overflow, label %end > > no_overflow: > > Was this valid? > > Any time the new i64 add would produce a different value than the > original se...

On Monday, July 30, 2012 12:16 AM, Cameron McInally wrote: > Hey Andy, > > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > Parts of my patch did make it into trunk about a year after, but others > did not. > > At that time, my solution was to add a binary operator to the IRBuilder, > since LCS fits in nicely with the other shift operators. But,

Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.

...dx to i64* > %1 = load i64* %0, align 16 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > %2 = trunc i64 %1 to i32 > %sext = shl i32 %2, 24 > %conv = ashr exact i32 %sext, 24 > %3 = lshr i64 %1, 16 > %.tr = trunc i64 %3 to i32 > %sext3 = ashr i32 %.tr, 24 > %add = add nsw i32 %sext3, %conv > ret i32 %add > } > > > Here, the load widening replaces two 1-byte loads with one 8-byte load which > partially goes out...