[PATCH 1/1] RISC-V: Support ".option [no]exact" assembler directives

[Jan Beulich]

On 16.05.2025 11:25, Tsukasa OI wrote:
> On 2025/05/16 18:12, Jan Beulich wrote:
>> On 16.05.2025 11:00, Tsukasa OI wrote:
>>> On 2025/05/16 15:38, Jan Beulich wrote:
>>>> Looks quite okay to me. I'm not entirely certain we need the new insn flag, but
>>>> perhaps it's good to do it this way to also cover the doc aspect (i.e. making
>>>> explicit which aliases are which).
>>>
>>> Thanks.
>>>
>>> The intent of the new instruction flag is, we don't want to disable all
>>> aliases but only aliases which will have unintended side effects in the
>>> context of the exact mode (currently, this flag is applied to RVC
>>> aliases which will change the instruction length from the non-RVC _main_
>>> encoding).
>>>
>>> For instance, we want to disable aliases of "addi" / "add" (that turn
>>> into compressed instructions like "c.addi") in the exact mode but we
>>> _don't_ want to disable "sgt" (set if greater than) aliases because
>>> "sgt" only turns into "sle" (set if less than or equal; with two source
>>> operands flipped) and unintended side effects in the context of the
>>> exact mode will not occur.
>>>
>>> For documentation, let me consider.  I think the best place to
>>> improve/describe is at the definition of INSN_NON_EXACT, right?
>>
>> I'm sorry if I caused confusion - I didn't mean to ask for anything to be
>> added.
> 
> Ah, looking now, I think the description of INSN_NON_EXACT is too brief
> to decide when to use and I want to add (at least) DOs and DON'Ts.
> 
> And, I found a clear bug and a border case while reviewing my patch set.
>  So, I thought it's a good time to reconsider.
> 
> 1.  "unimp" (compressed alias) lacks INSN_NON_EXACT and must be added.
> 2.  Decide whether we add INSN_NON_EXACT to non-compressed
>     aliases of "zext.[wh]" (likely to keep as-is).

zext.h only has a C alias, which needs treating like other compressed aliases.
Same for the C alias for zext.w; the Zba alias likely also needs treating
like that, but then there's only the macro one left. Which reminds me that I
wanted to ask about macro insns: Should they actually be permitted in "exact"
mode? (This _may_ be okay if what the macro expands to is precisely what the
spec says, but I'm unsure whether there weren't a few "extensions" in our
code.)

Jan