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

[Nelson Chu]

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/672d6203/attachment-0001.htm>