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