[PATCH] TTI: Add getCallInstrCost.

[Michael Zolotukhin]

================
Comment at: include/llvm/CodeGen/BasicTTIImpl.h:681
@@ +680,3 @@
+                                    RetTy->getVectorNumElements()))
+      return ScalarCost;
+
----------------
hfinkel wrote:
> mzolotukhin wrote:
> > hfinkel wrote:
> > > That's not quite right. You still need to call getCallInstrCost with the associated vector types.
> > Hi Hal,
> > 
> > I don't think I get it. When the types are vector, we first call getCallInstrCost for corresponding scalar types and then return `ScalarCalls*ScalarCost+ScalarizationCost` for not vectorizable functions and `ScalarCost` for vectorizable ones. If the types are scalar, we just return 10. What's missing here?
> > 
> > Could you please elaborate your point a little?
> The key problem here is that this logic does not belong inside the cost-model interface. What the cost model is supposed to provide is an interface that can be used for the vectorizer (and other clients) to ask the target, "Given this instruction on values of these types, please provide an estimate of the relative reciprocal throughput." The logic of how to transition from scalar instructions to vector instructions must live in the vectorizer, not inside the cost model. You're assuming too much about the actions that will be taken by the user of the interface by using the function-vectorization logic inside the most model to provide an estimate based on, not only the provided instruction and types, but also how the vectorizer will likely replace the queried function call with some other one.
> 
> We might not want to create external function declarations for each function we might wish to query as part of the interface, so we'll either need to allow for F to be nullptr, or change the interface.
> 
> What we're querying here is the cost of the function call, as provided, any logic related to vectorization needs to live inside the vectorizer, only the vectorizer knows how it will vectorize, and how to formulate any scalarization cost. The only scalarization costs that the TTI interface should know about, are those that will be incurred by the type legalization process in CodeGen -- those introduced at the IR level by TTI's users, need to be estimated by TTI's users based on how that scalarization is actually done.
> 
Ok, I see what you mean now, thank you for the explanation!

Then my plan is to leave in TTI only trivial getCallCost, which will always return 10 (in default implementation). The current logic, which takes into account scalarization costs, will be moved to the  vectorizer almost unchanged. With such changes back-ends could control the vectorizer by setting costs of Call, InsertElement and ExtractElement instructions. Does it sound good?

http://reviews.llvm.org/D8094

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/