search for: no_overflow

...rst, a warning: The scenario below is artificial. This is just a demonstration. Also, ignore the fact 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...

...nsformation, hoisting all of the > code above the %overflow_check branch: > > %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 > br i1 %overflow_check, label %no_overflow, label %end > > no_overflow: > > Was this valid? > > If nsw overflow is immediate undefined behavior, this transformation > would break the program, because the overflow is no longer guarded > by %overflow_check. But a premise of this exercise is that we want > to be a...

...t;> code above the %overflow_check branch: >> >>   %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 >>   br i1 %overflow_check, label %no_overflow, label %end >> >> no_overflow: >> >> Was this valid? >> >> If nsw overflow is immediate undefined behavior, this transformation >> would break the program, because the overflow is no longer guarded >> by %overflow_check. But a premise of this exercise...

...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 sext would have, it would be a case where the 32-bit add > had an overflow. The nsw says that the program would have undefined > behavior in t...

...heck branch: >>> >>> %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 >>> br i1 %overflow_check, label %no_overflow, label %end >>> >>> no_overflow: >>> >>> Was this valid? >>> >>> If nsw overflow is immediate undefined behavior, this transformation >>> would break the program, because the overflow is no longer guarded >>> by %overflow_ch...

On Wed, Jul 13, 2016 at 04:48:51PM +0200, Sedat Dilek via llvm-dev wrote: > [ CCed all people who were involved in this thread ] > > Hi Tom, > > personally, I am interested to test the prebuilt-toolchains for > Ubuntu/xenial alias 16.04 LTS and Debian/Jessie v8.5.0 AMD64. > The available toolchains are incomplete and thus useless. > > Just as a fact: There is still no