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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
