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

Fri Jul 4 02:24:53 GMT 2025

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/8dbb1d2e/attachment-0001.htm>