[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