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

[Nelson Chu]

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/20241119/950c0ca8/attachment-0001.htm>