[PATCH] D29014: [SelDag] Implement FREEZE node

Juneyoung Lee via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Oct 27 12:35:25 PDT 2019


aqjune added a comment.

I was looking through MachineInstr's optimizations to recheck validity of using IMPLICIT_DEF, and found that it caused problems at two cases.

1. When a function call is involved, its value is not preserved.

  define i32 @foo()
    %y1 = freeze i32 undef
    %k = add i32 %y1, 10
    call i32 @g()
    %k2 = add i32 %y1, 20
    ..

->

  _foo:
    addl  $10, %ebx
    callq _g
    addl  $20, %eax <- this is wrong because %eax and %ebx may differ
    ..



2. When PHI node is involved, it is folded into an incorrect value.

    br i1 %cond, label %BB1, label %BB2
  BB1:
    %y1 = freeze i32 undef
    %k1 = sub i32 %y1, 1
    br label %END
  BB2:
    %y2 = freeze i32 undef
    br label %END
  END:
    %p = phi i32 [%y1, %BB1], [%y2, %BB2]
    %p2 = phi i32 [%k1, %BB1], [0, %BB2]
    store i32 %p, i32* @x
    store i32 %p2, i32* @y

->

  LBB0_3:                                 ## %END
    movl  %eax, _x(%rip)
    movl  %eax, _y(%rip) <- should be "%eax - 1" if %cond is true

But, other than these two (function call and phi), other operations seemed okay.
Arithmetic operations including add / mul didn't fold IMPLICIT_DEF in a undef-like way.

What would be a good way to address the two cases?
The latter seemed to be done by ProcessImplicitDefs.cpp / PHIElimination.cpp. The former one seems more complicated; it seems to require preservation of information about the original IMPLICIT_DEF before it is removed by later pipeline.


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

https://reviews.llvm.org/D29014





More information about the llvm-commits mailing list