similar to: GEP with a null pointer base

Sean, Let me re-phrase a couple words to make it perfectly clear > On Jul 21, 2017, at 6:29 PM, Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > > Sean, > > Dan Gohman’s “transform” changes a loop induction variable, but does not change the CFG, > > Hal’s “transform” deletes blocks out of the CFG, fundamentally altering it. > > These are two totally

Sean, Dan Gohman’s “transform” changes a loop induction variable, but does not change the CFG, Hal’s “transform” deletes blocks out of the CFG, fundamentally altering it. These are two totally different transforms. And even the analysis is different, The first is based on an *assumption* of non-UB (actually there is no analysis to perform) the second Is based on a *proof* of existence of UB

Mehdi, Hal’s transformation only kicks in in the *presence* of UB, and it does not matter how that UB got there, whether by function inlining or without function inlining. The problem with Hal’s argument is that the compiler does not have a built in ouija board with which it can conjure up the spirit of the author of the source code and find out if the UB was intentional with the

> On Jul 21, 2017, at 10:55 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2017-07-21 22:44 GMT-07:00 Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>>: > Mehdi, > Hal’s transformation only kicks in in the *presence* of UB > > No, sorry I entirely disagree with this assertion: I believe we

Dave, The way I see it there should be just one pass that implements deleting UB (maybe it would come to be called UBCE), and that one pass should have a command line option simply for the reason than all passes should have one. Peter Lawrence. > On Jul 26, 2017, at 10:02 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Jul 26, 2017 at 9:23 PM

David, -fsanitize=undefined sounds great, but is not quite what I want. I recently ran into a problem with "CodeGen/MachineSink.cpp” [*], for a target that has to expand Select into control flow. The original IR had two select in a row that were based on the same condition, so the CMP that sets the FLAGS reg in the second select was MCSE’ed to the earlier CMP in the first

Dave, Dead code elimination is generally done in a pass called dead code elimination, Can you give concrete examples why the same would not be true for UB code elimination ? Yes, speculatively hoisting code requires it to be UB-free, but that has nothing to do with UBCE deleting entire blocks of code because of the existence of UB. The former requires an analysis proving UB-absense, the

> On Jul 20, 2017, at 11:22 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Jul 19, 2017 at 10:17 AM Peter Lawrence via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Chandler, > The only thing David made clear that wasn’t already clear > is that he believes UB to be “comparatively

On Mon, Jul 31, 2017 at 7:40 AM Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > Dave, > Dead code elimination is generally done in a pass called dead > code elimination, > Can you give concrete examples why the same would not be true for UB code > elimination ? > I haven't actually looked at how optimizations on the basis of the code being UB-free

Dave, I will try to locate and take a look at the actual llvm logic that deletes based on UB-presence, one of these days, and report back. In the mean time... Your “For example:" is a plausibility argument only. It is not meaningful until you can show this happening in real source code from real applications that are compiler warning free and static analysis warning free. Hal

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,

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

Chris, nice segue to Swift ! :-), but... The question is what should LLVM do with UB in general, saying that we are going to change one specific idiom from undefined to defined glosses over the real question: why should we ever optimize / delete any UB at all ? This “depressing and faintly terrifying thing” as you call it, should be viewed not as an opportunity for optimization, but

On Wed, Jul 12, 2017 at 11:58 AM, Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > > On Jun 30, 2017, at 12:00 PM, via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > Date: Fri, 30 Jun 2017 09:16:54 -0700 > From: Peter Lawrence via llvm-dev <llvm-dev at lists.llvm.org> > To: Hal Finkel <hfinkel at anl.gov> > Cc: llvm-dev <llvm-dev at

Hal, Mehdi points out I mis-quoted you, I apologize sincerely. Mehdi, Thank you for forcing me to go back and re-read what Hal wrote, I could have sworn Hal and I were in agreement at the time I wrote you, Must have been asleep at the wheel, not enough sleep last night However my request for a more concrete example stands Here’s what I said > This doesn’t make sense to me, a

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 Jul 6, 2017, at 3:07 PM, Chris Lattner <clattner at nondot.org> wrote: > > >> On Jul 6, 2017, at 2:05 PM, Peter Lawrence via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >>> On Jul 6, 2017, at 1:00 PM, via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>

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

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

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