similar to: [LLVMdev] [LLVMDev] About user of bitcast/GEP instruction

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, If the special handling in the meg2reg pass is to look for lifetime intrinsics, shouldn't it cast to <IntrisicInst> and then use getInstrinsicID to check for lifetime_start and lifetime_end ? The thing that I don't understand is the following piece of code, which finds all the users and cast it to <Instruction> then eraseFromParent(). How can this guarantee that it only

----- Original Message ----- > From: "guoqing zhang" <gqzhang81 at gmail.com> > To: llvmdev at cs.uiuc.edu > Sent: Friday, January 30, 2015 4:29:16 AM > Subject: [LLVMdev] About user of bitcast/GEP instruction > > Hi, > > > In PromoteMemoryToRegister.cpp, it seems to rely on the fact that the > only users of bitcast/GEP instruction are lifetime

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

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

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]

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 Dave, As an exercise I tried to fix this myself, and I think I have a working patch (attached). My own tests are all working wonderfully, and at fantastic performance! I'm looking forward to your patch to see whether we used the same approach or whether things could be improved further. Anyway, I've re-profiled the code and found ComputeLiveInBlocks to be the main hotspot now. Again

> There should be no difference between using llvm-gcc at some -O > level, and running it at -O0 and using opt to run the passes on > the unoptimized bitcode. However, you wrote earlier: > Finally, llvm-gcc runs the following passes on each function > immediately after it is created: > > CFGSimplification, PromoteMemoryToRegister, > ScalarReplAggregates,

On Tue, May 20, 2008 at 2:28 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 20, 2008, at 8:57 AM, David Greene wrote: > >> On Tuesday 20 May 2008 07:03, Nicolas Capens wrote: >> >>> 1) Does ScalarReplAggregates totally superscede >>> PromoteMemoryToRegister? I >> >> Nope, they are different. Mem2Reg is really important if you

2009/3/17 Shone Sadler <shone.sadler at gmail.com>: > 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. mem2reg (llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp) transforms to SSA form, but that's the conventional SSA construction algorithm, which doesn't

Chayan Sarkar wrote: > 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 . http://llvm.org/docs/Passes.html#mem2reg which is lib/Transforms/Utils/PromoteMemoryToRegister.cpp. Nick

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.

Hello, in the implementation of some analysis, I need to change the program and then invoke Mem2Reg pass. That pass, in turn, requires other analysis, so I must use PassManager. Here's the code I ended up with: bool runOnFunction(llvm::Function& m) { visit(m); ExistingModuleProvider mp(m.getParent());

Tobias Grosser wrote: > On 04/17/2013 05:53 PM, Sebastian Pop wrote: > >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

On 04/17/2013 05:53 PM, Sebastian Pop wrote: > 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 > ///

Hello, I have some code which I was hoping the LLVM optimization passes would get rid of for me, but no such luck -- all the code does is store four float 0.f to memory, load four other floats from memory, load back the first four floats, multiply them together (here we should have always get 0) and finally store them back to memory. Any ideas why this isn't picked up by the constant