[PATCH] D17573: [X86] PR26554: Enable using of true long nops for x86-64 for every CPU

[Simon Pilgrim via llvm-commits]

RKSimon added a subscriber: RKSimon.

================
Comment at: lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp:353
@@ -345,3 +352,3 @@
   // Select the right NOP table.
   // FIXME: Can we get if CPU supports long nops from the subtarget somehow?
   const uint8_t (*Nops)[10] = HasNopl ? TrueNops : AltNops;
----------------
bruno wrote:
> aturetsk wrote:
> > bruno wrote:
> > > Any reason why this shouldn't be done as a target feature as suggested in the FIXME above?
> > Target feature can be used as indicator of true long nop support, but that won't fix the issue.
> > 
> > The alternative nop instructions I introduced in http://reviews.llvm.org/D14178 are not actually nops for x86-64 arch. But all CPUs which don't support true long nops are 32-bit-only. So I propose to use true long nops if we compile for x86-64 arch for any CPU even if it's marked as 'doesn't support true long nops'.
> > Well, we do generate 64-bit instructions for 32-bit-only CPUs when x86-64 arch is used, why not generate true long nops as well?
> > And I think 'generic' should use true long nops in 64-bit mode (since every real 64 bit CPU seems to support them) and use alternative long nops in 32 bit mode.
> I see. However, we could have the opposite logic, something like "FeatureShortNop", and mark generic, i386, etc with them. I looked up these CPUs and none of them have Feature64Bit, so guess HasNopl will simply become !FeatureShortNop.
Basing this off target features would also make it much easier to chose the optimal nop length for intel/amd (as discussed on PR22965).


http://reviews.llvm.org/D17573