Displaying 8 results from an estimated 8 matches for "etforest".
2006 May 03
0
[LLVMdev] Conflicting passes?
...you, just in the case I mixed-up something:
(Chris, I'd also appreciate you wise thoughts on this. I'm sure
that other users are banging into this wall too.):
Requirements:
- several conflicting passes before myPass
- call runOnFunction in reverse topological order
- have DominatorTree, ETForest, LoopInfo and some other analyses
available
- possibly, I'll need access to DSAA
Possible solution:
- batch the conflicting transforms
- write myPass as a subclass of FunctionPass
- write myPass.runOnFunction like:
runOnFunction() {
if (!calledFromPassManager) {
doStuff();
}
}
- use...
2007 May 29
2
[LLVMdev] (no subject)
Hi everyone,
Llvm-gcc compiles the programs into bytecodes with some optimizations. How can I get unoptimized bytecodes?
Thanks.
Regards,
-Ying
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070530/5f793e95/attachment.html>
2007 May 29
0
[LLVMdev] (no subject)
Using
llvm-gcc -emit-llvm -O0 -S blah.c
will give you blah.s that is unoptimized. I guess passing that to llvm-as
would get you an unoptimized .bc.
llvm-as -debug-pass=Arguments blah.ll says it is only doing
Pass Arguments: -domtree -etforest -verify
scott
On 5/29/07, omiga <omiga at ustc.edu> wrote:
>
> Hi everyone,
>
> Llvm-gcc compiles the programs into bytecodes with some optimizations.
> How can I get unoptimized bytecodes?
> Thanks.
>
>
> Regards,
>
> -Ying
>
> ____________________...
2006 May 09
1
[LLVMdev] Memory leaks in LLVM
...0,172 (15,624 direct, 44,548 indirect) bytes in 558 blocks are
definitely lost in loss record 31 of 33
==10132== at 0x401C7F0: operator new(unsigned) (vg_replace_malloc.c:164)
==10132== by 0x8499B7E: llvm::ETNode::setFather(llvm::ETNode*) (
Dominators.cpp:661)
==10132== by 0x849A2CE:
llvm::ETForest::getNodeForBlock(llvm::BasicBlock*) ( Dominators.cpp:848)
==10132== by 0x849A467:
llvm::ETForest::calculate(llvm::ImmediateDominators const&) (Dominators.cpp
:865)
==10132== by 0x85010FD: llvm::ETForest::runOnFunction(llvm::Function&) (
Dominators.h :506)
==10132== by 0x850FD3E:
ll...
2006 Jul 05
0
[LLVMdev] Critical edges
...it is likely
to generate incorrect code (besides the problem of not inserting
branch instructions)?
Thanks a lot,
Fernando
Code ---------------------------------------------------------------
void CriticalEdgeRemoval_Fer::getAnalysisUsage
(AnalysisUsage & AU) const {
AU.addPreserved<ETForest>();
AU.addPreserved<DominatorSet>();
AU.addPreserved<ImmediateDominators>();
AU.addPreserved<DominatorTree>();
AU.addPreserved<DominanceFrontier>();
AU.addPreserved<LoopInfo>();
AU.addPreservedID(LoopSimplifyID);
}
bool CriticalEdgeRemoval_...
2006 Jul 04
2
[LLVMdev] Critical edges
On Tue, 4 Jul 2006, Fernando Magno Quintao Pereira wrote:
> However, it does not remove all the critical edges. I am getting a very
> weird dataflow graph (even without the Break Critical edges pass). The
> dataflow generated by MachineFunction::dump() for the program below is
> given here:
> http://compilers.cs.ucla.edu/fernando/projects/soc/images/loop_no_crit2.pdf
...
> The
2007 May 23
0
LLVM 2.0 Release
...ows ModulePasses to use the result of
FunctionPasses. This requires holding multiple FunctionPasses (e.g.
dominator info) in memory at a time.
14. Owen and Devang both worked to eliminate the [Post]DominatorSet
classes from LLVM, switching clients to use the far-more-efficient
ETForest class instead. Owen removed the ImmediateDominator class,
switching clients to use DominatorTree instead. These changes reduce
memory usage and speed up the optimizer.
Target-Independent Code Generator Enhancements:
15. Jim, Anton and Duncan contributed many enhancements and improvem...
2007 May 14
3
[LLVMdev] llvm 2.0 release announcement [draft]
...rt that allows ModulePasses to use the result
of FunctionPasses. This requires holding multiple FunctionPasses
(e.g. dominator info) in memory at a time.
x. Owen and Devang both worked to eliminate the [Post]DominatorSet
classes from LLVM, switching clients to use the far-more-efficient
ETForest class instead. Owen removed the ImmediateDominator class,
switching clients to use DominatorTree instead. These changes reduce
memory usage and speed up the optimizer.
Target-Independent Code Generator Enhancements:
x. Jim, Anton and Duncan contributed many enhancements and
improvement...