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

Hal Finkel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 23 07:31:49 PDT 2017


hfinkel added a comment.

In https://reviews.llvm.org/D31186#708714, @jonpa wrote:

> In https://reviews.llvm.org/D31186#708662, @hfinkel wrote:
>
> > In https://reviews.llvm.org/D31186#708507, @jonpa wrote:
> >
> > > >   User stories:
> > > >   
> > > >   An user wants to estimate the cost of an operation to make a decision whether it's worth to create it. The operation does not exist in IR.
> > > >   An user has an operation in IR and wants to know the cost of the operation to estimate its contribution into execution.
> > >
> > > I think there is also the case in a vectorizer, where there is an existing instruction but the cost query is for the same instruction *vectorized* with VF.
> > >
> > > > Jonas, an optional parameter duplicates the information passed through other parameters. It can provide all of the needed information. Also single API for all use cases might create some kind of misunderstanding.
> > >
> > > No, not in the case in the vectorizer. Here the scalar instruction is passed, with vector types.
> >
> >
> > But that is that the vectorizer normally does. It takes the scalar instruction and emits the same instruction with vector types. You need to explain how any other case is different.
>
>
> I meant that it is not quite true that it would be enough to just pass the Instruction without types, as a response to the statement that it just duplicates information. Currently LoopVectorizer passes types as arguments to TTI. Passing the instruction to TTI does not provide the Types, it only gives clues of the original instruction plus the possibility to inspect users / operands.


I agree. We can't only have the current instruction.


https://reviews.llvm.org/D31186





More information about the llvm-commits mailing list