[PATCH] D25482: [PPC] Allow two post RA schedulers to be in the pipeline and select one depending on the Machine Function's subtarget

Ehsan Amiri via llvm-commits llvm-commits at lists.llvm.org
Sat Oct 29 11:00:11 PDT 2016


amehsan added inline comments.


================
Comment at: lib/CodeGen/MachineFunctionPass.cpp:94-98
+bool MachineFunctionPass::skipFunction(const MachineFunction &MF) const {
+  if (!MF.getSubtarget().runPass(this->getPassID()))
+    return true;
+
+  return FunctionPass::skipFunction(*MF.getFunction());
----------------
amehsan wrote:
> echristo wrote:
> > amehsan wrote:
> > > echristo wrote:
> > > > amehsan wrote:
> > > > > echristo wrote:
> > > > > > I'm not sure why you need all of this and can't write the skipFunction without needing a MachineFunction in specific. Can you explain for me?
> > > > > Because I need MachineFunction's subtarget. Does that answer your question?
> > > > Not really, but I'd missed any resolution (which didn't appear to happen) for the basic idea of passing in a function to the pass.
> > > > 
> > > > Can this be done similar to IfConversion instead? I'd really prefer not to have this overloading of the idea of skipFunction.
> > > I don't really understand what you mean by "the basic idea of passing in a function to the pass". Could you clarify?
> > > 
> > > By IfConversion I believe you are referring to D8717. Could you explain why you prefer that to overloading skipFunction? 
> > So D8717 allows targets to configure passes by passing in a callback at configuration time. skipFunction is a pretty terrible hack that originally existed as a mechanism to deal with optnone and has an ok side effect of being able to use it for bisection. It's not a use case that should be promulgated further, especially given that the configuration via call back is both easier to understand and just as configurable (and more localized).
> Let me try to explain why "skipFunction is a pretty terrible hack"
> 
> Ideally, when we have a noopt function, no optimization pass should be invoked. Our infrastructure does not allow us to do that, so we use this hack that each optimization first checks the function if it is noopt or not. 
> 
> Is this correct? If yes, are there other reason as well or not. If no, why skipFunction is a hack?
I wanted to edit my comment if possible, and clicked on "hide comment". Let me repeat it.

//Let me try to explain why "skipFunction is a pretty terrible hack"
//
//Ideally, when we have a noopt function, no optimization pass should be invoked. For some reason we cannot do that, so we use this hack that each optimization first checks the function if it is noopt or not.
//
//Is this correct? If yes, are there other reason as well? If no, why skipFunction is a hack?//


https://reviews.llvm.org/D25482





More information about the llvm-commits mailing list