TargetLowering vs. TargetTransform

Hi all,

I’m looking for a place where to put the costs of vector (and scalar) cast operations for ARM, but I noticed the TargetTransform methods call the TargetLowering ones when unsure.

Now, I’m not sure…

Many casts on ARM are free, and I could build a list of cases where it is true, but should I put this on the lowering or the transform? My main motivation is to get the costs right for the vectorization pass, but I think this should be generally available to any pass that needs it.

What are the uses of each and, is there a general rule of thumb for using them?

cheers,
–renato

Hi Renato,

I think that we need to improve ::isTruncateFree, ::isZextFree, etc to include all of the free conversions. Vector and Scalar.

Non-free conversions are marked with setOperationAction so the generic parts of TTI should be able to give a reasonable cost estimation.

The cost tables should contain cases that are not handled by TTI. So, if we have a clever DAGCombine optimization (that TLI can't detect because it is not in the operations table) then we need to add it to the cost table.

Thanks,
Nadav

Hi Nadav,

Yes, and the question is: TargetLowering's isZExtFree or TargetTransform's
isZExtFree?

TargetTransform (TT) only has the free checks on types, while
TargetLowering (TL) has on SDValue and destination type.

For my purposes, I need the operation information, so I was going to
implement on TL, but I can't see where the TT queries that, though BasicTTI
queries isTruncateFree(Type, Type), which is not the one I want to override.

Do you see the confusion?

Some truncates are not free (16-bit results have to move to D* first), so I
could just assume this is the case by type, but I wanted to limit to the
arithmetic operations, not loads and stores, that have their own halving
and doubling that are, sometimes, free.

But since TT already lost the information on the operations (passing only
the type), I can't reach that info. And since ARMTTI is supposed to only
apply the exceptions, I didn't want to override it on that.

Am I making any sense?

cheers,
--renato

TargetTransform (TT) only has the free checks on types, while TargetLowering (TL) has on SDValue and destination type.

Yes. This is a limitation of the current API. The design decision behind it was that in many cases you want to know the cost of IR before you generate it.
For example, during vectorization you want to know how a particular IR would look if you were to vectorize it. Also, we wanted to rely on tables as much as possible. We did not want to write code to resemble ISel in order to estimate the cost. Is this something that we can live with ?

Yes. This is a limitation of the current API. The design decision behind
it was that in many cases you want to know the cost of IR before you
generate it.

That makes sense.

Also, we wanted to rely on tables as much as possible. We did not want to

write code to resemble ISel in order to estimate the cost. Is this
something that we can live with ?

It depends on the final design intentions. If these costs are only ever
going to be used by the vectorization, or if other optimizations are going
to start using TargetTransformInfo for cost information, than yes, it makes
sense to begin focusing cost models on TTI. But if other passes call TL
directly, then we might re-think the strategy.

It looks to me that only lowering would need to call TL's costs, since they
can be different than a more high level cost, and possibly assume that the
code is already valid and checked, which is not the case for most
transformations, including the vectorization. I think this is more or less
what you were saying before.

I'll give it a few tries and send to the list so we can discuss with more
concrete implementations.

cheers,
--renato

It depends on the final design intentions. If these costs are only ever going to be used by the vectorization, or if other optimizations are going to start using TargetTransformInfo for cost information, than yes, it makes sense to begin focusing cost models on TTI. But if other passes call TL directly, then we might re-think the strategy.

IR passes should only use TTI. This deserves a separate thread, but the idea is that ‘lowering IR passes’ such as the Vectorizers, LSR and CodegenPrepare will use TTI. Canonicalization transformations such as InstCombine and SimplifyCFG will not use TTI. Some canonicalization passes such as the Inliner may use a very small subset of TTI (the inliner can estimate the size of instructions, but this is still a canonicalization). A few of us are working on a proposal to formalize it.

It looks to me that only lowering would need to call TL’s costs, since they can be different than a more high level cost, and possibly assume that the code is already valid and checked, which is not the case for most transformations, including the vectorization. I think this is more or less what you were saying before.

Yes, TargetLowering is used directly only by the codegen (and TTI).

I’ll give it a few tries and send to the list so we can discuss with more concrete implementations.

Thanks,
Nadav