Page MenuHomePhabricator

[NFC] Make remaining cost functions in LoopVectorize.cpp use InstructionCost
ClosedPublic

Authored by david-arm on Jan 5 2021, 12:21 AM.

Details

Summary

A previous patch has already changed getInstructionCost to return
an InstructionCost type. This patch changes the other various
getXXXCost functions to return an InstructionCost too. This is a
non-functional change - I've added a few asserts that the costs
are valid in places where we're selecting between vector call
and intrinsic costs. However, since we don't yet return invalid
costs from any of the TTI implementations these asserts should
not fire.

See this patch for the introduction of the type: https://reviews.llvm.org/D91174
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2020-November/146408.html

Diff Detail

Event Timeline

david-arm created this revision.Jan 5 2021, 12:21 AM
david-arm requested review of this revision.Jan 5 2021, 12:21 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 5 2021, 12:21 AM

Thank you David for this patch.
It looks all fine and the patch LGTM.
I have a question, maybe out of the scope of this patch.
Can we also change LoopVectorizationCostModel::computePredInstDiscount to return InstructionCost as well?

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
4887

Is it necessary to set IntrinsicCost here?

xbolva00 added inline comments.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
6715

Missed?

6868

Missed?

ctetreau added inline comments.Jan 5 2021, 9:38 AM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
7323

I mentioned it in another patch, but I'm wondering if InstructionCost::min is a neccesary function. I think std::min will work.

Should we get rid of InstructionCost::min and InstructionCost::max?

Hi @CarolineConcatto, I wasn't sure whether I needed to change computePredInstDiscount because I've assumed (possibly wrongly!) that we shouldn't be encountering invalid discounts (costs). At the end of computePredInstDiscount it calls *Discount.getValue(), which will assert if the cost is invalid so there is some protection. When we add scalable vector support I doubt we can even call this function in it's current form because we know the scalarisation overhead will always be invalid.

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
4887

Possibly? I think you're right that if UseVectorIntrinsic is true then IntrinsicCost must be well-defined. Just not sure if the compiler will warn about unitialized values.

david-arm updated this revision to Diff 314908.Jan 6 2021, 8:23 AM
david-arm marked 4 inline comments as done.
david-arm added inline comments.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
7323

Hi @ctetreau, I'll create a separate patch to remove the min/max functions, thanks!

sdesmalen added inline comments.Jan 8 2021, 8:53 AM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
4888–4889

nit:

InstructionCost IntrinsicCost = ID ? Cost->getVectorIntrinsicCost(CI, VF) : 0;
4891–4892

If you initialise IntrinsicCost with 0, then you can do with a simpler condition: IntrinsicCost.isValid() && CallCost.isValid()

8239–8241

nit:

InstructionCost IntrinsicCost = ID ? CM.getVectorIntrinsicCost(CI, VF) : 0;
8243

If you initialise IntrinsicCost with 0, then you can do with a simpler condition: IntrinsicCost.isValid() && CallCost.isValid()

david-arm updated this revision to Diff 315731.Jan 11 2021, 1:55 AM
david-arm marked an inline comment as done.
david-arm marked 4 inline comments as done.
ctetreau added inline comments.Jan 11 2021, 9:44 AM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
3752

This assert should be removed. This function returns InstructionCost. Anybody who gets an InstructionCost has to be prepared to handle the invalid case.

7321

This assert should be removed. This function returns InstructionCost, so any caller already has to handle the invalid case.

david-arm updated this revision to Diff 316022.Jan 12 2021, 1:35 AM
david-arm marked 2 inline comments as done.
ctetreau added inline comments.Jan 12 2021, 3:39 PM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
6950

I assume that this assert is being added to ensure that this patch is NFC. I don't believe that this is necessary. Everywhere that currently returns invalid used to assert prior to this effort. So, if we just let the invalids flow through the system, and unconditionally dereference them, we will still get an assert when the resulting value is evaluated. Prior to this change, if this function was called, and an invalid cost would have been created, an assertion failure would result. After this change, this will still be the case because the callsites are not being updated in this patch.

Therefore, I submit that we only get functional changes when we introduce logic to handle invalid costs. Any code that accumulates costs or compares costs does not represent a functional change.

david-arm updated this revision to Diff 316370.Jan 13 2021, 5:13 AM
david-arm marked an inline comment as done.
This revision is now accepted and ready to land.Jan 18 2021, 3:09 AM