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>
Maybe Matching Threads
- [LLVMdev] TargetLowering vs. TargetTransform
- [LLVMdev] TargetLowering vs. TargetTransform
- [LLVMdev] TargetLowering vs. TargetTransform
- [LLVMdev] TargetLowering vs. TargetTransform
- [LLVMdev] [llvm-commits] [patch] "TargetTransform" as an API between codegen and IR-level passes