similar to: [LLVMdev] nsw is still logically inconsistent

> We first perform a speculation transformation, 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: > >

2011/12/14 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>: >> We first perform a speculation transformation, 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 =

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

On Dec 14, 2011, at 12:11 PM, Eli Friedman wrote: > 2011/12/14 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>: >>> We first perform a speculation transformation, 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

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 Dec 14, 2011, at 9:11 AM, David A. Greene wrote: > Dan Gohman <gohman at apple.com> writes: > >> Unfortunately, the final code is actually broken. If adding %a >> and %b as i32 values would overflow, adding them as i64 values >> would produce a value for which bit 31 is not equal to bit 32, so >> the subsequent ashr would produce a value which is not -1 or

Hi, > Hi Alexandre, > > LLVM currently doesn't have trunc nsw/nuw, no. > Which frontend would emit such instructions? Any application in mind? > Just asking because if no frontend could emit those, then the motivation to > add nsw/nuw support to trunc would be very low I guess. I think the clang frontend could use that to allow better static analysis of integer overflows on

> LICM on ToT hoists the div. Even speculatively. > > The other thing is that div is just one example. The problem could > also come up with an array load with an index could be safe to > speculate if the index is known to be bounded. isDereferenceablePointer > currently doesn't know how to do this, but it'll probably get > smarter some day. So, looking at just this

On Wed, Jul 5, 2017 at 3:59 PM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 07/04/2017 01:41 AM, Dr.-Ing. Christoph Cullmann via llvm-dev wrote: > >> Hi, >> >> Hi Alexandre, >>> >>> LLVM currently doesn't have trunc nsw/nuw, no. >>> Which frontend would emit such instructions? Any application in mind?

On 07/05/2017 03:10 PM, Alexandre Isoard wrote: > Ah, ok. I read it wrong. In *neither* case it is UB. > > Hum, can an implementation define it as UB? :-) Nope :-) The only case I've thought of where we could add these for C++ would be on conversions to (most) enums (because they used signed underlying types and the out-of-bounds mapping won't generally be one of the allowed

According to 6.3.1.3/3 of the C standard (I didn't check C++): "3 Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised." I *think* that means that IF a signal is raised then the signal raised could be one that you can't guarantee to be able to return from

Hi, Even if there are no ways in which a *frontend* can produce nsw truncs, it may still be useful to have if optimization passes can usefully attach nsw to truncates (after proving the truncates don't "overflow"). For instance in %a = ashr i64 %v, i32 33 %t = trunc %a to i32 the trunc can be marked nsw. However, the burden of proof here is to show that we can do some useful

On Wed, Nov 30, 2011 at 10:42 PM, Chris Lattner <clattner at apple.com> wrote: > On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: >> For a bit of an experiment I've been trying to compile LLVM & Clang >> with -Weverything (disabling any errors that seem like more noise/less >> interesting). One warning I've recently hit a few instances of is >>

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

Here are some clarifications for the reference manual. Please verify that my assumptions are correct. Shall I post a patch? Floating-point Constants: Add "The assembler requires the exact decimal value of a floating-point constant. For example, the assembler accepts '1.25' but rejects '1.3' because '1.3' is a repeating decimal in binary." Binary

Dan Gohman <gohman at apple.com> writes: >> I'm not following. If the promotion to i64 produces a different value, >> then the nsw smeantic was violated, leading to undefined behavior, as >> you note. That that point all bets are off. Divide by zero certainly >> is a perfectly valid expression of undefined behavior. If we had a >> delayed check we would

On Dec 1, 2011, at 12:08 AM, David Blaikie wrote: > On Wed, Nov 30, 2011 at 10:42 PM, Chris Lattner <clattner at apple.com> wrote: >> On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: >>> For a bit of an experiment I've been trying to compile LLVM & Clang >>> with -Weverything (disabling any errors that seem like more noise/less >>> interesting).

Hi Andrew, The issue below refers to LSR, so I'll appreciate your feedback. It also refers to instruction combining and might impact backends other than X86, so if you know of others that might be interested you are more than welcome to add them. Thanks, Anat _____________________________________________ From: Shemer, Anat Sent: Tuesday, February 18, 2014 15:07 To: 'llvmdev at

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

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