This is an archive of the discontinued LLVM Phabricator instance.

[RFC] Generate long nop instructions depending on function-specific subtarget info (version 2)
Needs ReviewPublic

Authored by aturetsk on Aug 15 2016, 5:59 AM.

Details

Summary
  1. Use SubtargetInfo (not CPU name) to control nop emission. For now we still use CPU name, but get it from SubtargetInfo. In the future new nop-related FeatureBits are supposed to be used instead.
  2. Support function multi-versioning, so that every function could have different nop padding depending on the target for which the function is compiled (e.g. through attribute "target").
  3. Compile path .ll -> .s -> .o must lead to the same result as .ll -> .o. That's why a new assembly directive '.arch' is introduced. The issue appears because of multi-versioning support: nop padding is done during object file creation, so compiler need to preserve target information till that moment (even in .s file). Because it hurts compatibility with other assemblies, it's done only if -asm-preserve-alignment option is specified.

Diff Detail

Event Timeline

aturetsk updated this revision to Diff 68027.Aug 15 2016, 5:59 AM
aturetsk retitled this revision from to [RFC] Generate long nop instructions depending on function-specific subtarget info (version 2).
aturetsk updated this object.
aturetsk added reviewers: echristo, bruno, RKSimon.
aturetsk added inline comments.Aug 15 2016, 6:14 AM
lib/MC/MCELFStreamer.cpp
85

Since we can end up merging two fragments with different STI (e.g. by using multiple '.arch' directives), we need a more general solution here. Didn't want to spend much time on this without being sure if the whole approach is OK...

lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
36

This is a placeholder for nop-related features I'm planning to add (FeatureLongNop, FeatureFastNop7).

rafael edited edge metadata.Aug 22 2016, 3:55 AM
rafael removed a subscriber: rafael.
RKSimon resigned from this revision.Sep 2 2016, 2:36 AM
RKSimon removed a reviewer: RKSimon.

Any comments?

This is a continuation of D21374 I assume? (Perhaps mark that one abandoned if so).

This is a new version of D21374 which takes into account the remark about .ll -> .s -> .o and .ll -> .o compile paths having different result.

dsanders removed a subscriber: dsanders.Sep 26 2016, 1:45 AM
jyknight added inline comments.Oct 5 2016, 12:19 PM
lib/MC/MCObjectStreamer.cpp
540

Why is this in generic code. Is .arch a generic directive? This syntax is x86-specific.

lib/MC/MCStreamer.cpp
33

I think this should be done so that it's compatible with gas. Is there some reason it can't be?

lib/Target/X86/AsmParser/X86AsmParser.cpp
3049

These features are LLVM features (right?), not the feature strings that are used with .arch. So this isn't really okay as is, unless the llvm features happened to align with the .arch features. Which they don't.

(.arch syntax in gas: https://sourceware.org/binutils/docs/as/i386_002dArch.html#i386_002dArch)

bruno resigned from this revision.Nov 9 2020, 11:52 AM