[clang] [llvm] [RISCV] Remove B and Zbc extension from Andes series cpus. (PR #144022)

[Craig Topper via llvm-commits]

topperc wrote:

> > > Not related to this PR, but I'd like to raise the question here:
> 
> > > For configurable cores, what is the best way to specify the features? `-mcpu` is meant to support the base configuration, but how can we specify the additional optional extensions? Apparently, failing back to `-march` is silly.
> 
> > > My thought is: can we support `-march/-mcpu` where the values can be `{cpu}(_ext)*`? Will such use be problematic?
> 
> > 
> 
> > Unfortunately, we have to suggest our users to specify both `-march` and `-mcpu` when their processor includes additional optional extensions. Ideally, we hope that code generated using `-mcpu` alone would always be compatible with processors that have varying configurations.
> 
> 
> 
> This is the same trade-off that I would choose, but I understand why others have gone a different way.

X86 has a similar issue. -march=haswell enables AVX2, but the cheaper haswell CPUs branded as Pentium instead of Core, don't support AVX2.

> 
> 
> 
> My hope would be that the combination of `-march=` and `-mtune=` would be equivalent to `-mcpu=`, so if you added more features to `-march=`, you'd still get the code generation you want (scheduling, optimisations, etc) but also the additional instructions that you asked for. I think we've worked out how to model this well in the RISC-V backend, but I haven't examined how `-mtune=` is treated fully.
> 
> 

There are some mcpu that we enable unaligned memory access for but there is no equivalent march+mtune. You have to use the no-strict-align options too.

https://github.com/llvm/llvm-project/pull/144022