[PATCH] D109069: [AArch64] Avoid adding duplicate implicit operands when expanding pseudo insts.

weiwei via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 2 06:43:36 PDT 2021


wwei added a comment.

The detailed explanation is:
Before post-ra scheduling, initial order of instructions:

  A:    ... implicit-def dead $nzcv
  B:    ... implicit-def $nzcv, implicit-def dead $nzcv
  C:    ... implicit-def $nzcv
  D:    ... implicit killed $nzcv    (use)

In the right way, the relationship should look like this after building the sched graph.

  A     B                      
   \   /                   
     C   
     |             
     D

The deps:   **A->C(output dep), **    ** B->C(output dep),**      ** C->D(true dep)**

Unfortunately, when the dependency graph is built, the graph we actually get :

  A     B                      
       /                   
     C   
     |             
     D

The deps:   **A(no any deps with B/C/D) ,    **          **    B->C(output dep),**     **  C->D(true dep),**    so after post-ra scheduling, we may get a wrong result:
**B  C  A  D,  **   A will break the true dependency(C->D)

`buildSchedGraph` function will walk the list of instructions, from bottom moving up.
First, it will build dependency for D and C, C->D(true dep). Then for B, it will have B->C(output dep), we can see the code in `addPhysRegDeps`,

  // Clear previous uses and defs of this register and its subergisters.
  for (MCSubRegIterator SubReg(Reg, TRI, true); SubReg.isValid(); ++SubReg) {
    if (Uses.contains(*SubReg))
      Uses.eraseAll(*SubReg);
    if (!MO.isDead())
      Defs.eraseAll(*SubReg);
  }

because B has an implicit-def $nzcv without `dead`,  Defs list will clear all the previous define insts(C will be cleared). So when checking the dependence for A, it can‘t create output deps with C.
Finally, we can make sure the root cause is, inst B having a redundant implicit-def $nzcv, which is added by expanding pseudo pass.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109069/new/

https://reviews.llvm.org/D109069



More information about the llvm-commits mailing list