search for: promotemem2reg

For a machine like an FPGA with no stack, you have to ensure that you have an optimization that rewrites the alloca into either registers (such as PromoteMem2Reg) or that you rewrite the alloca by declaring a static local, and rewriting the code to use that instead of the alloca result. Mark Mendell From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Bruce Hoult via llvm-dev Sent: December 14, 2018 3:27 PM To: jjones at prc-hsv.com Cc:...

...e file called sv_client.c indeed works on OSX, but on Linux X86 -O3 it still does not work. More in particular, the frontend is now stuck inside the for-loop on lines 176-->391 of PromoteMemoryToRegister.cpp when in the control flow of -scalarrepl: #4 0x08764f72 in (anonymous namespace)::PromoteMem2Reg::run (this=0xbff9bfa0) at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ Utils/PromoteMemoryToRegister.cpp:271 #5 0x08767021 in llvm::PromoteMemToReg (Allocas=@0xbff9c120, ET=@0x8b14c10, DF=@0x8b14d98, AST=0x0) at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Tran...

...makes it impossible for LLVM-based verifiers (such as KLEE) to find an uninitialized local variable bug in such examples. By the way, if 10 is replaced by a non-constant, mem2reg pass will produce "ret i32 undef" as a result, which is much closer to the original code. The problem lies in PromoteMem2Reg::RewriteSingleStoreAlloca function: it explicitly avoids checking whether a load is dominated by a store if an argument to the store is a constant. The comment in the code ("Non-instructions are always dominated") is incorrect as subsequent code checks whether the load is dominated by the...

Hi, I want to run the Mem2Reg pass on a function without using the the LLVM opt utility. I wrote some code, which I am not sure is correct: TS_ASSERT(!verifyFunction(*function)); // find the dominance frontier of the CFG DominanceFrontier DF; DF.runOnFunction(*function); // try to promote stack allocated variables PromoteMemToReg(function->getRegAllocas(), DF, *tgt_data);

...lient.c indeed works on > OSX, but on Linux X86 -O3 it still does not work. More in particular, > the frontend is now stuck inside the for-loop on lines 176-->391 of > PromoteMemoryToRegister.cpp when in the control flow of -scalarrepl: > > #4 0x08764f72 in (anonymous namespace)::PromoteMem2Reg::run > (this=0xbff9bfa0) > at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ > Utils/PromoteMemoryToRegister.cpp:271 > #5 0x08767021 in llvm::PromoteMemToReg (Allocas=@0xbff9c120, > ET=@0x8b14c10, DF=@0x8b14d98, AST=0x0) > at /home/bram/workspace/svn/aspi...

I have a question about PromoteMem2Reg::RewriteSingleStoreAlloca. Specifically, this bit of code: // If the store dominates the block and if we haven't processed it yet, // do so now. We can't handle the case where the store doesn't dominate a // block because there may be a path between the store and the use,...

...no (normal) stack On Mon, Dec 17, 2018 at 6:14 AM Mendell, Mark P <mark.p.mendell at intel.com<mailto:mark.p.mendell at intel.com>> wrote: For a machine like an FPGA with no stack, you have to ensure that you have an optimization that rewrites the alloca into either registers (such as PromoteMem2Reg) or that you rewrite the alloca by declaring a static local, and rewriting the code to use that instead of the alloca result. You'll then have to make sure programs never have recursion. When it comes down to it, nothing we run programs on actually has a true unbounded stack. We just have a r...

Thanks, no malloc or free equivalents either (no heap). So, there are no others (to your knowledge) who have built an LLVM backend for a platform with no “normal” stack? I found a presentation about some FPGA work (using LLVM) but it doesn’t seem to apply to my platform. Perhaps someone else on the mailing list will have come across this rarity? Thank you again for your time and