[PATCH] D15816: [TTI] Add hook for contextual cast estimates

Hal Finkel via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 2 16:39:54 PST 2016


hfinkel added inline comments.

================
Comment at: include/llvm/Analysis/TargetTransformInfo.h:468
@@ -440,3 +467,3 @@
 
   /// \return The expected cost of control-flow related instructions such as
   /// Phi, Ret, Br.
----------------
We definitely need this kind of functionality, but I share James's uncomfortableness with forcing the user to reencode some arbitrary portion of the use/def graph. Part of the problem is that the user of the interface has no idea how much of the graph would be useful to encode. Plus, the things you're reencoding into are essentially instructions that aren't instructions. While we generally have a policy against creating temporary instructions, getting around that by reinventing instructions seems unsatisfying.

What if we defined an abstract graph-traversal class that could be used by a TTI implementation to walk a (mutated) view of the existing SSA use/def graph.

  struct InstrContextView {
    struct InstrContext {
       Type *Ty;
       unsigned Opcode;
       unsigned NumOperands;
    };

    // Call this to get the initial instruction context (the starting point of the view on the use/def chain)
    virtual InstrContext *getInstrContext() = 0;
    virtual InstrContext *getOperandInstrContext(const InstrContext *, unsigned OpNum) = 0;
    virtual unsigned getNumInstrContextUsers(const InstrContext *) = 0;
    virtual InstrContext *getUserInstrContext(const InstrContext *, unsigned UserNum) = 0;
  };

Then the TTI interfaces take some derived class of InstrContextView, which holds the necessary state to provide whatever view is possible given the caller's knowledge of the potential IR. In this way, the creation of the InstrContext objects can be completely lazy.

The downside is that, because the traversal functions need to be virtual, walking large portions of the graph this was is not feasible. Luckily, I think we never want to do that.


http://reviews.llvm.org/D15816





More information about the llvm-commits mailing list