Page MenuHomePhabricator

[POC Only] Demonstration of approach to undo exit value rewriting
Needs ReviewPublic

Authored by reames on Aug 19 2019, 3:59 PM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

Not for review.

Just to demonstrate what one example approach might look like.
target datalayout = "n8:16:32:64"
define i32 @test2(i32 %n) {
entry:

br label %loop

loop:

%iv = phi i32 [0, %entry], [%iv.next, %loop]
%iv.next = add i32 %iv, 1
%cmp = icmp ult i32 %iv, %n
br i1 %cmp, label %loop, label %exit

exit:

ret i32 %n ;; rewrites this to %iv

}

The hard part is figuring out the right heuristic here.

Diff Detail

Event Timeline

reames created this revision.Aug 19 2019, 3:59 PM

Thanks for submitting this. It's good to see different approaches.

lib/Transforms/Scalar/ReuseLoopExitValues.cpp
110

Is the "loop context" really needed for expressions? Aren't dominance checks done later sufficient to know whether it's legal to replace one value with another or not?

135

I'm not sure why this dominance check is used. We are searching for the candidate to replace U.get(), Isn't it enough for DefI to dominate U.get()? Currently, this check prevents from replacing uses in phis which are common.

144

Won't this function always return U.get()? Any original ExitValue would always dominate it's rewritten form, if I'm not mistaken.

163

I had to add some type checks here (or create bitcasts) to prevent asserts.

danilaml added inline comments.Tue, Aug 27, 6:09 AM
lib/Transforms/Scalar/ReuseLoopExitValues.cpp
110

Nevermind. I relized that it's likely unavoidable for loops consisting of several BBs.