similar to: the nsw story, revisited

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

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

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,

Sean, Many thanks for taking the time to respond. I didn’t make myself clear, I will try to be brief... > On Jun 28, 2017, at 7:48 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Wed, Jun 28, 2017 at 3:33 PM, Peter Lawrence via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Chandler, >

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

All, These discussions seem to be based on the premise that there is a need for the compiler to exploit undefined behavior for performance optimization reasons. So far the only beneficial optimization I am aware of that relies on some form of “undefined” is Dan Gohman’s original project for LP64 targets of promoting i32 induction variables to i64 and hoisting sign-extension out of the

On Thu, Dec 1, 2011 at 09:23, Dan Gohman <gohman at apple.com> wrote: > > int a = INT_MAX, b = 1; > long c = (long)(a + b); > > What is the value of c, on an LP64 target? > > If a and b are promoted to 64-bit, c is 0x0000000080000000. > > In a world where signed add overflow returns undef, c could be any of >  0x0000000000000000 >  ... >

Chandler, where we disagree is in whether the current project is moving the issue forward. It is not. It is making the compiler more complex for no additional value. The current project is not based in evidence, I have asked for any SPEC benchmark that shows performance gain by the compiler taking advantage of “undefined behavior” and no one can show that. The current project

Hi Peter, On Thu, Jun 8, 2017 at 9:41 AM, Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > >> On Jun 7, 2017, at 2:23 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> >> Since most add/sub operations compiled from C have the nsw attribute, we cannot simply restrict movement of these instructions. > > Nuno, > I’m not saying the operations

Sanjoy, You have changed the subject. We still need real world examples showing how taking advantage of “undef” results in beneficial optimization. My belief is that they don’t exist, my reasoning is this: real world programmers are likely to run UBSan before compiling (or if they don’t they should), therefore it is highly unlikely that any “undef” will actually exist during

On Dec 1, 2011, at 9:09 AM, Chris Lattner wrote: > > On Dec 1, 2011, at 8:46 AM, Dan Gohman wrote: > >> >> On Nov 30, 2011, at 10:49 PM, Chris Lattner wrote: >> >>> >>> On Nov 29, 2011, at 3:21 PM, Dan Gohman wrote: >>> >>>> >>>> A natural reaction to this problem is to think that LLVM IR is so nice

A few thoughts from someone on the sidelines; hope they're helpful. On Tue, Nov 29, 2011 at 3:21 PM, Dan Gohman <gohman at apple.com> wrote: > The first solution for this was to define nsw add to return undef on > overflow, instead of invoking immediate undefined behavior. This way, > overflow can happen and it doesn't cause any harm unless the value > is actually used.

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

> 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

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 =

Regarding the patches, there are two concerns AFAICT: 1. It’s a new instruction and as usual when introducing a new instruction it will require work for some time until most optimizations know about it, and to get rid of any potential perf regression. No big deal; we just need to do the work (and we have already done some of it). 2. The patch was written by a student, which may not have time to

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 5, 2011, at 5:50 PM, me22 wrote: > On Thu, Dec 1, 2011 at 09:23, Dan Gohman <gohman at apple.com> wrote: >> >> int a = INT_MAX, b = 1; >> long c = (long)(a + b); >> >> What is the value of c, on an LP64 target? >> >> If a and b are promoted to 64-bit, c is 0x0000000080000000. >> >> In a world where signed add overflow

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

(If this thread is becoming tiresome, let me know. This newbie is trying to understand some of what's going on; clearly you've thought about it way more than I have, and I can understand if you want to stop thinking about it!) On Mon, Dec 5, 2011 at 2:22 PM, Dan Gohman <gohman at apple.com> wrote: > On Dec 5, 2011, at 11:55 AM, Paul Robinson wrote: > > > > On Thu,