- 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.
- 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").
- 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.
Details
- Reviewers
• tstellarAMD echristo • espindola bruno
Diff Detail
Event Timeline
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). |
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.
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) |
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...