* Jakub Jelinek: > On Wed, Sep 30, 2020 at 04:05:41PM +0200, Florian Weimer wrote: >> > I think the documentation should state that these are not valid in -mtune=, >> > just in -march=, and that using -march=x86-64-v* will not change tuning. >> > I guess there should be some testsuite coverage for the for some unexpected >> > behavior of >> > -march=skylake -march=x86-64-v3 >> > actually acting as >> > -march=x86-64-v3 -mtune=skylake >> > though perhaps it needs to be skipped if user used explicit -mtune= and >> > not sure how to actually test that (-fverbose-asm doesn't print -mtune= >> > when it is not explicit). >> >> I think the compiler driver collapses -march=skylake -march=x86-64-v3 >> to -march=x86-64-v3, dropping the tuning. The cc1 option parser also >> drops the first -march=. That's a bit surprising to me. It means >> that we can't use multiple tuning/non-tuning -march= switches, and >> that tuning with (say) -march=x86-64-v3 needs to use -mtune. >> >> PTA_NO_TUNE is still needed because we'd define __tune_k8__ otherwise >> (and switch to K8 tuning internally). >> >> Is it okay to simply document this? Perhaps like this? > > Thinking about it more, wouldn't it better to just imply generic tuning > for these -march= options?
I think this is what the patch does? See the x86-64-v3-haswell.c test. I tried to explain this in the documentation. I do not think this is particularly confusing for end users because they do not see the implementation, which is making this complicated. I think we should not set generic tuning in processor_alias_table because it would override tuning for target clones, and I don't think we want to do that automatically.
