similar to: [LLVMdev] Suspicious behavior of mem2reg (promoteSingleBlockAlloca)

I don't want to get into the debate w.r.t. which IR style is better - ask me over beer if you care about my opinions - but as an FYI, there are serious proposals being worked on to introduce some notion of memory def-use edges to help in analysing memory operations. I don't think we've settled on a concrete proposal yet, but I wouldn't be surprised to see something in the

Hi all, this is Jeehoon Kang, a CS PhD student and a newbie to LLVM. I am wondering why LLVM IR's basic block consists of a list of instructions, rather than a DAG of instruction as in the low level (ISelectionDAG). My gut feeling tells me that LLVM IR in DAG form may admit more optimisations in a systematic manner. This is because data dependence is more explicit in a DAG of instructions

Dear llvm-dev, Hi! We're collecting mis-compilation bugs in gvn and mem2reg since 3.7.1. Specifically, We're interested in bugs in the following files: llvm/lib/Transforms/Scalar/GVN.cpp llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp We checked all reports in the LLVM bugzilla (https://bugs.llvm.org/), so I'd like to ask if you know any such a bug that is not reported in

On Sat, Feb 21, 2015 at 6:38 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > > > On 21 Feb 2015, at 05:59, Jeehoon Kang <jeehoon.kang at sf.snu.ac.kr> > wrote: > > > > this is Jeehoon Kang, a CS PhD student and a newbie to LLVM. > > > > I am wondering why LLVM IR's basic block consists of a list of > instructions, > >

On Tue, Apr 10, 2018 at 3:09 PM, Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Tue, Apr 10, 2018 at 10:28 AM, Friedman, Eli via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: >> >> Dear llvm-dev, >> >> >> Hi! We're collecting mis-compilation

On Tue, Apr 10, 2018 at 10:28 AM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: > > Dear llvm-dev, > > > Hi! We're collecting mis-compilation bugs in gvn and mem2reg since > 3.7.1. Specifically, We're interested in bugs in the following files: > > llvm/lib/Transforms/Scalar/GVN.cpp

Hi all! While playing with LLVM, I've found a weird behavior in mem2reg pass. When optimizing single stores, undefined value is placed before any load preceding the store (based on basicblock's ordering and simple dominator analysis, if I remember correctly). This is the line that is responsible for the behavior: (LLVM9 does the same)

On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: > Dear llvm-dev, > > > Hi! We're collecting mis-compilation bugs in gvn and mem2reg since > 3.7.1.  Specifically, We're interested in bugs in the following files: > > llvm/lib/Transforms/Scalar/GVN.cpp > llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp 3.7 was released over two years ago; there have been

I think it’s reasonable to expect that IR generated by frontends doesn’t do this. Not sure about transforms; I can imagine that we might speculate a load without proving all the bits are well-defined. -Eli From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Juneyoung Lee via llvm-dev Sent: Sunday, September 20, 2020 3:54 PM To: llvm-dev <llvm-dev at lists.llvm.org>

Dear expeRts, I would simplify following code. --------------------------------------------- youtput <- function(x1, x2){ n <- length(x1) y <- vector(mode="numeric", length=n) for(i in 1:n){ if(x1[i] >=5 & x1[i] <= 10 & x2[i] >=5 & x2[i] <=10) y[i] <- 0.631 * x1[i]^0.55 * x2[i]^0.65 if(x1[i] >=10 & x1[i] <= 15 &

I think we need to allow this.  Otherwise, we have to prove that addresses are non-undef before we can hoist or sink a memory instruction.  Today, aliasing can use things like known bits, and if we imposed a no-undef in address requirement, we'd either need to replace such reasoning in AA, or have passes which wish to hoist/sink check the property afterwards. Or to say it differently, I

Thank you for the infos; it seems making it raise UB is problematic. Would clarifying it in LangRef be good? I can update the patch to contain the information instead. Another concern is then, how can we efficiently encode an assumption that a pointer variable in IR does not have undef bits? Certainly, in the front-end language, (most of) pointers won't have undef bits, and it would be great

> > Okay, it's just not immediately undefined behaviour. The C model has more > issues because of the problem with how "trap representation" is defined > (which precludes trap representations for unsigned char, two's complement > signed char, etc.). This interpretation is further stressed because C only explicitly ascribes > undefined behaviour to trap

> > // Members are initialized to poison at object creation. >> p = alloca {i8, i32} // p[0], p[4~7] are poison >> p[0] is an i8, so it shouldn't be poison? > > My interpretation of standard is that reading uninitialized char can also yield trap representation. If uninitialized, char variable has indeterminate value, and C/C++ does not seem to forbid reading trap

On Tue, Oct 2, 2018 at 4:44 AM Juneyoung Lee <juneyoung.lee at sf.snu.ac.kr> wrote: > > Hello Daniel, > > Thank you for the reply. > My impression was that embedding such information into MemorySSA > would be helpful for shorter compilation time > as well as people who needs this kind of information for writing optimizations, > but building time of MemorySSA also

It is UB when a poison is passed to certain operations that raise UB on poison, such as division by poison/dereferencing poison pointer/branching on poison condition/etc. Otherwise, poison is simply propagated, but it does not raise UB Copying poison bytes is okay: // Members are initialized to poison at object creation. p = alloca {i8, i32} // p[0], p[4~7] are poison q = alloca {i8, i32} // we

Two thoughts: 1. I think that we should aim for regularity, to the extent possible, and so we should treat nonnull, align, etc. similarly w.r.t. to whether they produce poison or UB. 2. I was thinking about the following last night, and it clarified for me why having an not_poison attribute makes sense and seems useful, and how poison/UB might affect things on a function-call boundary itself.

It seems MemorySSA.cpp is the only real code where we found the problem happening. Is it possible to change the source of MemorySSA.cpp to hide the problem and buy some time for now? Now we use an empty generic_def_path_iterator with Optional<ListIndex> N being initialized by None as the end of range. Can we initialize the Optional var with a special value instead of None?

On 07/18/2017 06:03 PM, David Majnemer via llvm-dev wrote: > I doubt it is possible for us to try and make any fix which is > predicated on eagerly treating undef in a particular way, refinement > will always cause these problems to come about... > > Given what I've seen in LLVM (and what I've learned from other > compilers), we probably have two choices: > 1.

Hi, On Mon, Jul 17, 2017 at 1:56 PM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Mon, Jul 17, 2017 at 1:53 PM, Wei Mi <wmi at google.com> wrote: >> >> It seems MemorySSA.cpp is the only real code where we found the >> problem happening. > > > This is doubtful, ¸FWIW :) > >> >> Is it possible to change the