<div dir="ltr"><div dir="ltr">I left them in as aliases when I implemented this in LLVM last week. I was trying to not break user code that may exist. binutils and LLVM both have a number of aliases for backward compatibility.  For example, "move", "sbreak", "scall", "frsr", "fssr", "fmv.s.x", 'fmv.x.s". So I thought this was standard practice.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jul 29, 2025 at 8:04 AM Nelson Chu <<a href="mailto:nelson@rivosinc.com">nelson@rivosinc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 29, 2025 at 3:15 PM Jan Beulich <<a href="mailto:jbeulich@suse.com" target="_blank">jbeulich@suse.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 29.07.2025 06:45, Nelson Chu wrote:<br>
> The original patch,<br>
> e6f372ba661bb0d8eec1e22a6dc1ad9937336e4d<br>
> <br>
> Since recently c.slli64, c.srai64, and c.srli64 have been removed from the<br>
> riscv-isa-manual, c.slli, c.srli, and c.srai with 0 immediate are now listed<br>
> as hints,<br>
> <a href="https://github.com/riscv/riscv-isa-manual/pull/1942" rel="noreferrer" target="_blank">https://github.com/riscv/riscv-isa-manual/pull/1942</a> and <a href="https://github.com/riscv/riscv-isa-manual/pull/2093" rel="noreferrer" target="_blank">https://github.com/riscv/riscv-isa-manual/pull/2093</a><br>
> <br>
> So allow c.slli, c.srli, and c.srai with 0 immediate as a hint.  Also allow to<br>
> assemble slli, srli and srai with 0 immediate to hint c.slli, c.srli and c.srai<br>
> when rvc is enabled.  The c.slli64, c.srai64, and c.srli64 should be kept as<br>
> aliases, so dis-assembler should disassemble to c.slli, c.srli, and c.srai with<br>
> 0 immediate.<br>
<br>
I don't quite understand the point of retaining ...<br>
<br>
> @@ -1199,12 +1174,12 @@ const struct riscv_opcode riscv_opcodes[] =<br>
>  {"c.and",      0, INSN_CLASS_ZCA,   "Cs,Ct",     MATCH_C_AND, MASK_C_AND, match_opcode, 0 },<br>
>  {"c.or",       0, INSN_CLASS_ZCA,   "Cs,Ct",     MATCH_C_OR, MASK_C_OR, match_opcode, 0 },<br>
>  {"c.xor",      0, INSN_CLASS_ZCA,   "Cs,Ct",     MATCH_C_XOR, MASK_C_XOR, match_opcode, 0 },<br>
> -{"c.slli",     0, INSN_CLASS_ZCA,   "d,C>",      MATCH_C_SLLI, MASK_C_SLLI, match_c_slli, 0 },<br>
> -{"c.srli",     0, INSN_CLASS_ZCA,   "Cs,C>",     MATCH_C_SRLI, MASK_C_SRLI, match_c_slli, 0 },<br>
> -{"c.srai",     0, INSN_CLASS_ZCA,   "Cs,C>",     MATCH_C_SRAI, MASK_C_SRAI, match_c_slli, 0 },<br>
> -{"c.slli64",   0, INSN_CLASS_ZCA,   "d",         MATCH_C_SLLI64, MASK_C_SLLI64, match_c_slli64, 0 },<br>
> -{"c.srli64",   0, INSN_CLASS_ZCA,   "Cs",        MATCH_C_SRLI64, MASK_C_SRLI64, match_c_slli64, 0 },<br>
> -{"c.srai64",   0, INSN_CLASS_ZCA,   "Cs",        MATCH_C_SRAI64, MASK_C_SRAI64, match_c_slli64, 0 },<br>
> +{"c.slli64",   0, INSN_CLASS_ZCA,   "d",         MATCH_C_SLLI64, MASK_C_SLLI64, match_c_slli64, INSN_ALIAS },<br>
> +{"c.srli64",   0, INSN_CLASS_ZCA,   "Cs",        MATCH_C_SRLI64, MASK_C_SRLI64, match_c_slli64, INSN_ALIAS },<br>
> +{"c.srai64",   0, INSN_CLASS_ZCA,   "Cs",        MATCH_C_SRAI64, MASK_C_SRAI64, match_c_slli64, INSN_ALIAS },<br>
<br>
... these three. The assembler should reject them now, shouldn't it? And the<br>
disassembler will never use them: If use of aliases is enabled, the earlier<br>
entries which aren't c. prefixed would be used, whereas is aliases are<br>
disabled, ...<br>
<br>
> +{"c.slli",     0, INSN_CLASS_ZCA,   "d,C>",      MATCH_C_SLLI, MASK_C_SLLI, match_opcode, 0 },<br>
> +{"c.srli",     0, INSN_CLASS_ZCA,   "Cs,C>",     MATCH_C_SRLI, MASK_C_SRLI, match_opcode, 0 },<br>
> +{"c.srai",     0, INSN_CLASS_ZCA,   "Cs,C>",     MATCH_C_SRAI, MASK_C_SRAI, match_opcode, 0 },<br>
<br>
... these three would be used.<br></blockquote><div><br></div><div>Hi Jan,</div><div><br></div><div>Yeah sounds reasonable, just remove the support of c.slli64, c.srli64, c.srai64 since the spec already removed them.</div><div><br></div><div>Hi Craig,</div><div><br></div><div>Does llvm also not support these c.s[ll|rl|ra]i64 instructions?  If llvm does support then probably because of the compatible issue?</div><div><br></div><div>Thanks</div><div>Nelson </div><div> </div></div></div>
</blockquote></div></div>