2 ms·

LLVM needs a way to be able to turn off compressed instructions entirely at configuration time. Some of the RISC-V server platforms which will appear in the ne

by rwmj 3y ago

LLVM needs a way to be able to turn off compressed instructions entirely at configuration time. Some of the RISC-V server platforms which will appear in the next few years won't have them.

LoganDark 3y ago
Those server platforms will make sure LLVM supports whatever they have, because a loss of Rust would be a very large blow, unless rustc_codegen_gcc is production-ready by then.
asb 3y ago
You could certainly change the default `-march` to rv64g (plus whatever extensions you want) rather than rv64gc. That provides mostly what you'd want, though there's some small chance that inline asm or hand-written assembly using `.option rvc` or `.option arch, +c` inappropriately causes issues. I just posted some thoughts on this here: https://lists.riscv.org/g/tech-profiles/message/348 https://lists.riscv.org/g/tech-profiles/message/348
- rwmj 3y ago
  Using 'clang -march=rv64g' does work but it's a pain in the neck for Linux distros. [Edit] The question is, is there a way to change this at llvm build time? I wasn't able to find a way. For GNU binutils it is relatively simple. BTW I've been writing a document on the topic of how Linux distros will support hardware with and without compressed: https://github.com/rwmjones/rhrq-riscv-extensions/blob/main/compressed.md https://github.com/rwmjones/rhrq-riscv-extensions/blob/main/...
  - asb 3y ago
    99.9% of my clang invocations are from the build dir of the git tree I'm working on, so I could be missing something known to others on the distribution side - but let me try my best answer. Firstly, as you probably know the Clang/LLVM model is quite different to gcc/binutils in terms of build-time configuration. Any clang can target any architecture (unless it was disabled at build time) using --target=$TRIPLE (see <https://clang.llvm.org/docs/CrossCompilation.html#target-triple https://clang.llvm.org/docs/CrossCompilation.html#target-tri...>). In practice it's not as useful as it sounds of course because you need appropriate sysroots. You can control the default with LLVM_DEFAULT_TARGET_TRIPLE, but without patching clang it's going to enabled compressed for the riscv64-unknown-linux-gnu triple. I think the standard way of controlling other default flags would be to deploy a configuration file <https://clang.llvm.org/docs/UsersManual.html#configuration-files https://clang.llvm.org/docs/UsersManual.html#configuration-f...> - though I'd need to check which logic took precedent if you explicitly passed --target=riscv64-unknown-linux-gnu. Ultimately we'd need to change the meaning of the current linux triples, or decide upon new ones I think. Thanks for sharing that doc - really helpful. I don't know if it's different with GNU as, but not that if a file contains `.option rvc` that _isn't_ sufficient to set the EF_RISCV_RVC ELF flag with LLVM. Additionally, I'd imagine in general that people using .option in inline asm may see different behaviour for Clang vs GCC. Clang doesn't generate assembly output that then gets passed to the assembly - ELF emission happens directly (of course, with the assembler being invoked as needed for inline asm blocks), and so it's rather difficult to replicate the effect you'd see with GCC generating a .s file that's then assembled.
cpeterso 3y ago
Why would RISC-V servers not want to support compressed instructions? I imagine compressed instructions would improve code memory locality, perhaps at the cost of some instruction decode overhead. On the flip side, Minimax is a RISC-V design that only implements compressed instructions: https://news.ycombinator.com/item?id=33422717 https://news.ycombinator.com/item?id=33422717
- fwsgonzo 3y ago
  One thing that comes to mind: Compressed instructions enable 2-byte alignment for all instructions, and actually allows for a 4-byte instruction to span two pages. EDIT: Looks like I'm not alone: https://news.ycombinator.com/item?id=29667135 https://news.ycombinator.com/item?id=29667135 He is completely right and I have had those exact problems: Not being able to figure out where you are in the instruction stream annoys me when it comes to RVC. I actually dislike it so much that I intentionally disregard it in my RISC-V emulator and focus on other things, eg. RV64GVB etc. I support C-extension, but it's hard to make it run fast. I wish they solved compression another way. We have very fast compressors/decompressors that can use dedicated dictionaries that could have been used in ELF loading instead.
  - circuit10 3y ago
    Decompressing during loading wouldn’t help memory/cache usage once the code is loaded
    - fwsgonzo 3y ago
      I didn't think about the potential benefits of fitting in icache. I managed to find this PDF that does admit that it has a modest 2-3% benefit whenever the code wouldn't normally fit in icache: https://forums.macrumors.com/attachments/a-case-to-remove-the-c-extension-from-app-profiles-profiltes-tg-20230929-pdf.2290162/ https://forums.macrumors.com/attachments/a-case-to-remove-th...
- rwmj 3y ago
  The servers in development have huge i-caches and gobs of memory bandwidth so compressed instructions don't really benefit there. (They are much more appropriate in embedded designs.) The real issues are two-fold: Compressed instructions consume 75% of the instruction encoding space. The thought is that without compressed instructions occupying that space, more 32-bit extensions can be added before we need to use longer instructions. Secondly verifying designs which use unaligned instructions is difficult because there are many different cases to consider (especially instructions crossing cache lines and pages). The verification thing comes from a particular vendor who already design very high end chips - you are likely to have several in your possession - and I have to assume they know what they're talking about.
snvzz 3y ago
This FUD keeps popping up every now and again. Yes, compressed instructions rely on variable size opcodes. No, it isn't like x86 where it's really complex for the decoder to know where instructions start and end. It has been designed to avoid that. As for actual implementations, every server chip that's been announced so far supports them. This includes Tenstorrent Ascalon, the one with the 8-wide decoder. Higher code density means more code fits in cache, or less cache is needed (and can thus be clocked higher). It helps very high performance implementations.

