[LLVMdev] CodeGenOpt

David A. Greene dag at cray.com
Thu Feb 24 09:30:11 PST 2011


Devang Patel <dpatel at 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



More information about the llvm-dev mailing list