The logic for the cost of cast instructions was handled in getOperationCost and getCastInstrCost just returned 1. Move the cast cost logic into the specific helper function and also use this in getUserCost.
Details
- Reviewers
- None
Diff Detail
Event Timeline
Since most transformations will be using TTI, which should then hold all the required information, just call the base getOperationCost without handling trunc and zext differently.
I don't understand what you mean. You're changing the default TTI implementation that most of the targets will use. Do you only want to call back when isTruncateFree/isZExtFree return false? I'd think that we'd want to continue handling the cases when they return true?
Hi Hal,
Thanks for questions. I have to admit that I've been confused by how TTI is implemented, it seems rather convoluted to me. I've removed my previous change and, instead, I've reorganised some of the logic in TargetTransformInfoImplBase which hopefully makes sense. I can see that implementing isTruncateFree in the ARM backend should also solve my problem and I will look into that next.
Thanks,
sam
It doesn't, likely, but as there's no documentation explicitly explaining this, it's not obvious why. TTI has two cost models right now: First is the "user cost" model, which is used by the inliner, loop unroller, etc. which provides some combination of code size and expense. The second is the model (mainly) used by the vectorizers, and it measures reciprocal throughput. getCastInstrCost is part of the latter model and getUserCost/getOperationCost are part of the former.
That doesn't mean that tying the models together in this way doesn't make sense, it might, but we'd need to be explicit about what we're doing on why. If we don't want to do that here, you should keep the implementations separate.
What problem are you trying to solve?
I can see that implementing isTruncateFree in the ARM backend should also solve my problem and I will look into that next.
Thanks,
sam
Is there any way of telling which API each function is apart of? I was thinking that there was a model driven by TLI and DataLayout and then one specified by a TTI implementation in the backend. Most of the functions end up returning a TargetCostConstant, which I see are the mixed costs you described. Does it make sense to try to bundle all those costs into one enum?
The issue I was having was that my test case wasn't being simplified into a single block because of the estimated cost of the trunc i64. Like I said, I know this is more easily handled by implementing another hook in the backend, but thought it would be better to try something in the mid-end too.
thanks,
sam
Both cost models can be overridden by the targets, although there's been, at the present time, more explicit target customization of the reciprocal throughput model used by the vectorizers. TargetCostConstants are currently used by the user-cost model. There isn't really a mid-end-native model (I'm not sure what that would mean, TLI and DL don't really have cost information aside from DL's idea of the maximum size of legal types). Regarding bundling them, so you mean like this: https://reviews.llvm.org/D37170 (Carrot is working on this)?
The issue I was having was that my test case wasn't being simplified into a single block because of the estimated cost of the trunc i64. Like I said, I know this is more easily handled by implementing another hook in the backend, but thought it would be better to try something in the mid-end too.
So you're trying to affect the user-cost model, and implementing the right backend hook seems like the right approach (either by implementing something like isTruncateFree/isZExtFree, or by directly customizing the model if there's more context dependence needed).
thanks,
sam
Ah, nice, yes separating the different costs sounds great. Ok, I will abandon this and implement the target hook. Thanks for your help.