On 12/3/24 8:04 PM, Jiawei wrote:
We talked about this at the Cauldron, but I forget if we actually
ended up saying anything on the mailing lists. IIRC the general
conclusion here was that we should take advantage of all the RVA22/23
mandatory features, even if they're defacto not implemented in
shipping systems -- in other words, just generate code that crashes
now rather than trying to start working around vendors who ignore the
requirements.
So specifically I'm thinking of the misaligned access stuff here.
I believe this discussion pertains to the Zicclsm extension. As you say,
attempting to address misaligned access for non-compliant systems
introduces significant maintenance burdens and risks diluting the
clarity of the standard. Instead, allowing such issues to result in
crashes might serve to emphasize the importance of compliance with
RVA22/23 requirements.
Do you have any suggestions or thoughts on how we should handle this
situation?
I think the consensus was that we just enable whatever's appropriate for
rva23, including unaligned support.
If a design which claims to be be compliant, but isn't, then that's a
problem for the chip designer to deal with, not the compiler or OS.
Basically we want to incentivize proper implementation of the profile by
exploiting features in the profile and dis-incentivize vendors from
claiming profile compliance when they actually get it wrong.
It's harsh, but it's the right thing to do IMHO. We shouldn't penalize
proper implementations of the profile to work around bugs in other designs.
jeff
