[PATCH] D82826: [X86] support .nops directive
Jian Cai via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 7 14:39:12 PDT 2020
jcai19 marked 2 inline comments as done.
jcai19 added inline comments.
================
Comment at: llvm/lib/MC/MCAssembler.cpp:644
+
+ while (NumBytes) {
+ uint64_t NopsToEmit = (uint64_t)std::min(NumBytes, MaxNopLength);
----------------
reames wrote:
> This loop is duplicated from within emitNops. Can you pass in a MaxNopLength parameter instead?
There isn't any loop in emitNops. Do you by any chance refer to the loop in writeNopData? In that case, they are not duplicate as this loop will break total bytes into nop instructions no longer than specified by the second argument of .nops if provided, while the loop in writeNopData makes sure each instruction emitted is no longer than the maximum length allowed by the target.
================
Comment at: llvm/test/MC/X86/align-branch-bundle.s:9
# CHECK-NEXT: e: nop
-# CHECK-NEXT: f: nop
# CHECK-NEXT: 10: jle
----------------
jcai19 wrote:
> reames wrote:
> > Having a test delta in a file without .nops is highly suspicious.
> >
> > I'd suggest splitting your patch into a trivial version which emits single byte nops, and an change which adds the multiple byte support. That would allow us to separate the directive mechanics from the interesting profit bits.
> How about we also print out instruction bytes here. If 64-bit processors can generate a two-byte long nop instruction here, shouldn't we emit that instead of two single-byte nop? Thanks.
On second thought, I agree that splitting the patch is the better approach in case the multiple-byte support causes any regression. Will address this in the next iteration.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D82826/new/
https://reviews.llvm.org/D82826
More information about the llvm-commits
mailing list