[PATCH] D92842: [RFC][SelectionDAG] Add Target-Independent Compiler Barrier
Craig Topper via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Dec 10 11:14:32 PST 2020
craig.topper added inline comments.
================
Comment at: llvm/test/CodeGen/X86/atomic-idempotent.ll:384
+; X86-ATOM-NEXT: # Compiler Barrier: acquire
+; X86-ATOM-NEXT: nop
+; X86-ATOM-NEXT: nop
----------------
jrtc27 wrote:
> craig.topper wrote:
> > jrtc27 wrote:
> > > What's up with this change?
> > I'm guessing that TargetOpcode::COMPILER_BARRIER is giving a different value from TargetSchedMode::computeInstrLatency() that X86::MEMBARRIER did which changed how X86PadShortFunctions.cpp computed how many NOPs to add before the return.
> I guess the question then is "which is better?".
I think we were counting a "compiler barrier" that doesn't generate code as having a non-zero or multiple cycle latency before. So this change is probably better.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D92842/new/
https://reviews.llvm.org/D92842
More information about the llvm-commits
mailing list