CostModel analysis -- what is its actual purpose?

Greetings,

So the CostModel ‘analysis’ today isn’t actually an analysis at all. It is one of the only analyses which doesn’t even have an interface available outside of the .cpp file, so it is literally impossible to use it today.

The only use is to form tests of TargetTransformInfo, but if that’s really the only intent, then I have two somewhat large questions:

  1. Why isn’t this just the implementation of the print method for TTI? Should I make it into that?

  2. Why is there so much logic in it? This doesn’t really seem like it’s just testing TTI, it almost seems its duplicating some logic in the vectorizers to ensure that logic behaves correctly… But if so, that logic should really be de-duplicated into an actual analysis with an API that is used by the vectorizers…

Anyways, I’m asking because I’ve ported TTI to the new pass manager, but it the testing is quite weak. I can port CostModel as well, but I don’t really know what the right port is given that it is an analysis which can only be used to print things.

-Chandler

Yes.it is only meant to form tests of the cost model by writing llvm IR instructions. Typically, one IR instruction.

The only 'logic' it has today are the utility functions which allow for writing tests of horizontal vector reduction instruction costs. Since, there is no horizontal reduction IR instruction we have to model them as a sequence of instructions. That's what that logic does. The vectorizer does not have this logic because it sees a scalar reduction and then asks what the cost of doing this with vector instructions. It emits such a sequence of instructions but never tests for them (since this would mean the block was already vectorized).

A print would be fine where there not the issue of testing the horizontal reduction cost and you would still need a driver to print costs of all instructions in a basic block.

How did you port the alias analysis evaluator it does the same thing: it is an analysis that tests alias analysis.

In my opinion either of the two could be a pass instead of an analysis.

From: "Chandler Carruth" <chandlerc@gmail.com>
To: "LLVM Developers Mailing List" <llvmdev@cs.uiuc.edu>, "Nadav Rotem" <nrotem@apple.com>, "Arnold Schwaighofer"
<aschwaighofer@apple.com>, "Hal Finkel" <hfinkel@anl.gov>
Sent: Sunday, February 1, 2015 3:24:17 AM
Subject: CostModel analysis -- what is its actual purpose?

Greetings,

So the CostModel 'analysis' today isn't actually an analysis at all.
It is one of the only analyses which doesn't even have an interface
available outside of the .cpp file, so it is literally impossible to
use it today.

The only use is to form tests of TargetTransformInfo, but if that's
really the only intent, then I have two somewhat large questions:

1) Why isn't this just the implementation of the print method for
TTI? Should I make it into that?

Is there some way to force an analysis to run and print itself via the new PM infrastructure such that we don't need 'printing passes' for testing?

2) Why is there so much logic in it? This doesn't really seem like
it's *just* testing TTI, it almost seems its duplicating some logic
in the vectorizers to ensure that logic behaves correctly.... But if
so, that logic should really be de-duplicated into an actual
analysis with an API that is used by the vectorizers...

The current difference is that the CostModel analysis always gets the cost of the current instruction. The vectorizers deal with scalar instructions, and wants the scalar cost, but also the cost of potentially-created corresponding vector instructions. While there is obvious overlap for the current instruction case, for costing potentially-created instructions, I'm not sure the logic would be universal.

-Hal