This is an archive of the discontinued LLVM Phabricator instance.

[AArch64][TTI][NFC] Overload method 'getVectorInstrCost' to provide vector instruction itself, as a context information for cost estimation.
ClosedPublic

Authored by mingmingl on Aug 3 2022, 2:26 PM.

Details

Summary
  1. Overloaded (instruction-based) method is a wrapper around the current (opcode-based) method.
  2. This patch also changes a few callsites (VectorCombine.cpp, SLPVectorizer.cpp, CodeGenPrepare.cpp) to call the overloaded method.
  3. This is a split of D128302.

Diff Detail

Event Timeline

mingmingl created this revision.Aug 3 2022, 2:26 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 3 2022, 2:26 PM
mingmingl requested review of this revision.Aug 3 2022, 2:26 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 3 2022, 2:26 PM
mingmingl updated this revision to Diff 449791.Aug 3 2022, 2:41 PM

undo the AArch64 custom overload

davidxl added inline comments.Aug 3 2022, 3:03 PM
llvm/include/llvm/Analysis/TargetTransformInfo.h
1181

Is the Type *val always from instruction? If yes, this parameter can be removed. Alternatively add an assert in the implementation that I->getType() == Val. The latter may be better as Type is readily available at callsite.

llvm/test/Analysis/CostModel/AArch64/kryo.ll
36 ↗(On Diff #449791)

This test change belong to the follow up patch.

mingmingl updated this revision to Diff 450071.Aug 4 2022, 11:03 AM
mingmingl marked an inline comment as done.
mingmingl edited the summary of this revision. (Show Details)

Resolve comments.

llvm/include/llvm/Analysis/TargetTransformInfo.h
1181

Type* val (representing vector type) could be retrieved from Instruction* I but not necessarily I->getType() (scalar for extract-element, and vector for insert-element)

For example, AArch64 TTI requires that Type* val is always vector type (code of asserts), while I->getType() for extract-element is the element type (code of EEI constructor)

For insert-element it should be true, since it's intentional that "there is only one instance of a particular type so that type comparison becomes pointer comparison" (class description of type)

davidxl accepted this revision.Aug 4 2022, 11:32 AM

lgtm

This revision is now accepted and ready to land.Aug 4 2022, 11:32 AM
This revision was landed with ongoing or failed builds.Aug 4 2022, 12:58 PM
This revision was automatically updated to reflect the committed changes.