[LLVMdev] InstMetrics would look a lot like NoTTI

[Andrew Trick]

On Jan 30, 2013, at 2:22 PM, Chandler Carruth <chandlerc at google.com> wrote:

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

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.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130130/e8b0b4bb/attachment.html>