[PATCH] RISC-V: Clarufy the behavior when extensions have superset.

[Kito Cheng]

I guess the formal semantic of ".option arch, -ext" is not really
concluded on the RISC-V community since there is a complicated
implication rule (*), so I would prevent using that as a baseline to
compare.

Back to RVC, that's really a historical issues, I was prefer don't
touch the definition: Keep it turn off C ext (norvc) and turn on C ext
(rvc),
however I realized people already use that in lots of places and
expect the behavior is "turn off compressed instruction and turn on
compressed instructions."
It's not wrong, but just ISA spec has extended the meaning of C extension.

So...I am inclined to update the definition to turn off compressed
instruction (norvc) and turn on compressed instruction (rvc) to make
sure we won't break most option rvc/norvc users around the RISC-V
world.

* I am not saying binutils is doing wrong or binutils should not be
doing bra bra bra, it's just not formally documented and reached
consensus with the RISC-V LLVM community.

On Fri, Jul 4, 2025 at 9:51 AM Nelson Chu <nelson@rivosinc.com> wrote:
>
> Hi Jeff, Jan, Kito, Vineet,
>
> I got a request recently that gcc 15 breaks the assembler .option norvc directives.  I think these two gcc patches caused the issue,
> RISC-V: c implies zca, and conditionally zcf & zcd, https://github.com/gcc-mirror/gcc/commit/36e5e409190e595638cec053ea034d20d5c74d6b
> [PATCH] RISC-V: Imply C from Zca whenever possible [PR119122], https://://github.com/gcc-mirror/gcc/commit/42ce61eaefc4db70e2e7ea2d8ef091daa458eb48
>
> In fact these two patches should be correct, it's a binutils bug for a long time, which starting from c was cut into zca, zcf and zcd, but just triggered by them.  I think not only c has this problem, the extensions mentioned in this binutils patch also have similar problems that make ".option arch, -ext" break.  But it's near 2.45 release, personally I prefer to just let ".option arch, -c" and ".option norvc" work as expected in 2.45, and then we can have more time to fix the removal of whole related extensions.  I will send the workaround later and cc you guys.
>
> Thanks
> Nelson
>
> On Tue, Nov 19, 2024 at 1:37 PM Nelson Chu <nelson@rivosinc.com> wrote:
>>
>> On Thu, Nov 14, 2024 at 9:00 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>
>>> On 14.11.2024 13:38, Nelson Chu wrote:
>>> > If extensions have superset, then which means the superset includes those
>>> > extensions.  We used to imply those extensions for the superset, and also
>>> > keep the superset since the canonical order form.  For example,
>>> >
>>> > * m includes zmmul, m implies zmmul
>>> > * b includes zba, zbb and zbs, and b also equals to zba + zbb + zbs, so b
>>> >   implies zba, zbb and zbs
>>> >
>>> > For all include rules,
>>> > m includes zmmul
>>> > zvbb includes zvkb
>>> > zhinx includes zhinxmin
>>> > zfh includes zfhmin
>>> >
>>> > For all equal rules,
>>> > a equals to zaamo + zalrsc
>>> > b equals to zba + zbb + zbs
>>> > zks equals to zbkb + zbkc + zbkx + zksed + zksh
>>> > zkn equals to zbkb + zbkc + zbkx + zkne + zknd + zknh
>>> > zk equals to zkn + zkr + zkt
>>> > zvkn equals to zvkb + zvkt + zvkned + zvknhb
>>> > zvks equals to zvkb + zvkt + zvksed + zvksh
>>> > zvkng equals to zvkn + zvkg
>>> > zvknc equals to zvkn + zvbc
>>> > zvksg equals to zvks + zvkg
>>> > zvksc equals to zvks + zvbc
>>> > c equals to zca + zcf (if rv32 and f) + zcd (if d)
>>> >
>>> > g is a super special case, so skip it here.
>>> >
>>> > Considering ".option arch, -extension [,...,-extension_n]" removes the
>>> > extension which,
>>> > 1. A includes B;
>>> >    Remove A should also remove B;
>>> >    Remove B is useless since we don't have any extensions to represent A - B
>>> > 2. A equals to B + C + ...;
>>> >    Remove A should also remove B, C and ...;
>>> >    Remove B should also remove A, but keep C and ...;
>>> >    Remove C should also remove A, but keep B and ...;
>>> >    Remove B ansd C should also remove A, but keep ...;
>>>
>>> I agree with 2, but that imo contradicts 1: Remove B should also remove A,
>>> as A = B + <unnamed>. The two still aren't mere aliases of one another, as
>>> behavior is different when they're added to the permitted extensions.
>>>
>>> (Otherwise, at the very least, a removal that doesn't remove anything
>>> should at least have a diagnostic issued.)
>>
>>
>> Sounds good, at least a warning is necessary, thanks.
>>
>>>
>>> > 3. A implies B;
>>> >    Remove B is useless, since A still imply B;
>>> >    Remove A doesn't affect B, since B may still be implied by others;
>>>
>>> I'm afraid I didn't really get what the difference is between "implies"
>>> and "includes". In particular, related to the 2nd sentence, in the
>>> summary at the top I can't spot any case of two distinct extensions
>>> implying the same more narrow one. Imo, if anything this 2nd rule
>>> should be "Remove A doesn't affect B, if B is still implied by another
>>> active one". Plus that (in your or my form) would still be similarly
>>> true for "included".
>>
>>
>> I think "includes" here is more like a large extension (superset) which is split into small ones (subsets);
>>
>> The "implies" originally means an extension generally needs others, or said they are best used together, so toolchain helps add these implies for convenience.  These extensions are basically different, so they are not the same as includes.  For example, f implies zicsr was because f has some floating csrs, so f probably will need zicsr instructions to access those csrs, though it seems still work if not enabling zicsr.  Compared to "imples", the "requires" is more mandatory, it is more inclined to "must".  But for now the implementation of "implies" is also mandatory and cannot be disabled, so maybe it isn't no longer important to distinguish between "implies" and "requires".  Anyway, if an extension needs/requires/...whatever... some extensions, toolchain will add these "implies" to make sure things goes well.
>>
>> As for why we add those "included" as "implies", and keep the superset before...  No matter it is because of the convenience in practice, or the canonical order form, there is no difference when only "adding" extensions, but have some troubles when supporting "removing"...
>>
>> I think Andrew and Kito can explain these terms better than I can, so hope they will see and have time to reply to something ;)
>>
>> Thanks
>> Nelson