similar to: The undef story

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

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, >

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,

Sanjoy, in your blog post https://www.playingwithpointers.com/problem-with-undef.html <https://www.playingwithpointers.com/problem-with-undef.html> you describe a problem with LLVM “undef”, yet in your paper http://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf <http://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf> you do not suggest fixing this problem, even though in

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

> On Jun 29, 2017, at 4:39 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 06/28/2017 05:33 PM, Peter Lawrence wrote: >> 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

Chandler, I am not a “politically correct” person, never have been, never will be. If you are waiting for me to make a politically incorrect statement so you can jump on it, let me assure you that you will never be disappointed. But if that’s all you do then you and llvm lose out. If you want to actually help llvm move forward then you should judge what I say based on its merit,

Chandler, Al right then, stay on topic, what do you actually think should be done about the fact that the current proposal will mis-compile the function-inlining example, and won’t be able to hoist a loop-invariat divide out of a loop. Peter Lawrence. > On Jun 28, 2017, at 11:03 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > On Wed, Jun 28, 2017 at

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

Sanjoy, The point is this, you have to take a stand one way or the other on the function-inlining issue: [1. this function *always* executes statement S, F(a) { If (a == a) S; } but in llvm if you inline it and “a” happens to be “undef” then nothing can be said about whether statement S is executed. This is indefensible.] My belief is this: that llvm exists for a

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

> > Having read all of these threads, I am thoroughly convinced by the positions put forward by others. > Chandler, others have decided to let the compiler continue mis-compiling the function-inlining example, others have decided to not fix the inability to hoist a loop invariant divide out of a loop. It sounds like you haven’t even thought about these things let alone

> On Jun 16, 2017, at 8:23 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Peter, > > On Tue, Jun 13, 2017 at 10:27 AM, Peter Lawrence via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Here’s what seems to really be going on >> >> “undef” === models an uninitialized register, but > > No, it specifically does

Sanjoy, My belief is that this is a register allocation problem that should not be addressed in the IR. However you have changed the subject, and we still need an example showing why the proposed definition for branch is the right one. Peter Lawrence. > On Jun 16, 2017, at 7:39 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Peter, > > On

On 05/26/2017 03:02 PM, Matthias Braun wrote: > >> Regarding SDAG, and given that poison is already there, we would need >> to adopt a similar solution to the IR. Maybe right now we can get >> away with it because nsw is not exploited significantly (as you say). >> Just because there’s no explicit poison in SDAG, just having nsw is >> sufficient to cause

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

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

On 06/29/2017 10:41 AM, Peter Lawrence wrote: > >> On Jun 29, 2017, at 4:39 AM, Hal Finkel <hfinkel at anl.gov >> <mailto:hfinkel at anl.gov>> wrote: >> >> On 06/28/2017 05:33 PM, Peter Lawrence wrote: >>> Chandler, >>> where we disagree is in whether the current project >>> is moving the issue >>> forward.