similar to: Which pass should be propagating memory copies

Keno, Hmmm, seems like you are saying “copy-in-copy-out” argument semantics are required by the language, Otherwise you would be using “by-reference" argument semantics, And that CICO is easiest for you to represent with memcpy. Usually there are some very subtle issues with CICO and the memory model, Typically the original object isn’t supposed to be modified until the function

Consider the following IR example: define void @simple([4 x double] *%ptr, i64 %idx) { %stack = alloca [4 x double] %ptri8 = bitcast [4 x double] *%ptr to i8* %stacki8 = bitcast [4 x double] *%stack to i8* call void @llvm.memcpy.p0i8.p0i8.i32(i8 *%stacki8, i8 *%ptri8, i32 32, i32 0, i1 0) %dataptr = getelementptr inbounds [4 x double], [4 x double] *%ptr, i32 0, i64 %idx

I was just going to say: With well-formed debug info it should create a deep copy up until the DISubprogram, but no further. But because the DISubprogram linked to the Function is missing the special handling of the DISubprogram (that would prohibit cloning the DICompileUnit is side-stepped). But then I remembered the discussion we had in

I left a comment on https://reviews.llvm.org/D18738 earlier which I feel is related to this discussion, so I'm reproducing it here: I wonder though if what we want to express isn't some sort of "type-based dereferencability annotations". For example the semantics I care about are essentially, "if you know you have a defereferencable pointer, you can go and dereference any

- old Keno +current Keno > On Jun 19, 2017, at 2:59 PM, Adrian Prantl <aprantl at apple.com> wrote: > > In your example the instructions in the cloned function have debug locations belonging to a different function, and the function itself is missing a DISubprogram metadata attachment. > >> (lldb) p OldFunc->dump() >> >> ; Function Attrs: nounwind optsize

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

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

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

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

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

The if you are cloning into the same LLVM module the CU should not cloned. If don't mind sharing your code, I can try to help diagnose why the CU gets cloned... just send me a patch that applies to trunk and instructions. -- adrian > On Jun 16, 2017, at 1:54 PM, Sergei Larin <slarin at codeaurora.org> wrote: > > Sorry… It takes a pass that was not accepted for upstreaming….

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

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

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 within LLVM to give one a very specific meaning that is different from the other.... to the LLVM developers I would suggest using the term

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

Can you send me a patch with instructions to reproduce? I can take a look. -- adrian > On Jun 15, 2017, at 2:23 PM, Sergei Larin <slarin at codeaurora.org> wrote: > > Yes, it does for us. My tree is couple days off the tip, and I see it there. > > Sergei > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Keno Fischer via llvm-dev > Sent:

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