On Thursday 09 August 2007 16:29, Devang Patel wrote:> On Aug 9, 2007, at 2:22 PM, David Greene wrote: > > A better question to ask is, how do I do this with llvm-gcc? My > > perusal of > > the code doesn't turn up any obvious places for options for alias > > analysis > > are registered. > > As you've figured out, not all options are exposed by llvm-gcc. You'll > have to update llvm-gcc.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. 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? -Dave
On Thu, 9 Aug 2007, David Greene wrote:>> As you've figured out, not all options are exposed by llvm-gcc. You'll >> have to update llvm-gcc. > > 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.> 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". -Chris -- http://nondot.org/sabre/ http://llvm.org/
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