similar to: Miscompilation bugs in GVN.cpp and PromoteMemoryToRegister.cpp?

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

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

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

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

Hi LLVMDev, this is Jeehoon Kang, a Ph.D. student of Software Foundations Laboratory ( http://sf.snu.ac.kr), Dept. of Computer Science & Engineering, Seoul National University. Our group studied the mem2reg pass, and we got a question on its algorithm. As far as I understand, the mem2reg pass essentially uses the SSA construction algorithm to promote allocas into registers, but there are

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

at line 216 'S' is declared with 'const' qualifier const DominanceFrontier::DomSetType &S = it->second; a few lines later an iterator over this set is asked for, instead of a const_iterator -- Visual C (rightfully) flags this as an error. Here is a patch... m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

Hi Dave, Did that patch of yours ever make it into trunk? I can't seem to find any related checkin for PromoteMemoryToRegister.cpp. I've been doing some extra profiling lately and the RewriteSingleStoreAlloca function alone is taking a whopping 63% of execution time. Thanks! Nicolas -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]

Hi, Today I managed to link ioquake3, but generating a binary does not work yet. 1) On OSX, I get: Error: Code generator does not support intrinsic function 'llvm.ppc.altivec.lvsl'! when I do: llc file.bc -march=c -o file.c 2) On Linux X86, llc does not give any problem, but I get this while compiling the generated .c file: error: unknown register name 'S' in

Hi, In PromoteMemoryToRegister.cpp, it seems to rely on the fact that the only users of bitcast/GEP instruction are lifetime intrinsics (llvm.lifetime.start/end). I did some searching in llvm/test folder, it seems to be true. However, by reading LLVM IR manual, I don't see any restriction stated on the possible user of bitcast/GEP instruction. So my question is who impose the restriction ?

On Wednesday 24 September 2008 09:35, Nicolas Capens wrote: > Hi Dave, > > Did that patch of yours ever make it into trunk? I can't seem to find any > related checkin for PromoteMemoryToRegister.cpp. I've been doing some extra > profiling lately and the RewriteSingleStoreAlloca function alone is taking > a whopping 63% of execution time. I will commit it today along with

Hi, In PromoteMemoryToRegister.cpp, it seems to rely on the fact that the only users of bitcast/GEP instruction are lifetime intrinsics (llvm.lifetime.start/end). I did some searching in llvm/test folder, it seems to be true. However, by reading LLVM IR manual, I don't see any restriction stated on the possible user of bitcast/GEP instruction. So my question is who impose the restriction ?

Hi, I wonder what PRE algorithm is used for the GVN.cpp in LLVM. Any reference will be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140930/3d7f74e3/attachment.html>

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>

Hi, I am new to llvm. I have project in llvm. For that I need SSA form, which is already implemented in llvm. Basically I want to know which pass insert phi and converts it to SSA form in llvm . Regards, Chayan

Hi, polly is run very early and schedules the following passes before it runs: /// @brief Schedule a set of canonicalization passes to prepare for Polly /// /// The set of optimization passes was partially taken/copied from the /// set of default optimization passes in LLVM. It is used to bring the code /// into a canonical form that simplifies the analysis and optimization passes /// of Polly.

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.

Thanks for the response. I was more specifically looking through the source code for a place where Reaching Definitions was implemented to derive those uses and/or to generate the SSA. To provide some context, as a student I have a project to implement a path infeasibility algorithm to "Sharpen" the results of the Reaching Definitions results in LLVM. Being new to LLVM I wasn't