The existing CodeGenOpt is not flexible enough for our needs. Our
customers want to be able to control the optimization level at a fine
grain, so we provide them separate dials for general optimization, fp
optimization and memory hierarchy optimization.
I would like to replace the existing CodeGenOpt::Level enum with a more
general CodeGenOpt class that can track different sets of optimization
level. Initially it would look something like this:
class CodeGenOpt {
...
public
getOptLevel() ...;
getFPLevel() ...;
getMemLevel() ...;
};
Does this sound reasonable?
-Dave
On Feb 23, 2011, at 1:49 PM, David Greene wrote:> The existing CodeGenOpt is not flexible enough for our needs. Our > customers want to be able to control the optimization level at a fine > grain, so we provide them separate dials for general optimization, fp > optimization and memory hierarchy optimization. > > I would like to replace the existing CodeGenOpt::Level enum with a more > general CodeGenOpt class that can track different sets of optimization > level. Initially it would look something like this: > > class CodeGenOpt { > ... > public > getOptLevel() ...; > getFPLevel() ...; > getMemLevel() ...; > }; > > Does this sound reasonable?I don't think that this is the right way to go. Higher level decisions like that should affect your choice of passes to schedule. -Chris
Chris Lattner <clattner at apple.com> writes:>> class CodeGenOpt { >> ... >> public >> getOptLevel() ...; >> getFPLevel() ...; >> getMemLevel() ...; >> }; >> >> Does this sound reasonable? > > I don't think that this is the right way to go. Higher level > decisions like that should affect your choice of passes to schedule.But there's no way to do that at the codegen level. LLVMTargetMachine keys off of CodeGenOpt. -Dave