[LLVMdev] InstMetrics would look a lot like NoTTI

[Chandler Carruth]

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
important.

On Wed, Jan 30, 2013 at 11:07 AM, Andrew Trick <atrick at apple.com> wrote:

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130130/e84e3ac7/attachment.html>