On 8/8/23 14:06, Daniel Henrique Barboza wrote:
(CCing Alistair and other reviewers)
On 8/8/23 15:17, Vineet Gupta wrote:
Again this helps with better testing and something qemu has been doing
with newer features anyways.
Signed-off-by: Vineet Gupta <[email protected]>
---
Even if we can reach a consensus about removing the experimental (x-
prefix) status
from an extension that is Frozen instead of ratified, enabling stuff
in the default
CPUs because it's easier to test is something we would like to avoid.
The rv64
CPU has a random set of extensions enabled for the most different and
undocumented
reasons, and users don't know what they'll get because we keep beefing
up the
generic CPUs arbitrarily.
I understand this position given the arbitrary nature of gazillion
extensions. However pragmatically things like bitmanip and zicond are so
fundamental it would be strange for designs to not have them, in a few
years. Besides these don't compete or conflict with other extensions.
But on face value it is indeed possible for vendors to drop them for
various reasons or no-reasons.
But having the x- dropped is good enough for our needs as there's
already mechanisms to enable the toggles from elf attributes.
Starting on QEMU 8.2 we'll have a 'max' CPU type that will enable all
non-experimental
and non-vendor extensions by default, making it easier for tooling to
test new
features/extensions. All tooling should consider changing their
scripts to use the
'max' CPU when it's available.
That would be great.
For now, I fear that gcc and friends will still need to enable
'zicond' in the command
line via 'zicond=true'. Thanks,
Thx,
-Vineet
