Skip to content

aarch64: support udiv for 32bit integers#9798

Merged
cfallin merged 9 commits into
bytecodealliance:mainfrom
MarinPostma:i32-div-aarch64
Dec 17, 2024
Merged

aarch64: support udiv for 32bit integers#9798
cfallin merged 9 commits into
bytecodealliance:mainfrom
MarinPostma:i32-div-aarch64

Conversation

@MarinPostma
Copy link
Copy Markdown
Contributor

@MarinPostma MarinPostma commented Dec 12, 2024

This PR takes first steps towards completing #9766, by implementing support for 32bit unsigned division in cranelift and winch.
we had to take the following steps to enable that:

  • extend the ISLE lowering rules in cranelift to properly handle 32bits udiv, by have a rule that matches 64bit division, and another for anything else that fits 32bit. The 32 bits basically is the old 64bits rule but for 32bits.
  • stop extending registers to 64bits in the ISLE rules.
  • patch the emit code to emit the correct instruction for 32bits division.
  • in winch: stop emitting extend operations for urem and udiv.
  • Make trap_if size aware: this avoids having to perform extensions before cbz, shaving more instructions. This is reflected in the lowering rules for checking division by zero for udiv.

@MarinPostma MarinPostma requested review from a team as code owners December 12, 2024 01:23
@MarinPostma MarinPostma requested review from alexcrichton and cfallin and removed request for a team December 12, 2024 01:23
@MarinPostma MarinPostma marked this pull request as draft December 12, 2024 01:24
@github-actions github-actions Bot added cranelift Issues related to the Cranelift code generator cranelift:area:aarch64 Issues related to AArch64 backend. winch Winch issues or pull requests labels Dec 12, 2024
@github-actions
Copy link
Copy Markdown

Subscribe to Label Action

cc @saulecabrera

Details This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "winch"

Thus the following users have been cc'd because of the following labels:

  • saulecabrera: winch

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

;; *execute* the embedded `Inst`. (In the emitted code, we use the inverse
;; of this condition in a branch that skips the trap instruction.)
(TrapIf
(size OperandSize)
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I think we mostly had two choices here:

  • either make the size part of the CondBrKind, which is tighter, but yields more changes in the code
  • or setting the size in the op itself (current approach), which required less changes

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think I might prefer the first option actually -- I was a bit confused at first how the OperandSize would affect the TrapIf if we're just talking about conditional branch kinds like b.lo, b.hi, etc; until I realized that CondBrKind::Zero(reg) and NonZero(reg) exist and encode cbz/cbnz. If you don't mind, do you think you could try the refactor out? On the upside, it seems like it should get rid of a bunch of extraneous OperandSizes on branches emitted in various places that are condcode-based (e.g. in abi.rs above and in many of the emit-tests below).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Also, separately, if we modify CondBrKind, this is toward the direction that we want for supporting 32-bit zero/nonzero tests in regular conditional branches too. We don't have to implement that now (you can unimplemented!() it in the CondBr case; but if you wanted to, it would certainly be fine with me) but it's nice to lay the groundwork.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This make sense to me, I'll refactor

@MarinPostma MarinPostma marked this pull request as ready for review December 12, 2024 15:25
@github-actions github-actions Bot added the cranelift:area:machinst Issues related to instruction selection and the new MachInst backend. label Dec 12, 2024
Copy link
Copy Markdown
Member

@cfallin cfallin left a comment

Choose a reason for hiding this comment

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

Thanks! One thought below on the way that TrapIf is extended, but generally I like how this is turning out.

;; *execute* the embedded `Inst`. (In the emitted code, we use the inverse
;; of this condition in a branch that skips the trap instruction.)
(TrapIf
(size OperandSize)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think I might prefer the first option actually -- I was a bit confused at first how the OperandSize would affect the TrapIf if we're just talking about conditional branch kinds like b.lo, b.hi, etc; until I realized that CondBrKind::Zero(reg) and NonZero(reg) exist and encode cbz/cbnz. If you don't mind, do you think you could try the refactor out? On the upside, it seems like it should get rid of a bunch of extraneous OperandSizes on branches emitted in various places that are condcode-based (e.g. in abi.rs above and in many of the emit-tests below).

fn show_reg_sized(reg: Reg, size: OperandSize) -> String {
match reg.class() {
RegClass::Int => show_ireg_sized(reg, size),
RegClass::Float => todo!(),
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

todo!() here -- can we just show the reg (and below for vector too) with show_reg for now?

;; *execute* the embedded `Inst`. (In the emitted code, we use the inverse
;; of this condition in a branch that skips the trap instruction.)
(TrapIf
(size OperandSize)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Also, separately, if we modify CondBrKind, this is toward the direction that we want for supporting 32-bit zero/nonzero tests in regular conditional branches too. We don't have to implement that now (you can unimplemented!() it in the CondBr case; but if you wanted to, it would certainly be fine with me) but it's nice to lay the groundwork.

@MarinPostma
Copy link
Copy Markdown
Contributor Author

Thanks @cfallin, will do the refactor 👍

@github-actions github-actions Bot added the isle Related to the ISLE domain-specific language label Dec 15, 2024
@github-actions
Copy link
Copy Markdown

Subscribe to Label Action

cc @cfallin, @fitzgen

Details This issue or pull request has been labeled: "cranelift:area:machinst", "isle"

Thus the following users have been cc'd because of the following labels:

  • cfallin: isle
  • fitzgen: isle

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

@MarinPostma MarinPostma requested a review from cfallin December 17, 2024 17:04
Copy link
Copy Markdown
Member

@cfallin cfallin left a comment

Choose a reason for hiding this comment

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

Looks great; thanks a bunch!

@cfallin cfallin added this pull request to the merge queue Dec 17, 2024
Merged via the queue into bytecodealliance:main with commit 031a28a Dec 17, 2024
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:area:machinst Issues related to instruction selection and the new MachInst backend. cranelift Issues related to the Cranelift code generator isle Related to the ISLE domain-specific language winch Winch issues or pull requests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants