On Thursday 09 August 2007 17:27, Chris Lattner wrote:> > So what's the right way to do this? There's the regalloc way, which > > invents a whole new class just to register register allocators and > > provide an option for picking one. But alias analysis already uses > > AnalysisGroup so a new class to register alias analysis passes isn't > > necessary. > > I'm not sure what you mean. The passmgr already fully supports this.Regalloc doesn't use PassManager to handle its options. It uses a sort of AnalysisGroup-like scheme to provide the -regalloc=foo option.> > It seems desireable to augment AnalysisGroup with the ability to provide > > command-line options. Is this a good strategy or is there a better way? > > Command line options are already fully published by opt. llvm-gcc > intentionally does not publish all of the llvm options through cc1. We > can add new options, but that has to be an explicit design decision. We > do allow you to use some options through -mllvm -foo, but that won't help > in this case. > > Also note that the current implementation of andersens is "research > quality".Alias analysis is just the closest example of what I really need to do: provide an option to choose a coalescer. I've got a scheme where coalescers register with an AnalysisGroup (just like AA) and I need a way to pick one at runtime. This really has nothing to do with llvm-gcc. It's a question of how to provide command-line options for choosing members of an AnalysisGroup where the trick used by opt is not available (because one doesn't want to expose all of the passes as options). opt does it by registering each Pass with a command-line option. Regalloc does it in the special way described above (maybe this is invokable from llvm-gcc since the cl_opt is a static but I haven't tried it). My question is whether AnalysisGroup should provide a mechanism to register command-line options. Then one could pick an alias analysis with, for example, -alias=andersens. Or -coalscer=aggressive. Or even -regalloc=linearscan if register allocation were recoded to use AnalysisGroup. It would be a nice way to unify all of these things. -Dave
On Thu, 9 Aug 2007, David Greene wrote:>> intentionally does not publish all of the llvm options through cc1. We >> can add new options, but that has to be an explicit design decision. We >> do allow you to use some options through -mllvm -foo, but that won't help >> in this case.> Alias analysis is just the closest example of what I really need to do: > provide an option to choose a coalescer. I've got a scheme where > coalescers register with an AnalysisGroup (just like AA) and I need a > way to pick one at runtime. This really has nothing to do with llvm-gcc. > It's a question of how to provide command-line options for choosing > members of an AnalysisGroup where the trick used by opt is not available > (because one doesn't want to expose all of the passes as options).Ah, I see ok. This is different then. :) We don't want the users of the *c compiler* to be able to choose different coallescers. Having selectable coallescers is useful for two communities: 1) people hacking on the compiler 2) people building other tools with other constraints. As far as the C compiler goes, we want to have just one option that works well, we don't want a million knobs people have to tweak. We already service #2 through various means, so you really want to help out #1. This is exactly what the -mllvm option is for: to pass random stuff down into the llvm command line option stuff without exposing it to the users through a sanctioned option.> My question is whether AnalysisGroup should provide a mechanism to > register command-line options. Then one could pick an alias analysis > with, for example, -alias=andersens. Or -coalscer=aggressive. Or even > -regalloc=linearscan if register allocation were recoded to use AnalysisGroup.Interesting question, I don't have an answer to this. To make things more complicated, you can have multiple instances of an analysis group and may want different things at different times: -basicaa -licm -something_that_invalidates_aa -andersaa -licm -whatever In the short term, adding a cl::opt to llvm-backend.cpp seems the easiest way to go, which makes it available through -mllvm. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Thursday 09 August 2007 19:21, Chris Lattner wrote:> As far as the C compiler goes, we want to have just one option that works > well, we don't want a million knobs people have to tweak.Agreed.> Interesting question, I don't have an answer to this. To make things more > complicated, you can have multiple instances of an analysis group and may > want different things at different times: > > -basicaa -licm -something_that_invalidates_aa -andersaa -licm -whateverMmm...yeah, that makes life interesting.> In the short term, adding a cl::opt to llvm-backend.cpp seems the easiest > way to go, which makes it available through -mllvm.Ok, I'll look at doing that. Thanks! -Dave
On Thursday 09 August 2007 19:21, Chris Lattner wrote:> Interesting question, I don't have an answer to this. To make things more > complicated, you can have multiple instances of an analysis group and may > want different things at different times: > > -basicaa -licm -something_that_invalidates_aa -andersaa -licm -whateverSome questions about that: How does this interact with analysis groups? When a class is registered as part of an analysis group there's a boolean template argument indicating whether it is the default pass for the group. If I say -andersaa on the command line (say it's the very first option), does that then make Andersen's the new default alias analysis so that passes that declare a dependence on AliasAnalysis will now get Andersen's instead of basicaa? Or do I really have to put -andersaa after every option that could invalidate alias analysis?>From the comments in PassSupport.h, it sounds like the former is true.Andersen's would be "available" and thus used. However, what happens when alias analysis information gets invalidated? Is Andersen's still "available" in the sense analysis groups use it? If not, it seems it would be tough to make sure Andersen's is always used everywhere that AliasAnalysis is asked for because there are passes llvm runs without any command-line directive and those passes could invalidate AA. Or is it sufficient than an Andersen's object is constructed and that that constitutes "availability?" What happens if multiple alias analyses are constructed? Is the most-recently constructed one considered the "available" one? -Dave