Added TTI queries for the cost of a VP Memory operation, and added DataType and Alignment to the hasActiveVectorLength() interface.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/include/llvm/Analysis/TargetTransformInfo.h | ||
---|---|---|
1125 | I prefer the downstream name getVariableLengthMemoryOpCost. I'm not sure |
llvm/include/llvm/Analysis/TargetTransformInfo.h | ||
---|---|---|
1125 | VP stands for Vector Predication and is the name that the community has used for all the predicated intrinsics. See https://llvm.org/docs/LangRef.html#vector-predication-intrinsics |
Yes, I realize. Are you intending to go ahead with that patch? It has been sitting for a while. I would imagine that is useful info for other reviewers.
llvm/include/llvm/Analysis/TargetTransformInfo.h | ||
---|---|---|
1125 | Well, I followed your link. There are no "vp" memory ops. The loads and stores are named "masked" operations. |
llvm/include/llvm/Analysis/TargetTransformInfo.h | ||
---|---|---|
1125 | The target implementation you propose depends on having an Instruction parameter passed in. If you pass in an Instruction you could actually figure out from the dynamic cast that this is a vp intrinsic. The existing getMemoryOpCost allows passing in an Instruction, so it seems like you could figure this out without a new interface. |
llvm/include/llvm/Analysis/TargetTransformInfo.h | ||
---|---|---|
1125 | The LLVM LangRef wording for vp.load/store/gather/scatter are missing. The intrinsics themselves are upstream though. |
The following patches are related and still in flight and we intend to go ahead with them all. There has been a delay due to Hussain leaving, but we definitely want to resume the work soon and finish it. If you are interested in helping commandeer some of them please let me know.
https://reviews.llvm.org/D109416 - Cost model infrastructure for VPMemory ops
https://reviews.llvm.org/D109417 - Cost model for VPMemory ops
https://reviews.llvm.org/D109584 - Expansion of VP load/store to scalar loads/stores
https://reviews.llvm.org/D109377 - Type legalization for VP memory SelectionDAG nodes
https://reviews.llvm.org/D109379 - PPC lowering for VP memory SD nodes
llvm/include/llvm/Analysis/TargetTransformInfo.h | ||
---|---|---|
1125 | There is precedence for this, for example we have separate interfaces for getMaskedMemoryOpCost and getGatherScatterOpCost, so we try to follow that in this patch. |
llvm/include/llvm/Analysis/TargetTransformInfo.h | ||
---|---|---|
1125 | Now that the instruction pointer is truly optional, having a separate call actually provides value and I like this patch a lot better. |
llvm/include/llvm/Analysis/TargetTransformInfo.h | ||
---|---|---|
1387 | This is really just a getter that tells you whether using VP intrinsics makes sense on this target at all. It shouldn't be modified this way. Couldn't you use the cost function to tell you whether a combination of %evl and type for memory accesses makes sense? | |
llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp | ||
1341 | This patch should only be for TTI. You are using the default impl here anyway - target-specific changes should go in a separate patch. |
llvm/include/llvm/Analysis/TargetTransformInfo.h | ||
---|---|---|
1387 | Whether the target supports EVL in hardware may depend on opcode and data type. For example, Power9/10 only support load and stores. Other targets may have dependency on data type or alignment. For these reasons I think we should pass opcode and datatype/alignment as input to this function. I just realized I had forgotten to add opcode to this interface. I'll do that. Having a function that can tell us whether an opcode/type combination can be efficiently vector predicated (without having to model the cost) is helpful in LoopVectorizer as well. For example when deciding how to vectorize we don't have a VPIntrinsic yet, so we cannot use getVPLegalizationStrategy. Having something similar to isLegalMaskedLoad would be useful, and I was hoping we use hasActiveVectorLength() for that purpose (per previous conversation in D99750#inline-949716). Is there another interface I should we looking at? | |
llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp | ||
1341 | This is just a stub, but I'll move it to D109417 for cleaner separation. |
@simoll I've addressed your comments above, please let me know if you have any further comments. I plan to commit this soon. Thanks!
I prefer the downstream name getVariableLengthMemoryOpCost. I'm not sure
what VP stands for here and it seems like VP is already used in the context of VPlan. At least explain in the comment.