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.
Thanks,
-Andy
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>
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>