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

[CHERI-RISC-V] Allow load/store mnemonics without the c prefix #749

Conversation

arichardson
Copy link
Member

Instead, make it depend on the type of the operand. This does not yet include all instructions, but the initial set of loads/atomics has been converted (the ones that should be part of the standard version of CHERI-RISC-V).

We were not checking capability mode loads/stores, only
compressed ones and atomics.
@arichardson arichardson marked this pull request as draft August 26, 2024 07:16
}

multiclass CLR_r_aq_rl<bits<3> funct3, string opcodestr,
string Namespace = "CapModeOnly_"> {
Copy link
Member Author

Choose a reason for hiding this comment

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

Passing the DecoderNamespace is a bit ugly, but I couldn't figure out how to work around InstAlias not having such a field.

@arichardson arichardson force-pushed the operand-dependent-loads branch from 7da5124 to e6a7ccc Compare August 27, 2024 06:46
@arichardson arichardson requested a review from jrtc27 August 27, 2024 06:47
@arichardson arichardson marked this pull request as ready for review August 27, 2024 06:47
@arichardson
Copy link
Member Author

CI is failing because one of the RISC-V tests now gets a different error message - will fix this if the approach is considered ok.

Instead, make it depend on the type of the operand. This commit only
touches the basic load/store instruction without the assembler aliases
or compressed instructions.
As a follow-up to the last commit this includes the aliases without an
immediate offset.
This adds support for compressed instructions. Does not yet include Zcb
or floating-point loads/stores.
This adds the floating point loads and stores and should conclude this
series of patches.
@arichardson arichardson force-pushed the operand-dependent-loads branch from e6a7ccc to ef56748 Compare September 4, 2024 18:49
@@ -22,7 +22,7 @@ la x1, %hi(foo) # CHECK: :[[@LINE]]:8: error: operand must be a bare symbol name
la x1, %lo(foo) # CHECK: :[[@LINE]]:8: error: operand must be a bare symbol name

sw a2, %hi(a_symbol), a3 # CHECK: :[[@LINE]]:8: error: operand must be a symbol with %lo/%pcrel_lo/%tprel_lo modifier or an integer in the range [-2048, 2047]
sw a2, %lo(a_symbol), a3 # CHECK: :[[@LINE]]:23: error: invalid operand for instruction
sw a2, %lo(a_symbol), a3 # CHECK: :[[@LINE]]:23: error: operand must be a bare symbol name
Copy link
Member

Choose a reason for hiding this comment

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

Hm, this is a bit weird, though so is upstream's diagnostics?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah I don't quite understand why patch 1 changes the resulting error, but since neither of them are particularly helpful I don't think it matters.

Copy link
Member

@jrtc27 jrtc27 left a comment

Choose a reason for hiding this comment

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

The approach generally makes sense to me, though I don't love the strip-all-leading-c's approach in the tests... not that I have a better suggestion

@arichardson
Copy link
Member Author

The approach generally makes sense to me, though I don't love the strip-all-leading-c's approach in the tests... not that I have a better suggestion

I agree this is rather gross and could be fragile but duplicating all the lines seems even more ugly. I did the duplication approach for tests with only a handful of checks but for the larger ones the sed approach just seemed simpler.

@arichardson arichardson merged commit 35604c0 into CTSRD-CHERI:upstream-llvm-merge Sep 11, 2024
5 checks passed
@arichardson arichardson deleted the operand-dependent-loads branch September 11, 2024 22:05
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.

2 participants