Auto-enable Vector Crypto superset extensions (Zvkn, Zvknc, Zvkng, Zvks, Zvksc, Zvksg)

[nadime15]

Add remaining vector crypto extensions and automatically enable superset extensions when all of the appropriate subset extensions are enabled.

[github-actions]

Test Results

400 tests  ±0   400 ✅ ±0   1m 28s ⏱️ -1s
  1 suites ±0     0 💤 ±0 
  1 files   ±0     0 ❌ ±0 

Results for commit 96ba8c3. ± Comparison against base commit d8c3006.

♻️ This comment has been updated with latest results.

[nadime15]

Does somebody know how things actually work with the device tree and shorthands like these:

Vector Crypto Extensions

Extension	Description
Zvkn	Zvkned + Zvknhb + Zvkb + Zvkt
Zvknc	Zvkn + Zvbc
Zvkng	Zvkn + Zvkg
Zvks	Zvksed + Zvksh + Zvkb + Zvkt
Zvksc	Zvks + Zvbc
Zvksg	Zvks + Zvkg

So let’s say I enable Zvknc, which pulls in Zvkn + Zvbc, and those pull in Zvkned + Zvknhb + Zvkb + Zvkt. Should the final device tree only print Zvknc or Zvbc_Zvkn_Zvknc or even Zvbc_Zvkb_Zvkn_Zvknc_Zvkned_Zvknhb_Zvkt.

As far as I can see now its actually printing Zvbc_Zvkb_Zvkn_Zvknc_Zvkned_Zvknhb_Zvkt but the desired behaviour (?) is probably only to print Zvknc.

@pmundkur

[Timmmm]

Yeah I think we can print the minimum necessary if the others are implied. You don't have to always list all the sub-extensions.

[jordancarlin]

I think the simplest approach is to not include these superset extensions in the config file and instead just have the smallest granularity extensions. These should still exist in the extensions enum and would get turned on automatically if all of the appropriate subset extensions are enabled.

In terms of what to print in the device tree/isa string, it might be the least ambiguous to just print the full list even if that is more verbose. I know some tools (like riscv-config) don't always handle the superset extensions well.

[pmundkur]

Yes, I think for now we should stick to the smallest granularity extensions in the model and config file. We could rely on other tooling (such as that in #993) to convert superset extensions into Sail model configurations.

[Timmmm]

But note that in some cases it isn't as simple as extension 1 = extensions 2 + 3. IIRC think supporting B or C is different to supporting the extensions that they cover. In this case I believe it is though.

[jordancarlin]

hartSupports_measure in riscv_termination.sail needs to be updated with the dependency order to fix the Lean build.

[pmundkur]

I'm rethinking the choice to not expose superset extensions in the config file. It necessitates extra tooling (and a degree of user-unfriendliness); is there a way of handling this without extra tooling?

This would mean some extensions may not appear in the config file, e.g. if Zvknc is marked as supported, Zvkn and Zvbc may not appear since they would be redundant. This would require some additional flexibility in the configuration mechanism, e.g. a check for whether a configuration option appears before trying to read its value.

[jordancarlin]

LGTM based on the decisions made in Monday's meeting.

[Timmmm]

Isn't this going to put the superset extensions and the subset ones in the ISA string? That seems slightly odd... Or is that intentional?

[jordancarlin]

Isn't this going to put the superset extensions and the subset ones in the ISA string? That seems slightly odd... Or is that intentional?

I think we decided that the generated ISA string should take the approach of being exhaustive to satisfy tools that might be looking for one or the other.