Skip to content

aarch64: skip the extend of a scalar comparison's result - #14082

Open
fitzgen wants to merge 2 commits into
bytecodealliance:mainfrom
fitzgen:remove-extends-of-comparisons-in-aarch64-lowering
Open

aarch64: skip the extend of a scalar comparison's result#14082
fitzgen wants to merge 2 commits into
bytecodealliance:mainfrom
fitzgen:remove-extends-of-comparisons-in-aarch64-lowering

Conversation

@fitzgen

@fitzgen fitzgen commented Aug 5, 2026

Copy link
Copy Markdown
Member

icmp and fcmp on scalars both lower through lower_cond_result_bool, whose every arm already clears upper bits, so extending it is a no-op.

This removes ~18,000 uxtb instructions emitted from a PCA-based subset of Sightglass (this is ~87% of uxtb instructions emitted and 0.220% of all instructions emitted). It also results in an average 0.42% faster execution (significant) in terms of cycles.

`icmp` and `fcmp` on scalars both lower through `lower_cond_result_bool`,
whose every arm already clears upper bits, so extending it is a no-op.

This removes ~18,000 `uxtb` instructions emitted from a PCA-based subset of
Sightglass (this is ~87% of `uxtb` instructions emitted and 0.220% of *all*
instructions emitted). It also results in an average 0.42% faster
execution (significant) in terms of cycles.
@fitzgen
fitzgen requested a review from a team as a code owner August 5, 2026 19:29
@fitzgen
fitzgen requested review from alexcrichton and removed request for a team August 5, 2026 19:29
@github-actions github-actions Bot added cranelift Issues related to the Cranelift code generator cranelift:area:aarch64 Issues related to AArch64 backend. labels Aug 5, 2026
@alexcrichton

Copy link
Copy Markdown
Member

We've generally tried to avoid lowering rules like this historically where correctness relies on other lowering rules in the system, although we also have some already for x64 so it's not the most principled stance per se. I'd be surprised though if this uextend+icmp showed up too too often in terms of materializing the result of a comparison vs feeding the uextend+icmp into a branch/select/trap/etc. Is this perhaps something where we could get the lion's share of the benefit by shifting around these rules to where conditions are lowered or similar?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cranelift:area:aarch64 Issues related to AArch64 backend. cranelift Issues related to the Cranelift code generator

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants