[PATCH] D31186: Changing TargetTransformInfo::getGEPCost to take GetElementPtrInst as parameter

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D31186#706614, @efriedma wrote:

> In some contexts, we might want to compute the cost of a GEP which doesn't actually exist in IR at the moment.  I guess there aren't any callers in the tree like that at the moment, but we use this sort of capability in other contexts, so we want to structure the code to allow it.
>
> Actually, the inliner itself could in theory take advantage of that: if you have a function which returns a GEP, the cost depends on how the caller uses the value.  That might be overkill, though, given the tiny effect in most cases.
>
> Along those lines, it probably makes sense to structure the code more like this:
>
> 1. The core cost function for GEPs should keep its existing signature, and just assume the GEP has users which are not memory operations (so it's not free unless all the indices are zero).
> 2. We should have a utility function which examines the users of the GEP, and checks if the GEP can be folded into them, using isLegalAddressingMode or something like that.


+1

I'll also point out that we're further walking down the path of costing instruction patterns, instead of individual instructions. We should clearly document how we expect this to work. Specifically, we want to have a uniform scheme that we can use without overcounting. We can't for example, have some logic look at an instruction along with its operands and another loop at an instruction along with its users. I think that the approach described, where we look at the users, seems potentially the easiest to make consistent, but regardless, we should make a decision.


https://reviews.llvm.org/D31186