[PATCH] D85384: [X86] Add basic support for -mtune command line option in clang

Tue Aug 18 12:26:04 PDT 2020

craig.topper added inline comments.

================
Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1752
   StringRef TargetCPU = getTarget().getTargetOpts().CPU;
+  StringRef TuneCPU = getTarget().getTargetOpts().TuneCPU;
   std::vector<std::string> Features;
----------------
erichkeane wrote:
> craig.topper wrote:
> > erichkeane wrote:
> > > Does this lead to a situation in 'attribute-target' where we have a 'tune' setting to a processor that is 'before' the 'TargetCPU'?  Should this enforce some sort of hierarchy to make sure we only do it if it is 'newer' (read, more feature rich) than the target?
> > TuneCPU is only supposed to control microarchitectural things like should i prefer an "ADD 1" over "INC" instruction. Or should I use more immediate controlled shuffles over a single variable controlled shuffle. As such that things we get from tune don't have a straightforward relationship with architectural features.
> My concern is more.  Say:
> 
> TargetCPU == "nahalem"
> 
> Does it make sense for 
> TuneCPU == "pentium"?
> 
> It would seem to me that is pretty nonsensical.  I've definitely seen the reverse (in within x86_64 at least, where Tune is newer than Target), but tuning for an older CPU seems like nonsense.
>From a behavior standpoint, its not any different than what this does today

-march=pentium -msse4.2 -mpopcnt -mfxsr <other nehalem features>

I don't think gcc enforces any ordering.  

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85384/new/

https://reviews.llvm.org/D85384