[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#707662, @eastig wrote:

>


...

> Hal, you wrote:
> 
>> I'll also point out that we're further walking down the path of costing instruction patterns
> 
> What do you mean "instruction patterns"?

I mean taking into account folding decisions that will be made by the backend. For example, it might be the case that, for some data type, add(zext(x), zext(x)), will be given a cost of 3 because each zext costs 1 and the add costs 1. These costs are accurate in isolation, however, the target can actually lower this into a single instruction, so the overall cost should be 1 for all three operations. I think that the proposed approach, where we pass each instruction so we can look at the users, probably makes the most sense. We need to be careful, however, that we don't overcount.

> Maybe it's time to redesign API?

This may be true. Also, I think that the VPlan work being done (https://reviews.llvm.org/D28975) may be highly relevant to how we do this (we might just want to let the backends cost VPlans directly in cases where the fine-grained modeling won't work).


https://reviews.llvm.org/D31186