similar to: [LLVMdev] DeadStoreElimination: do better without TargetData

Re-posting with better-looking code. Hans Wennborg wrote: > The attached patch makes DeadStoreElimination able to remove stores in > store-store dependencies when the operand types are equal, even if there > is no TargetData available. > > / Hans > > > ------------------------------------------------------------------------ > >

On Nov 4, 2009, at 7:21 AM, Hans Wennborg wrote: > Re-posting with better-looking code. Thanks, do you have a testcase showing what this does? -Chris > > Hans Wennborg wrote: >> The attached patch makes DeadStoreElimination able to remove stores >> in store-store dependencies when the operand types are equal, even >> if there is no TargetData available. >>

Sorry, I admit my e-mail was a bit unclear. Here is an example: declare void @foo() define void @f(i32* noalias %p) { store i32 1, i32* %p; <-- This is dead call void @foo() store i32 2, i32 *%p ret void } When run through ./llvm-as test.ll -o - | ./opt -O3 -S the dead store is not removed by the DSE pass. (The call to @foo is there to prevent InstCombine

Hi all, I am working on a project that requires LLVM DeadStoreElimination However, when I look through the code in Transforms/Scalar/DeadStoreElimination.cpp, I see the following: // Ignore any store where we can't find a local dependence. // FIXME: cross-block DSE would be fun. :) if (!InstDep.isDef() && !InstDep.isClobber()) continue; I have two questions on this

Hans Wennborg wrote: > Sorry, I admit my e-mail was a bit unclear. > Here is an example: > > declare void @foo() > > define void @f(i32* noalias %p) { > store i32 1, i32* %p; <-- This is dead > call void @foo() > store i32 2, i32 *%p > ret void > } Hold up. Is this correct? "noalias: This indicates that the pointer

On Nov 5, 2009, at 1:59 PM, Hans Wennborg wrote: > My apologies for not replying sooner; I've been away from keyboard all > day today. > >> Thanks, applied here: >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091102/090396.html >> >> >> I'd appreciate it if you could resend your other patches in patch >> format >> like

Hello, I fixed my patch as you asked. Sorry for the delay, I'd been working on my SSU patch (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025347.html ) I hope that everything is fine now. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: pr2218-3.patch Type: application/octet-stream Size: 7511 bytes Desc: not available URL:

It is possible to ask DataLayout about getTypeSizeInBits and also getTypeStoreSize. And there is a table showing an example of what it could look like: /// Size examples: /// /// Type SizeInBits StoreSizeInBits AllocSizeInBits[*] /// ---- ---------- --------------- --------------- /// i1 1 8 8 /// i8 8 8

On Sep 2, 2009, at 1:07 AM, Jakub Staszak wrote: > Hello, > > I fixed my patch as you asked. Sorry for the delay, I'd been working > on my SSU patch (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025347.html > ) > > I hope that everything is fine now. Hey Jakub, Thanks for working on this again, one more round :) Please merge the three testcases into one

On Sep 2, 2009, at 3:15 PM, Chris Lattner wrote: > Please merge the three testcases into one file. We added a new > FileCheck tool which allows you to check for the exact sequence of > instructions expected, which also allows the tests to be merged into > one file. > > +/// MemCpyOpt::pointerIsParameter - returns true iff pointer is a > parameter of > +/// C call

Hi, It looks like the DeadStoreElimination optimization doesn't work across BasicBlock boundaries. The project I'm working on (https://github.com/trailofbits/mcsema), would tremendously benefit from even simple cross-block DSE. There was a patch to do non-local DSE few years ago (http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-January/028751.html), but seems that the patch was never

Hi all, There might be a bug in DeadStoreElimination.cpp. This pass eliminates stores backwards aggressively in an end BB. It does not check dependencies on stores in an end BB though. For example, in this code snippet: ... 1. %sum.safe_r47.pre-phi = phi i64* [ %sum.safe_r47.pre, %entry.for.end_crit_edge ], [ %sum.safe_r42, %for.body ] 2. %call9 = call i32 @gettimeofday(%struct.timeval* %end,

On Thu, Oct 6, 2011 at 2:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Oct 6, 2011 at 2:12 PM, Zeng Bin <ezengbin at gmail.com> wrote: >> Hi all, >> >> There might be a bug in DeadStoreElimination.cpp. This pass eliminates >> stores backwards aggressively in an end BB. It does not check dependencies >> on stores in an end BB though.

Dear LLVM contributors, I work on the "Improvement of vectorization process in Polly". At the moment I'm trying to implement tiling, interchanging and unrolling of specific loops based on the following algorithm for the analytical modeling [1]. It requires information about the following parameters of a target architecture: 1. Size of double-precision floating-point number. 2.

I wrote a pass(that is to be loaded by opt) that I would like to use in conjunction with MemoryDependenceAnalysis. I have tried using by including its header and adding this to my pass:        virtual void getAnalysisUsage(AnalysisUsage &AU) const {         errs() << "addRequired called\n";         AU.addRequired<MemoryDependenceAnalysis>();        } And in my

On Thu, Oct 6, 2011 at 2:12 PM, Zeng Bin <ezengbin at gmail.com> wrote: > Hi all, > > There might be a bug in DeadStoreElimination.cpp. This pass eliminates > stores backwards aggressively in an end BB. It does not check dependencies > on stores in an end BB though. For example, in this code snippet: >   ... > 1.  %sum.safe_r47.pre-phi = phi i64* [ %sum.safe_r47.pre,

Something like: index 6db7f68..68564cb 100644 --- a/lib/Transforms/Vectorize/LoopVectorize.cpp +++ b/lib/Transforms/Vectorize/LoopVectorize.cpp @@ -1208,6 +1208,8 @@ void InnerLoopVectorizer::vectorizeMemoryInstruction(Instr Type *DataTy = VectorType::get(ScalarDataTy, VF); Value *Ptr = LI ? LI->getPointerOperand() : SI->getPointerOperand(); unsigned Alignment = LI ?

On Oct 30, 2012, at 3:15 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 10/30/2012 4:10 PM, Ashwin kumar wrote: >> >> Assertion failed: (PI && "Expected required passes to be initialized"), >> function schedulePass, file PassManager.cpp, line 597. >> >> >> I register the passes using RegisterPass function call.

Is there a way to get the sizeof a type? Say I've created a struct type without any explicit attribtues, and I want to call malloc() to allocate space for it. Can I get the size as an llvm::Constant* (or other llvm::Value*) given an llvm::StructType* or other llvm::Type*? TIA, -- Rick

It does not do anything. It is an abstract function which transforms a pointer and returns another pointer of the same type. It does not visit memory or capture the pointer parameter. On Thu, Oct 6, 2011 at 2:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Oct 6, 2011 at 2:20 PM, Eli Friedman <eli.friedman at gmail.com> > wrote: > > On Thu, Oct 6, 2011 at