Skip to content

[AArch64] Update getCmpSelInstrCost #145568

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.

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

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

davemgreen
Copy link
Collaborator

@davemgreen davemgreen commented Jun 24, 2025

This currently

  • The AArch64TTIImpl::getCmpSelInstrCost function now tried to handle all cost kinds, not just TCK_RecipThroughput.
  • Updates fcmp costs to correctly model the cost of fcmp's predicates that require expansion into multiple instructions.
  • Adds a target feature for when SVE fcmxx instructions have a lower throughput than the Neon versions.
  • Some of the old select code that assumed they would not be well lowered were removed.

This comment was marked as off-topic.

davemgreen added a commit to davemgreen/llvm-project that referenced this pull request Jun 27, 2025
This removes the CostKind == TCK_RecipThroughput limitation from
getCmpSelInstrCost, allowing it to return more accurate costs for CodeSize and
Lat / SizeLat. Especially for larger vectors under CodeSize, the returned costs
are currently 1, not the legalization cost.

There are further ideas for improvement in llvm#145568, this is the first step.
davemgreen added a commit to davemgreen/llvm-project that referenced this pull request Jul 8, 2025
This removes the CostKind == TCK_RecipThroughput limitation from
getCmpSelInstrCost, allowing it to return more accurate costs for CodeSize and
Lat / SizeLat. Especially for larger vectors under CodeSize, the returned costs
are currently 1, not the legalization cost.

There are further ideas for improvement in llvm#145568, this is the first step.
From the SWOG's for various CPUs, SVE fcmp can have a lower throughput that the
Neon instructions. This adds a cost-model tuning feature to the relevant CPUs
and increase the costs in those cases.  This should lead to fixed-width being
slightly more prefered on those CPUs.

In the long run this information would ideally come straight from the
scheduling model, but that is currently unproven and my experiments with it
have ran into issues that are not yet addressed.
@davemgreen davemgreen force-pushed the gh-a64-getCmpSelInstrCost branch from 3daea67 to be43c70 Compare August 12, 2025 09:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant