similar to: The undef story

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

Peter, I strongly suggest that you take a break from this email thread and careful consider the points Chandler has made about community norms and expectations before returning to this discussion. Chandler has been exceedingly patient with explaining why your behaviour is problematic and made several concrete suggestions as to productive next steps you should take. You are actively

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

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

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

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,

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,

Part I. The original LangRef appeared to be “nice and pretty” and originally ‘undef’ did not seem to stick out. Then evidence came to light in the form of bug reports, and in the form of Dan Gohman’s email “the nsw story”, that all was not good for ‘undef’ [1,2]. A proposal was made based on that evidence. A presentation was made at an llvm gathering. A paper was written. The proposal has even

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

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

Mehdi, I think the following was the point of the conversation, That both those examples are illegal C programs. They are both “undefined behavior” because they both use a shift amount that is too large. They both should have been rejected by the compiler even though they weren’t. Hal agrees wth this assessment, That’s why we’re waiting for a more complete example. My belief is that

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

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

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

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

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

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

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

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