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
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@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
If you look at addCommonCodeGenPasses() then you'll see that CodeGenOpt is not used to select passes. Yes, CodeGenOpt::None is checked at few places to ensure that we are doing optimization, but it is not checking *level* of optimization.
If seems you want better approach to influence pass selection in addCommonCodeGenPasses() for your needs. If so, why not try to do what we did in 'opt' using StandardPasses.h ? (Note, I have not thought through this suggestion, I am just thinking loudly here)
Devang Patel <dpatel@apple.com> writes:
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.
If you look at addCommonCodeGenPasses() then you'll see that
CodeGenOpt is not used to select passes. Yes, CodeGenOpt::None is
checked at few places to ensure that we are doing optimization, but it
is not checking *level* of optimization.
True, but it could and in our case, will.
If seems you want better approach to influence pass selection in
addCommonCodeGenPasses() for your needs. If so, why not try to do what
we did in 'opt' using StandardPasses.h ? (Note, I have not thought
through this suggestion, I am just thinking loudly here)
It's not just pass selection. CodeGenOpt gets passed to the scheduler,
dagcombine and several other places. We need to influence decisions
made in those places as well. We still want to run the passes, but have
them behave differently.
Something like StandardPasses.h could improve the situation in
addCommonCodeGenPasses, but it doesn't solve the whole problem. And in
any event, a StandardPasses.h for codegen would still want to know about
various optimization levels, so we still need a way to represent it.
Another way of saying this is that StandardPasses.h is also not flexible
enough and I don't think adding more flags to the create*Passes
interfaces is the right way to go. To me, a centralized, flexible way
of representing optimization variations that can be passed around for
inspection is more convenient than remembering which flags should be
passed where.
-Dave