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

Add a "xcheri-std-compat" mode to LLVM #756

Open
wants to merge 19 commits into
base: dev
Choose a base branch
from

Conversation

arichardson
Copy link
Member

This limits the instructions that are emitted to the ones that are also supported in the upcoming RISC-V standard.

The only new instructions are modesw.cap and modesw.int which will need to be supported in QEMU for hybrid mode code.

arichardson and others added 18 commits January 31, 2025 15:19
The new "cheri-common" feature will be used as the base for CHERI
functionality that is common across all variants (CHERIv9, CHERIoT and
the RISC-V standard extension).
This may have been needed before ISAInfo handled custom extensions, but
now we can just defer to ISAInfo. No functional change intended
The upcoming standard no longer includes cgetoffset (and cgetaddr has
been removed in ISAv9). For now the assembly code still accepts cgetaddr
and converts it to a move, but use an intrinsic call instead as that can
be optimized to a subregister read on next use rather the requiring an
explicit move.
This also handles implied features and therefore is more future-proof than
a simple string comparison.
The new -mxcheri-std-compat can be used to enable a compilation mode
that only permits the subset of CHERI instructions that will be
available in the upcoming CHERI standard (while still using the current
opcodes rather than the new ones).

It is not yet useful to use the -mxcheri-std-compat as it disables
many instructions that are generated internally and will therefore
result in crashes, but it can be used to check that assembly code does
not rely on instructions that will no longer be available.
CGetOffset is not part of the standard so we have to expand it to
`cap.addr - cap.base` instead.
There is no CGetSealed in the RISC-V standard, use GCTYPE instead.
CSetOffset is not part of the standard so we have to use
CSetAddr(CGetBase+offset) instead.
CClearTag is not part of the standard. Expand this to CSetHigh (which
always clears the tag bit) with the existing capability metadata bits
CRRL is not part of the standard so we need to use `((len + ~mask) & mask)`
instead. This was found while compiling a function with a variable
length stack allocation.
Previously the compiler would just fail with a cannot select/invalid
instruction predicates error. With this commit we now emit a C frontend
error pointing at the line where the unsupported builtin is used instead
of crashing. The end result is essentially the same but the new
behaviour is a lot more user-friendly.
These will not be expanded but instead just emit an error.
It should use underscores not dashes since that results in separate tokens
and also means __riscv_xcheri is no longer defined.
This can be used to conditionally compile code.
These will be needed since jr.cap no longer exists in the standard.
Support these loads by changing to the appropriate mode before and after
the load operation. This adds quite a bit of boilerplate but I don't
see a better approach for supporting this.
Need to use -1 and not zero!
@@ -2639,10 +2651,16 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl, unsigned BuiltinID,
}
break;
}
case Builtin::BI__builtin_cheri_cap_load_tags:
Copy link
Member Author

Choose a reason for hiding this comment

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

I guess we could expand this to lc+cgettag, but I think an error if it's not support might make it clearer that the optimized version does not exist?

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