Skip to content

[AArch64][LV] Reduce cost of scaled reduction extends #134074

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

[AArch64][LV] Reduce cost of scaled reduction extends #134074

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f06fe0b
[AArch64][LV] Reduce cost of scaled reduction extends
huntergr-arm Apr 1, 2025
9ae0c34
Walk vplan instead of storing set of extends
huntergr-arm Apr 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8770,8 +8770,11 @@ void VPRecipeBuilder::collectScaledReductions(VFRange &Range) {
for (auto Pair : PartialReductionChains) {
PartialReductionChain Chain = Pair.first;
if (ExtendIsOnlyUsedByPartialReductions(Chain.ExtendA) &&
ExtendIsOnlyUsedByPartialReductions(Chain.ExtendB))
ExtendIsOnlyUsedByPartialReductions(Chain.ExtendB)) {
ScaledReductionMap.insert(std::make_pair(Chain.Reduction, Pair.second));
Plan.addScaledReductionExtension(Chain.ExtendA);
Plan.addScaledReductionExtension(Chain.ExtendB);
}
}
}

Expand Down
16 changes: 16 additions & 0 deletions llvm/lib/Transforms/Vectorize/VPlan.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3469,6 +3469,11 @@ class VPlan {
/// VPlan is destroyed.
SmallVector<VPBlockBase *> CreatedBlocks;

/// Sign/Zero extend instructions used for scaled reductions. We can use
/// this to better model costs, since the extension operations will happen
/// as part of a combined instruction on the target.
SmallPtrSet<const Instruction *, 8> ScaledReductionExtends;

/// Construct a VPlan with \p Entry to the plan and with \p ScalarHeader
/// wrapping the original header of the scalar loop.
VPlan(VPBasicBlock *Entry, VPIRBasicBlock *ScalarHeader)
Expand Down Expand Up @@ -3747,6 +3752,17 @@ class VPlan {
/// successors of the block in VPlan. The returned block is owned by the VPlan
/// and deleted once the VPlan is destroyed.
VPIRBasicBlock *createVPIRBasicBlock(BasicBlock *IRBB);

/// Add an extension to the list of operations covered by a scaled reduction
/// so it can be checked when cost modelling.
void addScaledReductionExtension(const Instruction *Extend) {
ScaledReductionExtends.insert(Extend);
}

/// Check whether a given extension is part of a scaled reduction.
bool isScaledReductionExtension(const Instruction *Extend) const {
return ScaledReductionExtends.contains(Extend);
}
};

#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
Expand Down
5 changes: 5 additions & 0 deletions llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1796,6 +1796,11 @@ InstructionCost VPWidenCastRecipe::computeCost(ElementCount VF,
// For Z/Sext, get the context from the operand.
else if (Opcode == Instruction::ZExt || Opcode == Instruction::SExt ||
Opcode == Instruction::FPExt) {
// If the extend is performed as part of another operation, it can be
// considered 'free'.
const VPlan *Plan = getParent()->getPlan();
if (Plan->isScaledReductionExtension(getUnderlyingInstr()))
return TargetTransformInfo::TCC_Free;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible for the sext/zext to have multiple uses, i.e. one for the partial reduction and one used for something else? If so, then it won't be free. We might need to check that all uses are for partial reductions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, can't you just look at uses of this recipe and if all uses are for the VPPartialReductionRecipe then mark as free? I just wonder if this avoids having to keep a pointer set.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already do that, in VPRecipeBuilder::collectScaledReductions

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, then I think it would be good to have an assertion here at least, just in case that changes in future.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For our initial motivating use case (the AArch64 dot product instructions), there would be an extra recipe (a multiply) between the extends and the partial reduction. So we would need to look for uses of uses. I'm not sure if anyone has a case for more than one operation between the extends and the reduction, but I decided to keep it simple for now instead of walking the vplan.

If it's preferable to do the walk, then sure, I can convert it.

(I guess we could also make the multiply free, but so far that hasn't been an issue in using wider VFs)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Walking the plan would be needed for an assert anyway.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only free iff the target has an instruction that implements the partial reduction in a way that it folds in the extend. I think this warrants another CastContextHint enum value for the case where the extend is used in a partial reduction context. Then the TTI.getCastInstrCost can determine whether this is folded into the operation, and is therefore TCC_Free.

This does mean widening the meaning of CastContextHint beyond loads, but I can't see any fundamental reason why that hint should only be limited to loads.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a bit of a conflict there, though – the current code looks up the operand and calculates a CCH based on that, whereas this focuses on users. This would override the existing CCH... I guess we could do that if the current CCH is Normal or None, otherwise leave it as is?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the documentation for CastContextHint says:

/// Represents a hint about the context in which a cast is used.
///
/// For zext/sext, the context of the cast is the operand, which must be a
/// load of some kind. For trunc, the context is of the cast is the single
/// user of the instruction, which must be a store of some kind.

The first sentence suggests adding a new hint would make sense for this case, and the second part suggests that the interpretation is currently specific to loads/stores. For partial reductions, we'd indeed look at the single use.

This would override the existing CCH

If I read the code correctly for the zext/sext case it can only be set to TTI::CastContextHint::None at the point where you want to define it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Immediately below my change is the code to look up the CCH based on the operand. I was imagining overriding the CCH after that code and letting the existing getCastInstrCost call below make use of the info. I think it'd be more appropriate that way – a normal load of <vscale x 16 x i8> can be used directly by an sdot instruction, whereas the result of a gather for the same type couldn't be.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't sound like a job for CCH, as it cannot handle the mul. In the long run I would expect this to work like #113903, where there is one vplan recipe that gets the entire cost of the extending reduction added to it. And we happily leave the legacy cost model behind us.

The mul should also be free, as in

llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp

Line 6655 in de6c909

if (auto RedCost = getReductionPatternCost(I, VF, VectorTy))
. I was hoping that #113903 would be done by now and we could have one solution for the two sets of extending reductions, that should ideally work the same. The mul should also be free though, and the entire cost of the dot should come from getPartialReductionCost.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the extend is free then it should be modeled similar to other special reductions in #113903 as @davemgreen mentioned.

Recipes should encapsulate all information required to compute their costs. Otherwise we may have to spread logic to detect those free extends to multiple places (e.g. register pressure computation).

This should also make it easier to perform a specific TTI query, instead of encoding some target-dependent knowledge directly in ::computeCost

if (Operand->isLiveIn())
CCH = TTI::CastContextHint::Normal;
else if (Operand->getDefiningRecipe())
Expand Down
Loading