similar to: [LLVMdev] Confuse on getSCEVAtScope

Displaying 20 results from an estimated 500 matches similar to: "[LLVMdev] Confuse on getSCEVAtScope"

2010 Jun 29
0
[LLVMdev] Confuse on getSCEVAtScope
On Jun 29, 2010, at 7:08 AM, ether zhhb wrote: > > why computeSCEVAtScope not try to get the operands in the current > scope like the function do with SCEVCommutativeExpr, like: > > if (const SCEVAddRecExpr *AddRec = dyn_cast<SCEVAddRecExpr>(V)) { > if (!L || !AddRec->getLoop()->contains(L)) { > ... > // Then, evaluate the AddRec. >
2011 May 01
0
[LLVMdev] ScalarEvolution::getSVECAtScope
Hi, Is it valid to query ScalarEvolution::getSCEVAtScope with a Value which is an Instruction inside the provided Loop? If so, I believe there is a bug in computeSCEVAtScope. Specifically: 04716     // If the scope is outside the addrec's loop, evaluate it by using the 04717     // loop exit value of the addrec. 04718     if (!AddRec->getLoop()->contains(L)) { 04719       // To
2011 May 01
0
[LLVMdev] ScalarEvolution::getSVECAtScope
Nevermind. I misread the documentation. On Sat, Apr 30, 2011 at 8:12 PM, Thomas Jablin <tjablin at gmail.com> wrote: > Hi, > > Is it valid to query ScalarEvolution::getSCEVAtScope with a Value > which is an Instruction inside the provided Loop? If so, I believe > there is a bug in computeSCEVAtScope. Specifically: > > 04716     // If the scope is outside the
2011 Nov 21
1
[LLVMdev] Fwd: Order of Basic Blocks
---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Mon, Nov 21, 2011 at 10:30 AM Subject: Re: [LLVMdev] Order of Basic Blocks To: Benjamin Kramer <benny.kra at googlemail.com> This worked, though the RPO_iterator apparently wasn't what I was looking for anyways, it seems it doesn't rreally go top->down. I have a simple example code,
2016 Feb 08
2
LoopIdiomRegognize vs Preserved
Hi, I'm having problems with the LoopIdiomRegognizer crashing on me with An asserting value handle still pointed to this value! UNREACHABLE executed at ../lib/IR/Value.cpp:695! If I remove AU.addPreserved<LoopInfoWrapperPass>(); or AU.addPreserved<AAResultsWrapperPass>(); everything goes well. The C-code triggering this is void foo(int a[10][10]) { int i, j,
2007 Jun 12
3
[LLVMdev] ARM backend problem ?
Hello, I want to compile a LLVM file into an executable running on ARM platform. I use LLVM 2.0 with the following command lines: llvm-as -f -o test.bc test.ll llc -march=arm -mcpu=arm1136j-s -mattr=+v6 -f -o test.s test.bc arm-linux-gnu-as -mcpu=arm1136j-s test.s With the last command, I obtain the following error: rd and rm should be different in mul The bad instruction is
2010 Aug 05
3
[LLVMdev] a problem when using postDominatorTree
On 08/05/2010 06:46 AM, Wenbin Zhang wrote: > Hi all, > I'm using postDominatorTree to do some program analysis. My code works > well for small tests, but when I run it on real applications, the > following error occurs: > /Inorder PostDominator Tree: DFSNumbers invalid: 0 slow queries. > [1] <<exit node>> {0,21} > [2] %bb1 {1,2} > [2] %bb {3,4} > [2]
2007 Jun 12
0
[LLVMdev] ARM backend problem ?
Hi Mikael, You are obtaining warning, not an error, right? The most arm cores, including arm1136, can execute mul with rd = rm. So, you can ignore this warning. Lauro 2007/6/12, Peltier, Mikael <m-peltier at ti.com>: > > > > > Hello, > > > > I want to compile a LLVM file into an executable running on ARM platform. > > I use LLVM 2.0 with the following
2009 Sep 03
2
[LLVMdev] Non-local DSE optimization
Hi, It looks like PDT.getRootNode() returns NULL for: define fastcc void @c974001__lengthy_calculation. 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { entry: br label %bb bb: br label %bb } Isn't it a bug in PostDominatorTree? Please note that this crashes: opt -postdomtree -debug dom_crash.bc I think this should be reported as a bug, -Jakub On Sep 3, 2009, at
2009 Sep 03
0
[LLVMdev] Non-local DSE optimization
Hi Jakub, interesting patch. I ran it over the Ada testsuite and this picked up some problems even without enabling dse-ssu. For example, "opt -inline -dse -domtree" crashes on the attached testcase. Ciao, Duncan. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dom_crash.ll URL:
2012 Nov 26
2
[LLVMdev] LSR pass
Hi, I would like some help regarding the LSR pass. It seems that it likes to duplicate address calculations as in the case above, which is highly undesirable on my target. I wonder if there is any way to tell LSR to not duplicate the code in cases like this? Or could I perhaps run CSE after LSR again? What is the logic behind this transformation? It seems that a LSR pass should not insert a
2009 Aug 31
2
[LLVMdev] Non-local DSE optimization
Hello, This patch adds non-local DSE optimization. It uses Static Single Use representation. This is my first "big" patch, please be tolerant :-) Please note that optimization is disabled by default. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: dse_ssu.patch Type: application/octet-stream Size: 17352 bytes Desc: not available URL:
2011 Jul 07
1
[LLVMdev] code generation removes duplicated instructions
Ok. Let me describe the problem again in some detail. The following is the original bitcode from a real testcase: bb7: %46 = load i32* %j, align 4 %47 = add nsw i32 %46, 1 store i32 %47, i32* %j, align 4 br label %bb8 To protect the operand of the store I duplicate the input chain of operands and insert a comparison to check whether the operand of the stores are correct. As a result of
2008 May 02
4
[LLVMdev] Pointer sizes, GetElementPtr, and offset sizes
The LLVA and LLVM papers motivate the GetElementPtr instruction by arguing that it abstracts implementation details, in particular pointer size, from the compiler. While it does this fine for pointer addresses, it does not manage it for address offsets. Consider the following code: $ cat test.c int main() { int *x[2]; int **y = &x[1]; return (y - x); } $ llvm-gcc -O3 -c test.c
2010 May 08
2
[LLVMdev] Remove identical or redundant basic blocks?
Dear all, after optimizing a small LLVM example program (i.e., with opt -O3), the resulting code contains several basic blocks, which I consider identical or redundant. For instance, return: ; preds = %min.exit ret i32 0 bb15: ; preds = %min.exit ret i32 0 or, bb7.i:
2011 Jul 07
0
[LLVMdev] code generation removes duplicated instructions
On 7 July 2011 00:02, D S Khudia <daya.khudia at gmail.com> wrote: > I am trying to add a intrinsic call between the similar two instructions > which either I'll remove or convert to nop in codegen. If the two instructions are only similar in your real example, than you need to make them similar in your test, not identical. Different offsets, different array... If them two are
2010 Aug 05
0
[LLVMdev] a problem when using postDominatorTree
I'll try the trunk, as well as check my code again. If indeed it's not fixed, I'll try to post a triggering case here. Thanks for the advice~ Best, --Wenbin ----- Original Message ----- From: "Tobias Grosser" <grosser at fim.uni-passau.de> To: "Wenbin Zhang" <zhangwen at cse.ohio-state.edu> Cc: <llvmdev at cs.uiuc.edu> Sent: Thursday, August
2011 Jul 06
2
[LLVMdev] code generation removes duplicated instructions
Hi Renato, I am trying to add a intrinsic call between the similar two instructions which either I'll remove or convert to nop in codegen. Does that kind of seem appropriate for the purpose here? Thanks Daya On Wed, Jul 6, 2011 at 11:55 AM, Renato Golin <renato.golin at arm.com> wrote: > On 6 July 2011 15:57, D S Khudia <daya.khudia at gmail.com> wrote: > > Since I am
2010 May 08
2
[LLVMdev] Remove identical or redundant basic blocks?
Would it make sense to have a similar pass that operates on llvm main IR? On Sat, May 8, 2010 at 5:15 PM, Dale Johannesen <dalej at apple.com> wrote: > The branch folding pass does this, but it operates later, on the > target-dependent form in llc. > > On May 8, 2010, at 8:48 AM, Heinz Riener wrote: > >> Dear all, >> >> after optimizing a small LLVM example
2009 Sep 06
0
[LLVMdev] Non-local DSE optimization
Jakub Staszak wrote: > Hi, > > It looks like PDT.getRootNode() returns NULL for: > > define fastcc void @c974001__lengthy_calculation. > 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { > entry: > br label %bb > > bb: > br label %bb > } > > > Isn't it a bug in PostDominatorTree? > > Please note that this crashes: >