Skip to content
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

[WIP] dialects (arm): add cf instructions #3744

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Conversation

emmau678
Copy link
Contributor

@emmau678 emmau678 commented Jan 13, 2025

Add control flow instructions for ARM (same as those already implemented for riscv).
Please note: Not ready for review, this is a WIP branch. I will break this up into smaller PRs and eventually delete this one

@emmau678 emmau678 added the dialects Changes on the dialects label Jan 13, 2025
@emmau678 emmau678 requested a review from superlopuh January 13, 2025 10:12
@emmau678 emmau678 self-assigned this Jan 13, 2025

then_block = successor_def()

assembly_format = (
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm aware that this is not correct, but I'm not sure how exactly to fix it. In arm, beq must follow a cmp in the line beforehand. (Related question: Shall I still treat is as one instruction and just include the cmp in the printing, or implement cmp separately?)

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think I'd add the cmp separately and have a verification check here in beq the enforces this constraint (i.e., the cmp must be the instruction prior to this), similarly to some of the verify_ methods in the RISC-V dialect.
We don't have many there and the constraints are a bit more involved, but you should get an idea.

Let me know if you have more questions on this.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not 100% sure, if the constraint is so hard-coded, then maybe we could get away with a single op. Probably worth a discussion.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Well, it depends on the CPSR AFAIU, and I'm not sure how to model that fully, e.g., when these are cleared, as the specification phrases this as "set by the last flag-setting instruction... etc.". For example, the cmp instruction sets the Z flag.

Copy link
Collaborator

@compor compor left a comment

Choose a reason for hiding this comment

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

Overall looks good, I left some comments. I expect the Label op and attribute PRs to go in first, which would simplify this one.

Maybe also rename the PR title to be the specific control flow instruction that you intend to add here?


then_block = successor_def()

assembly_format = (
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think I'd add the cmp separately and have a verification check here in beq the enforces this constraint (i.e., the cmp must be the instruction prior to this), similarly to some of the verify_ methods in the RISC-V dialect.
We don't have many there and the constraints are a bit more involved, but you should get an idea.

Let me know if you have more questions on this.

@emmau678
Copy link
Contributor Author

Overall looks good, I left some comments. I expect the Label op and attribute PRs to go in first, which would simplify this one.

Maybe also rename the PR title to be the specific control flow instruction that you intend to add here?

thanks for the review @compor. This was my initial attempt at adding support for CF but I felt it was getting a bit too long for a single PR, so I pushed it as a WIP branch so I could get some feedback. I'm planning to break it up into a couple of smaller PRs, so I'll probably end up cutting this down/deleting it afterwards

@compor
Copy link
Collaborator

compor commented Jan 13, 2025

Overall looks good, I left some comments. I expect the Label op and attribute PRs to go in first, which would simplify this one.
Maybe also rename the PR title to be the specific control flow instruction that you intend to add here?

thanks for the review @compor. This was my initial attempt at adding support for CF but I felt it was getting a bit too long for a single PR, so I pushed it as a WIP branch so I could get some feedback. I'm planning to break it up into a couple of smaller PRs, so I'll probably end up cutting this down/deleting it afterwards

Excellent @emmau678, no objection. Happy to hear and discuss your thoughts on the above discussion on the cmp/CPSR issue.

Copy link
Collaborator

@alexarice alexarice left a comment

Choose a reason for hiding this comment

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

Left some comment but not 100% they are very useful

// RUN: XDSL_GENERIC_ROUNDTRIP
// RUN: xdsl-opt -t arm-asm %s | filecheck %s --check-prefix=CHECK-ASM

module {
Copy link
Collaborator

Choose a reason for hiding this comment

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

It surprises me that this verifies, as ModuleOp is tagged as being single_block

@@ -8,7 +8,7 @@
from xdsl.dialects.builtin import ModuleOp
from xdsl.ir import Dialect

from .ops import ARMOperation, DSMovOp, DSSMulOp, GetRegisterOp
from .ops import ARMOperation, DSMovOp, DSSMulOp, GetRegisterOp, LabelOp
Copy link
Collaborator

Choose a reason for hiding this comment

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

Feels like this could be its own PR

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is actually its own PR now (#3749), and I think all of your other comments are resolved in that one. apologies for the confusion, I will clearly mark WIP PRs from now on

AssemblyInstructionArg: TypeAlias = SSAValue

@irdl_attr_definition
class LabelAttr(Data[str]):
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why not just use a StringAttr here?

label = attr_def(LabelAttr)
comment = opt_attr_def(StringAttr)

assembly_format = "attr-dict"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should this not have label in it somewhere?

"""

name = "arm.label"
label = attr_def(LabelAttr)
Copy link
Collaborator

Choose a reason for hiding this comment

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

any reason this isn't a property?

@emmau678
Copy link
Contributor Author

emmau678 commented Jan 15, 2025

Overall looks good, I left some comments. I expect the Label op and attribute PRs to go in first, which would simplify this one.
Maybe also rename the PR title to be the specific control flow instruction that you intend to add here?

thanks for the review @compor. This was my initial attempt at adding support for CF but I felt it was getting a bit too long for a single PR, so I pushed it as a WIP branch so I could get some feedback. I'm planning to break it up into a couple of smaller PRs, so I'll probably end up cutting this down/deleting it afterwards

@alexarice, thanks for the review also! this was very much a WIP when I pushed it and I have since done a smaller PR as a first step LabelOp. I'm planning to build on this incrementally in further PRs. I have updated the PR description and will do this next time if I push a WIP PR

@superlopuh
Copy link
Member

We tend to use [WIP] in the PR title to mark PRs as such

@emmau678 emmau678 changed the title dialects (arm): add cf instructions [WIP] dialects (arm): add cf instructions Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dialects Changes on the dialects
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants