This is an archive of the discontinued LLVM Phabricator instance.

[RFC] Generate long nop instructions depending on function-specific subtarget info
AbandonedPublic

Authored by aturetsk on Jun 15 2016, 5:20 AM.

Details

Summary

Store function-specific subtarget info in MCFragments during machine function pass AsmPrinter and later write long nop instructions in MCAssembler depending on this info.

Diff Detail

Event Timeline

aturetsk updated this revision to Diff 60818.Jun 15 2016, 5:20 AM
aturetsk retitled this revision from to [RFC] Generate long nop instructions depending on function-specific subtarget info.
aturetsk updated this object.
aturetsk added reviewers: echristo, bruno, RKSimon.
aturetsk added a subscriber: llvm-commits.

Hi,

I've been thinking about a way to generate function-specific long nop instructions and here is what I came up with:

  1. Function-specific subtarget info seems to be available only during machine function passes. However I don't think we can start generating long nops somewhere there, so during the pass which creates MCFragments (AsmPrinter) we store the info in the fragments which hold the function.
  2. We generate long nops in MCAssembler as we've been doing so far, just additionally pass the function subtarget info to the writeNopData function.
  3. Unfortunately I didn't find a better way to pass a module subtarget info to the writeNopData other that in the rejected http://reviews.llvm.org/D17573 (so to work correctly this patch is applied on top of it). Eric suggested to move writeNopData from AsmBackend somewhere else, but I didn't find a better place with module subtarget info available there. Also, I didn't find a way to reach module subtarget info from MCAssembler. I'd appreciate any advise on how to do that any other way than http://reviews.llvm.org/D17573.

The result of the patch you can see in the test - generated long nops differ from function to function depending on the specified targets.

aturetsk updated this object.Jun 15 2016, 5:42 AM
aturetsk edited edge metadata.

How is this represented is the assembly file?

We should not create another case where we cannot go from .ll to .s to .o.

Cheers,
Rafael

Can we use llvm.ident metadata which is stored and loaded from an assembly file to keep function-specific subtarget information across assembly?
For example we could store "llvm/multiversioning/symbol_name/cpu_name/feature_bits_hex" string in ident metadata for functions which subtarget info differs from module's info in AsmPrinter::FinalizeMachineFunction.

echristo edited edge metadata.Jul 4 2016, 10:20 AM
echristo added a subscriber: echristo.

No, that doesn't sound like a good idea. There should be done way of
representing this in assembly.

How is this represented is the assembly file?

We should not create another case where we cannot go from .ll to .s to .o.

I'd have expected that indicating which instructions are used ought to be done via emitting an ".arch" directive when the desired architecture changes in the emitter, and then using that data in the assembler. Unfortunately, LLVM's assembler doesn't support ".arch" on x86 at the moment, so that's a bit of a shame.

See the testcase in gas, "gas/testsuite/gas/i386/nops-5.s" (nops-5.d output) for an example of using .arch to influence the output of .p2align.

For some reason, though, it looks like GCC doesn't emit the .arch directive, even when doing e.g. #pragma GCC target ("arch=i386"). So I dunno. *shrug*.

James, thanks for pointing this directive out! I'll look at it closely.

RKSimon resigned from this revision.Sep 2 2016, 2:35 AM
RKSimon removed a reviewer: RKSimon.