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