Compatibility with RV64GC

[alpencolt]

As we know AOSP and ART use RVA22 profile, which brings big amount of useful extensions. But there are no so many boards on market in the current moment which support it. And I'm not sure that future low end consumer devices will be able to support it.
If we look to OpenJDK, it checks what extensions are supported.
.NET Runtime target is RV64GC.

So, while there are no so many parts of ART which use specific for RVA22 extensions, is it possible to check their availability (via new API, or just ifdef) and make AOSP compatible with RV64GC?
If it's OK, I can prepare PR.

[enh-google]

And I'm not sure that future low end consumer devices will be able to support it.

Android/risc-v is going to need to be competitive with Android/arm64. RVA22 + V + vector crypto doesn't quite get us to the 2012 armv8.0 baseline, but it gets us close. in 2023, it's not realistic to aim lower than what everyone else has been using for more than a decade.

the performance of current boards -- even for the instructions they do support -- leaves a lot to be desired too. i haven't yet seen anything that could realistically compete even in the lowest supported Android segments.

that said, although we think qemu is the best ("least worst") option right now, we are sympathetic to folks trying to do work on current hardware while they wait for more useful hardware. it's pretty easy to manually revert the more-than-just-rv64gc changes for local testing if desired.

but the NDK ABI needs to be competitive with other architectures, and plain rv64gc just isn't.

[SiFiveHolland]

FWIW, I've started upstreaming our patch set for supporting a smaller set of extensions (down to RV64GC). Whether or not any of it gets merged, it will be available for folks to use.

[enh-google]

that's an interesting idea --- i coincidentally spent part of the afternoon debugging an issue caused by our "we won't remove non-V code" policy, and by far the easiest fix is for me to remove the non-V support, so if folks want to keep their own patches, that might be the least worst option. (given how slow all hardware currently on sale is, though, i still think qemu is a "less bad" option!)