[PATCH] D92842: [RFC][SelectionDAG] Add Target-Independent Compiler Barrier

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