similar to: Is trapping allowed when an add with nsw flag overflows?

[This mail could be an answer to the other responses as well, as they basically are the same.] Ah, I think I understand now what poison is for. Adds are defined to not have side-effects, so the dependence rule is needed so the optimizer is allowed to exploit undefined behavior. Is this correct? I forgot to mention in my original mail that our trapping arithmetic operations are fully

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

Hi Sanjoy, thanks for your thoughts on this. On Sat, Jun 27, 2015 at 12:16 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > > First of all, going by the "poison causes UB only when observed", SCEV > does not do the right thing currently: [...] > > That seems like a bug? There's also bug 23527 for GEP. Sounds like there might be more such bugs. One

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

John, Sanjoy, Nuno, David, Thanks for the tip, below are the relevant posts from the archives. I am suggesting something similar to Dan's third option below (Tue Nov 29 2011 "the nsw story”, Dan Gohman), when hoisting an instruction with ‘nsw’ it looses the ‘nsw’ attribute, but without saying “add-nsw is a fully side-effecting instruction”. This option was back then seen by

The old and popular tradition of "int" being the default all-purpose type in C hit a snag with the arrival of 64-bit general-purpose architectures, when, for reasons of memory usage and compatibility, "int" was fixed at 32 bits. This meant it was no longer the same size as a pointer, the size of an array index, or the widest native integer type. (Sequence of events simplified

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

Preface: This paper shows that "poison" was never actually necessary in the first place. “Poison"s existence is based on incorrect assumptions that are being explored for the first time. I have been re-reading Dan Gohman's original post "the nsw story" [1] and have come to the conclusion that Dan got it wrong in some respects. He came up with "no signed

*** Summary I'd like to propose (and implement) functionality in LLVM to determine when a poison value from an instruction is guaranteed to produce undefined behavior. I want to use that to improve handling of nsw, inbounds etc. flags in scalar evolution and LSR. I imagine that there would be other uses for it. I'd like feedback on this idea before I proceed with it. *** Details Poison

Chandler, Please give some citations, I’ve search the llvm-dev archives and didn't find any. Peter Lawrence. > On Jun 28, 2017, at 12:01 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > On Wed, Jun 28, 2017 at 9:39 AM Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote: > > Preface: This paper

On 06/28/2017 02:18 PM, Chandler Carruth wrote: > On Wed, Jun 28, 2017 at 12:09 PM Peter Lawrence > <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote: > > Chandler, > Please give some citations, I’ve search the > llvm-dev archives and didn't find any. > > > They are all in the discussions from Nuno,

Hi Adam, Indvar widening can sometimes be harmful for architectures (e.g. NVPTX and AMDGPU) where wider integer operations are more expensive ( https://llvm.org/bugs/show_bug.cgi?id=21148). For this reason, we disabled indvar widening in NVPTX in http://reviews.llvm.org/D6196. Hope it helps. Jingyue On Mon, Jun 29, 2015 at 11:59 AM Adam Nemet <anemet at apple.com> wrote: > > >

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

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

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 =

> Then why does the Release Note say > " the operation is guaranteed to not overflow". It means that the person who wrote the IR has guaranteed that there's no overflow (by some means) so LLVM can assume it during optimisation. This guarantee might come from doing explicit checks before executing the add/sub; or perhaps from performing the operation after a sext so that the

----- Original Message ----- > From: "Bjarke Roune" <broune at google.com> > To: "Jingyue Wu" <jingyue at google.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Tuesday, June 30, 2015 8:16:13 PM > Subject: Re: [LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution > > Hi Adam, > > Jingyue is right. We need to keep

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 Dec 6, 2011, at 10:07 AM, Paul Robinson wrote: > On Tue, Dec 6, 2011 at 9:06 AM, David A. Greene <greened at obbligato.org> wrote: > Dan Gohman <gohman at apple.com> writes: > > > For example, suppose we want to convert the && to &, and the ?: to a > > select, in this code: > > > > if (a && (b ? (c + d) : e)) { > > >

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