llvm dev - Jan 2013 - [LLVMdev] TargetLowering vs. TargetTransform

On 25 January 2013 17:48, Nadav Rotem <nrotem at apple.com> wrote:
> I think that we need to improve ::isTruncateFree, ::isZextFree, etc to
> include all of the free conversions. Vector and Scalar.
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130125/363135e2/attachment.html>

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

On 25 January 2013 23:03, Nadav Rotem <nrotem at apple.com> wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130126/db160fb4/attachment.html>