search for: peterl95124

...lled 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 Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote: > 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 i...

...t it as a bug. Peter Lawrence. [* in fact that’s one of the primary reasons Apple adopted llvm, to use It as a base for static analysis] > On Jul 21, 2017, at 10:03 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2017-07-21 21:27 GMT-07:00 Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>>: > 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 <mailto:peterl95124 at sbcglobal.net>> wrote: >&g...

...-absense, because in the real world after programs have passed static-analysis there won’t be any UB-presence to delete. Peter Lawrence. > On Jul 27, 2017, at 7:45 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Jul 27, 2017 at 7:30 PM Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote: > 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...

...in 4.0.1, but should be able to within a month. My target resembles MSP430, so I’ll try to replicate it for that target in 4.0.1 ] > On Jul 24, 2017, at 9:08 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Jul 24, 2017 at 9:02 AM Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote: >> On Jul 21, 2017, at 10:55 PM, Mehdi AMINI <joker.eph at gmail.com <mailto:joker.eph at gmail.com>> wrote: >> >> >> >> 2017-07-21 22:44 GMT-07:00 Peter Lawrence <peterl95124 at...

> 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 optimize program where there is no UB. We delete dead code, code that n...

...this assumption (-fsanitize=undefined isn’t opt’ing out, its opt’ing in to a lot extra that I might or might not want). Peter Lawrence. > On Jul 31, 2017, at 9:48 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Jul 31, 2017 at 7:40 AM Peter Lawrence <peterl95124 at sbcglobal.net <mailto: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 act...

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

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

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 different transforms. > >...

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, John and others...

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 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. &gt...

> > > Message: 5 > Date: Tue, 25 Jul 2017 00:12:35 -0700 > From: Sean Silva via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > To: Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> > Cc: llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>, John Regehr > <regehr at cs.utah.edu <mailto:regehr at cs.utah.edu>> > Subject: Re: [llvm-dev] GEP with a null pointer...

...ou are actively violating the community expectations around interaction on the public mailing lists. Your behaviour on this thread is not acceptable and must stop. Philip On 06/28/2017 11:03 PM, Chandler Carruth via llvm-dev wrote: > On Wed, Jun 28, 2017 at 10:53 PM Peter Lawrence > <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote: > > > > > Having read all of these threads, I am thoroughly convinced by > the positions put forward by others. > > > > Chandler, > others have decided to...

...of UB (here typically some non-trivial analysis is required) These have, practically speaking, nothing in common. Peter Lawrence. > On Jul 21, 2017, at 5:00 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Jul 21, 2017 3:24 PM, "Peter Lawrence" <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote: > >> On Jul 20, 2017, at 11:22 AM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> >> >> On Wed, Jul 19, 2017 at 10:17 AM Peter Lawrence via llv...

...rent 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 10:53 PM Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote: > > > > 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-com...

...users expectations in the function-inlining example. So the question is, where do you stand ? Peter Lawrence. > On Jun 19, 2017, at 9:35 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Peter, > > On Mon, Jun 19, 2017 at 8:36 AM, Peter Lawrence > <peterl95124 at sbcglobal.net> wrote: >> You’ve hit the nail on the head !, but I don’t think we’ve correctly >> identified the root cause of the problem yet. >> >> Rather the problem is with how we incorrectly cse and copy-propagate it: >> x = undef >>...

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

On Mon, Feb 14, 2011 at 3:49 PM, Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > Andrew, >                your response highlights a naming problem in LLVM, > which is that  "array" and "vector" > mean the same thing in normal computer language and compiler theory > usage, so it is > inconvenient and misleading...

Keno, Perhaps you can view the problem to be the memcpys themselves, We humans can look at the memcpys and see loads and stores but to almost all optimizer passes they aren’t what it is looking for, They instead see function calls which they mostly don’t touch, If these memcpys were inlined into plain old loads and stores The redundant loads and stores should be deleted by existing opts

...else do_something_2(); } return 0; } char foo(); bool alwaysfalse(); char f = do_something<char>(foo(), alwaysfalse()); > On Jun 29, 2017, at 2:49 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2017-06-29 14:32 GMT-07:00 Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>>: > 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...