by rwmj 3y ago

LLVM needs a way to be able to turn off compressed instructions entirely at configuration time. Some of the RISC-V server platforms which will appear in the next few years won't have them.

LoganDark 3y ago

Those server platforms will make sure LLVM supports whatever they have, because a loss of Rust would be a very large blow, unless rustc_codegen_gcc is production-ready by then.

asb 3y ago

You could certainly change the default `-march` to rv64g (plus whatever extensions you want) rather than rv64gc. That provides mostly what you'd want, though there's some small chance that inline asm or hand-written assembly using `.option rvc` or `.option arch, +c` inappropriately causes issues. I just posted some thoughts on this here: https://lists.riscv.org/g/tech-profiles/message/348 https://lists.riscv.org/g/tech-profiles/message/348

rwmj 3y ago
Using 'clang -march=rv64g' does work but it's a pain in the neck for Linux distros. [Edit] The question is, is there a way to change this at llvm build time? I wasn't able to find a way. For GNU binutils it is relatively simple. BTW I've been writing a document on the topic of how Linux distros will support hardware with and without compressed: https://github.com/rwmjones/rhrq-riscv-extensions/blob/main/compressed.md https://github.com/rwmjones/rhrq-riscv-extensions/blob/main/...
- asb 3y ago
  99.9% of my clang invocations are from the build dir of the git tree I'm working on, so I could be missing something known to others on the distribution side - but let me try my best answer. Firstly, as you probably know the Clang/LLVM model is quite different to gcc/binutils in terms of build-time configuration. Any clang can target any architecture (unless it was disabled at build time) using --target=$TRIPLE (see <https://clang.llvm.org/docs/CrossCompilation.html#target-triple https://clang.llvm.org/docs/CrossCompilation.html#target-tri...>). In practice it's not as useful as it sounds of course because you need appropriate sysroots. You can control the default with LLVM_DEFAULT_TARGET_TRIPLE, but without patching clang it's going to enabled compressed for the riscv64-unknown-linux-gnu triple. I think the standard way of controlling other default flags would be to deploy a configuration file <https://clang.llvm.org/docs/UsersManual.html#configuration-files https://clang.llvm.org/docs/UsersManual.html#configuration-f...> - though I'd need to check which logic took precedent if you explicitly passed --target=riscv64-unknown-linux-gnu. Ultimately we'd need to change the meaning of the current linux triples, or decide upon new ones I think. Thanks for sharing that doc - really helpful. I don't know if it's different with GNU as, but not that if a file contains `.option rvc` that _isn't_ sufficient to set the EF_RISCV_RVC ELF flag with LLVM. Additionally, I'd imagine in general that people using .option in inline asm may see different behaviour for Clang vs GCC. Clang doesn't generate assembly output that then gets passed to the assembly - ELF emission happens directly (of course, with the assembler being invoked as needed for inline asm blocks), and so it's rather difficult to replicate the effect you'd see with GCC generating a .s file that's then assembled.

cpeterso 3y ago

Why would RISC-V servers not want to support compressed instructions? I imagine compressed instructions would improve code memory locality, perhaps at the cost of some instruction decode overhead. On the flip side, Minimax is a RISC-V design that only implements compressed instructions: https://news.ycombinator.com/item?id=33422717 https://news.ycombinator.com/item?id=33422717

fwsgonzo 3y ago
One thing that comes to mind: Compressed instructions enable 2-byte alignment for all instructions, and actually allows for a 4-byte instruction to span two pages. EDIT: Looks like I'm not alone: https://news.ycombinator.com/item?id=29667135 https://news.ycombinator.com/item?id=29667135 He is completely right and I have had those exact problems: Not being able to figure out where you are in the instruction stream annoys me when it comes to RVC. I actually dislike it so much that I intentionally disregard it in my RISC-V emulator and focus on other things, eg. RV64GVB etc. I support C-extension, but it's hard to make it run fast. I wish they solved compression another way. We have very fast compressors/decompressors that can use dedicated dictionaries that could have been used in ELF loading instead.
- circuit10 3y ago
  Decompressing during loading wouldn’t help memory/cache usage once the code is loaded
  - fwsgonzo 3y ago
    I didn't think about the potential benefits of fitting in icache. I managed to find this PDF that does admit that it has a modest 2-3% benefit whenever the code wouldn't normally fit in icache: https://forums.macrumors.com/attachments/a-case-to-remove-the-c-extension-from-app-profiles-profiltes-tg-20230929-pdf.2290162/ https://forums.macrumors.com/attachments/a-case-to-remove-th...
rwmj 3y ago
The servers in development have huge i-caches and gobs of memory bandwidth so compressed instructions don't really benefit there. (They are much more appropriate in embedded designs.) The real issues are two-fold: Compressed instructions consume 75% of the instruction encoding space. The thought is that without compressed instructions occupying that space, more 32-bit extensions can be added before we need to use longer instructions. Secondly verifying designs which use unaligned instructions is difficult because there are many different cases to consider (especially instructions crossing cache lines and pages). The verification thing comes from a particular vendor who already design very high end chips - you are likely to have several in your possession - and I have to assume they know what they're talking about.

snvzz 3y ago

This FUD keeps popping up every now and again. Yes, compressed instructions rely on variable size opcodes. No, it isn't like x86 where it's really complex for the decoder to know where instructions start and end. It has been designed to avoid that. As for actual implementations, every server chip that's been announced so far supports them. This includes Tenstorrent Ascalon, the one with the 8-wide decoder. Higher code density means more code fits in cache, or less cache is needed (and can thus be clocked higher). It helps very high performance implementations.