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