Displaying 4 results from an estimated 4 matches for "lowerswitchid".
Did you mean:
lowerswitch
2006 May 03
1
[LLVMdev] Patch for transform dependencies
...{
AU.addRequired<DominanceFrontier>();
AU.addRequired<TargetData>();
AU.setPreservesCFG();
+ // This is a cluster of orthogonal Transforms
+ AU.addPreserved<UnifyFunctionExitNodes>();
+ AU.addPreservedID(LowerSelectID);
+ AU.addPreservedID(LowerSwitchID);
}
};
Index: ./lib/Transforms/Scalar/LowerSelect.cpp
===================================================================
RCS file: /var/cvs/llvm/llvm/lib/Transforms/Scalar/LowerSelect.cpp,v
retrieving revision 1.4
diff -u -p -r1.4 LowerSelect.cpp
--- ./lib/Transforms/Scalar/LowerSelect.cp...
2006 May 03
2
[LLVMdev] Conflicting passes?
Hi all,
Why are these two passes conflicting: UnifyFunctionExitNodes and LowerSwitch?
AU.addRequired(LowerSwitchID) works, so does AU.addRequired<unifyFunctionExitNodes>(),
but the two together don't...
opt: PassManagerT.h:387: void llvm::PassManagerT<Trait>::markPassUsed(const llvm::PassInfo*, llvm::Pass*) [with Trait = llvm::MTraits]: Assertion `getAnalysisOrNullUp(P) && dynamic_cas...
2006 Jul 25
1
[LLVMdev] Dubious Library Dependencies
...LLVMCodeGen.a(
llvm::MVT::getVectorType(llvm::MVT::ValueType, unsigned int))
The following dependencies is not a singleton, but they it just seemed
dubious to me that "TransformUtils" would depend on ScalarOpts.
libLLVMTransformUtils.a:
libLLVMScalarOpts.a
llvm::LowerSelectID
llvm::LowerSwitchID
llvm::PromoteMemoryToRegisterID
Something else that came up fairly often. Several libraries depend on
libLLVMTarget.a solely to get at the TargetData class. Perhaps this
should be moved to VMCore?
Hope this helps resolve the cyclic dependencies in LLVM.
Reid.
2006 May 03
1
[LLVMdev] Conflicting passes?
...hem both
b) Sequencing and "property preservation" still look like optimization
to me (a very useful, but also limiting one). If runOnFunction() calls
are assumed to be independent, for each function, the PassManager could
call:
UnifyFunctionExitNodes which destroys all properties, and
LowerSwitchID, which should be able to rebuild what it needs.
The order might be implementation-dependent, and that's the only problem
I see. However, in this case those two passes do orthogonal transforms,
and it doesn't really matter which runs first. Even if it does, the
sequence of addRequired<&g...