Adds Innitial RVY support #787
Conversation
veselypeta
force-pushed
the
petr/implement-rvy
branch
from
70a6b06 to
f921abe
Compare
|
This is going to take a while to review, but two points I can make right now are that zRVY should be inferred from the arch string in .RISCV.attributes (and probably some riscvFoo member), and that we're not going to take the mapping symbols in that form (if you can infer the mode from the ISA string then you don't need to do anything new, and if we can't then $x should be something else like $y; Morello used $c but ARC has a vendetta against C). I'd suggest just leaving them out, they're not required to support RVY, it can be future work to make mixed-mode code disassemble better. |
|
Also it's [RISCV] for commit message prefixes, and RVY not rvy. |
.got.plt is the table of pointers, .plt is the instructions. |
| // RUN: | FileCheck %s --check-prefixes=CHECK,RV32-ZYHYBRID '-DFEATURES=+32bit,+xcheri-norvc,+y,+zyhybrid' | ||
| // RUN: %clang --target=riscv64 -march=rv64izyhybrid -S -mno-xcheri-rvc -emit-llvm %s -o - \ | ||
| // RUN: | FileCheck %s --check-prefixes=CHECK,RV64-ZYHYBRID '-DFEATURES=+64bit,+xcheri-norvc,+y,+zyhybrid' |
There was a problem hiding this comment.
I would drop all the +xcheri-norvc here. For RVY it should be based on the C extension.
There was a problem hiding this comment.
@jrtc27 do we still need this flag?
There was a problem hiding this comment.
I think I kept it so we could measure the gain from supporting compressing CHERI instructions, specifically thinking about numbers I might want for my PhD thesis. But it may not be quite right as it stands anyway (you probably want to compare with not remapping any of the C instructions, rather than disabling the ones that we remap), and can always be added back in a branch for that experiment.
| // RUN: %riscv64y_purecap_cc1 -E -dM -ffreestanding < /dev/null \ | ||
| // RUN: | FileCheck %s | ||
| // RUN: %riscv32y_purecap_cc1 -E -dM -ffreestanding < /dev/null \ | ||
| // RUN: | FileCheck %s | ||
| // RUN: %riscv64y_hybrid_cc1 -E -dM -ffreestanding < /dev/null \ | ||
| // RUN: | FileCheck --check-prefixes=CHECK,CHECK-HYBRID %s | ||
| // RUN: %riscv32y_hybrid_cc1 -E -dM -ffreestanding < /dev/null \ | ||
| // RUN: | FileCheck --check-prefixes=CHECK,CHECK-HYBRID %s |
There was a problem hiding this comment.
I would add a "--implicit-check-not=#define __CHERI" instead of the explicit CHECK-NOT lines.
| } | ||
|
|
||
| MCSubtargetInfo &RISCVAsmPrinter::copySTI() { | ||
| RISCVSubtarget &STICopy = *static_cast<RISCVSubtarget *>( |
There was a problem hiding this comment.
Once we've made one copy, can't we just freely modify the feature bits on that one without having to create a new copy each time? So maybe just have a local pointer that is null initially and gets set on the first copy?
There was a problem hiding this comment.
The reason for having to copy is that RISCVAsmPrinter stores a pointer to const of the subtarget info, so we copy-modify-replace to maintain the 'constness'. This is also done like this in RISCVAsmParser
veselypeta
force-pushed
the
petr/implement-rvy
branch
3 times, most recently
from
3bc2132 to
4ba003b
Compare
veselypeta
force-pushed
the
petr/implement-rvy
branch
from
4ba003b to
33a598e
Compare
3 participants
This PR:
xcheriinstructions.I've done my best to create a sensible history, and can hopefully be reviewed by commit. There is still quite a large commit which adds most of the support for the new instructions and codegen (let me know if this shoud be divided up further).