search for: loopsimplyf

...from. It seems to me that LoopSimplify.cpp is in the wrong place. This file defines the LoopSimplify FunctionPass which doesn't seem to me to be a "transform util". I thought the purpose of "Transforms/Util" was to provide utilities that are common amongst transforms. But, LoopSimplyf *is* a transform. So, I think the solution is to move LoopSimplify.cpp out of Transforms/Utils to somewhere else, say just "Transforms. By doing this, we probably eliminate the cycle. I'm going to validate that shortly. Reid. On Wed, 2006-03-22 at 09:26 -0500, Eric Kidd wrote: > On Ma...

...e that LoopSimplify.cpp is in the wrong > place. This file defines the LoopSimplify FunctionPass which doesn't > seem to me to be a "transform util". I thought the purpose of > "Transforms/Util" was to provide utilities that are common amongst > transforms. But, LoopSimplyf *is* a transform. So, I think the solution > is to move LoopSimplify.cpp out of Transforms/Utils to somewhere else, > say just "Transforms. By doing this, we probably eliminate the cycle. > I'm going to validate that shortly. > > Reid. > > On Wed, 2006-03-22 at 09:26...

On Mar 21, 2006, at 11:23 PM, Chris Lattner wrote: >>> LLVMCodeGen.o LLVMSelectionDAG.o libLLVMAnalysis.a >>> libLLVMTarget.a >>> libLLVMTransformUtils.a libLLVMipa.a > > CodeGen should depend on Target, but not the other way around. > LLVMIPA should depend on LLVMAnalysis, but certainly nothing in the > list should depend on LLVMIPA. If you knew

On Tue, 21 Mar 2006, Reid Spencer wrote: > About the only thing I can suggest are: > > 1. Combine LLVMSparc*.o into one LLVMSparc.a. That work is already > happening with the new Sparc backend that is being developed. Should be > out in 1.7 (Chris?) I wouldn't worry about the SparcV9 backend for your project. > 2. Combine the JIT/Interpreter/ExecutionEngine into one .a