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

[Nelson Chu]

Hi Guys,

I sent the patch to fix .option norvc and .option arch, -c,
https://inbox.sourceware.org/binutils/20250704054239.29226-1-nelson@rivosinc.com/T/#mea571cc2bf69ceeb0d0ff52ef0158fb92d1c2e8c,
which looks stupid but works.  My problem is - should norvc mean no zca,
zcf and zcd?  Or do we need to disable all non-compressed (zc*)
instructions, including zcb, zce, zcmp, zcmop, zcmt and zclsd?

Thanks
Nelson

On Fri, Jul 4, 2025 at 10:24 AM Nelson Chu <nelson@rivosinc.com> wrote:

> Agreed, .option norvc should be used everywhere and people should
> recognize them to trun off the rvc instructions, so at least we should fix
> it now...
>
> Thanks
> Nelson
>
> On Fri, Jul 4, 2025 at 10:14 AM Kito Cheng <kito.cheng@gmail.com> wrote:
>
>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20250704/432181fa/attachment.htm>