InstMetrics would look a lot like NoTTI

I want to expose most of the logic in NoTTI to passes that do not depend on TTI for the purpose of pure IR-level instruction metrics. For example, we don't want the presence of certain "free" intrinsics to affect the patterns handled by canonical transforms. It would still be ok to use DataLayout here, so certain casts are considered free. The idea of "free" here has little to do with the cost to execute the operation and more to do with the fact that we don't want them to be barriers to optimization. The interface would also provide useful queries like isDuplicatable and isLoweredToCall.

Why do I care? This is holding up my work to improve LoopRotate, because I want to design heuristics independent of TTI. But more generally we want to better sandbox TTI (more on that in some later thread).

I'm hoping for quick feedback on the implementation of the next small step in this direction...

I could cleverly control the order of TTI passes so that -basictti doesn't run until after the non-TTI passes. But clever is bad. There should be a less subtle/confusing way.

I like the implementation currently in NoTTI and want to avoid scattering code. There are two easy possibilities:

1) I could create a NoTTI pass wrapper so that NoTTI can be used as a utility in addition to part of the analysis group:

struct NoTTIBase : TargetTransformInfo {
... all the TTI hooks ...

struct NoTTI : ImmutablePass, NoTTIBase {
  ... pass interface ...

Create a new Analysis/InstMetrics.(h|cpp) to expose only the queries that No-TTI passes are allowed to use. Instatiate a NoTTI instance on-the-fly

2) I could move the Target-Independent "cost" metrics into InstMetrics.cpp and use that interface within NoTTI.



FWIW, this all makes perfect sense from a philosophical point of view.

If anything, I think it is absolutely critical to differentiate the very
interface this exposes from the TTI interfaces. The latter should be cost
functions, that are as accurate as we can make them while remaining largely
"conservative" (IE, don't assume any clever brilliance is the chip or
backend; what is the impact of this in both the time and space dimensions?
And with a distinct emphasis on the space dimension).

What you're describing is something with a very different motivation and
design constraints. Separating it thoroughly API-wise is going to be

2) I could move the Target-Independent "cost" metrics into InstMetrics.cpp
and use that interface within NoTTI.

I think this is a much better approach. It is minimally clever. It is
obvious how things work.

It also allows NoTTI to *selectively* use the pieces of your logic when it
makes sense as a baseline approximation of TTI's interface. It may not
always make sense. A potentially interesting example: complex constant
expressions in GEPs may have very real cost, and we may want to model this
even in NoTTI, but we likely don't want to avoid canonicalizing toward a
single all-constant GEP.

Some thoughts on the specific design of this new thing:

I would make it another immutable analysis pass. I think that's the
simplest way to express the dependencies between it and other passes, and
to ensure that it gets the correct DataLayout and other information.

I think 'metrics' is a bad term to use in the API / pass. If it's about
cost or metrics, than TTI makes too much sense. I would really like to get
the fundamental idea of canonicalization into the API so that we correctly
skew the design in that direction. Does "CanonicalizationModel" work? Is
there some other way to phrase the types of queries that will make this
more clear?

I think phrasing this in terms of "target independent" is a bit of a trap
-- if it looks at the data layout, it's not going to be independent... But
I think I know what you're aiming for, and completely agree with the goals,
I'm just searching for better words that will lead to less confusion when
we discuss this in 2 years or with others. =]

Anyways, cool stuff, looking forward to even better design of these APIs.

Great. I totally agree with all that. I’ll try to think of a better name and prepare a patch. The InstMetrics name is just mimicking the current CodeMetrics. Not sure what to call it yet.