Chris Lattner
eede65ce6c
Don't infininitely thread branches when a threaded edge
...
goes back to the block, e.g.:
Threading edge through bool from 'bb37.us.thread3829' to 'bb37.us' with cost: 1, across block:
bb37.us: ; preds = %bb37.us.thread3829, %bb37.us, %bb33
%D1361.1.us = phi i32 [ %tmp36, %bb33 ], [ %D1361.1.us, %bb37.us ], [ 0, %bb37.us.thread3829 ] ; <i32> [#uses=2]
%tmp39.us = icmp eq i32 %D1361.1.us, 0 ; <i1> [#uses=1]
br i1 %tmp39.us, label %bb37.us, label %bb42.us
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@50251 91177308-0d34-0410-b5e6-96231b3b80d8
2008-04-25 04:12:29 +00:00
Chris Lattner
a5ddb59a13
Start doing the significantly useful part of jump threading: handle cases
...
where a comparison has a phi input and that phi is a constant. For example,
stuff like:
Threading edge through bool from 'bb2149' to 'bb2231' with cost: 1, across block:
bb2237: ; preds = %bb2231, %bb2149
%tmp2328.rle = phi i32 [ %tmp2232, %bb2231 ], [ %tmp2232439, %bb2149 ] ; <i32> [#uses=2]
%done.0 = phi i32 [ %done.2, %bb2231 ], [ 0, %bb2149 ] ; <i32> [#uses=1]
%tmp2239 = icmp eq i32 %done.0, 0 ; <i1> [#uses=1]
br i1 %tmp2239, label %bb2231, label %bb2327
or
bb38.i298: ; preds = %bb33.i295, %bb1693
%tmp39.i296.rle = phi %struct.ibox* [ null, %bb1693 ], [ %tmp39.i296.rle1109, %bb33.i295 ] ; <%struct.ibox*> [#uses=2]
%minspan.1.i291.reg2mem.1 = phi i32 [ 32000, %bb1693 ], [ %minspan.0.i288, %bb33.i295 ] ; <i32> [#uses=1]
%tmp40.i297 = icmp eq %struct.ibox* %tmp39.i296.rle, null ; <i1> [#uses=1]
br i1 %tmp40.i297, label %implfeeds.exit311, label %bb43.i301
This triggers thousands of times in spec.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@50110 91177308-0d34-0410-b5e6-96231b3b80d8
2008-04-22 21:40:39 +00:00
Chris Lattner
6bf77500c6
Teach jump threading to thread through blocks like:
...
br (and X, phi(Y, Z, false)), label L1, label L2
This triggers once on 252.eon and 6 times on 176.gcc. Blocks
in question often look like this:
bb262: ; preds = %bb261, %bb248
%iftmp.251.0 = phi i1 [ true, %bb261 ], [ false, %bb248 ] ; <i1> [#uses=4]
%tmp270 = icmp eq %struct.rtx_def* %tmp.0.i, null ; <i1> [#uses=1]
%bothcond = or i1 %iftmp.251.0, %tmp270 ; <i1> [#uses=1]
br i1 %bothcond, label %bb288, label %bb273
In this case, it is clear that it doesn't matter if tmp.0.i is null when coming from bb261. When coming from bb248, it is all that matters.
Another random example:
check_asm_operands.exit: ; preds = %check_asm_operands.exit.thr_comm, %bb30.i, %bb12.i, %bb6.i413
%tmp.0.i420 = phi i1 [ true, %bb6.i413 ], [ true, %bb12.i ], [ true, %bb30.i ], [ false, %check_asm_operands.exit.thr_comm ; <i1> [#uses=1]
call void @llvm.stackrestore( i8* %savedstack ) nounwind
%tmp4389 = icmp eq i32 %added_sets_1.0, 0 ; <i1> [#uses=1]
%tmp4394 = icmp eq i32 %added_sets_2.0, 0 ; <i1> [#uses=1]
%bothcond80 = and i1 %tmp4389, %tmp4394 ; <i1> [#uses=1]
%bothcond81 = and i1 %bothcond80, %tmp.0.i420 ; <i1> [#uses=1]
br i1 %bothcond81, label %bb4398, label %bb4397
Here is the case from 252.eon:
bb290.i.i: ; preds = %bb23.i57.i.i, %bb8.i39.i.i, %bb100.i.i, %bb100.i.i, %bb85.i.i110
%myEOF.1.i.i = phi i1 [ true, %bb100.i.i ], [ true, %bb100.i.i ], [ true, %bb85.i.i110 ], [ true, %bb8.i39.i.i ], [ false, %bb23.i57.i.i ] ; <i1> [#uses=2]
%i.4.i.i = phi i32 [ %i.1.i.i, %bb85.i.i110 ], [ %i.0.i.i, %bb100.i.i ], [ %i.0.i.i, %bb100.i.i ], [ %i.3.i.i, %bb8.i39.i.i ], [ %i.3.i.i, %bb23.i57.i.i ] ; <i32> [#uses=3]
%tmp292.i.i = load i8* %tmp16.i.i100, align 1 ; <i8> [#uses=1]
%tmp293.not.i.i = icmp ne i8 %tmp292.i.i, 0 ; <i1> [#uses=1]
%bothcond.i.i = and i1 %tmp293.not.i.i, %myEOF.1.i.i ; <i1> [#uses=1]
br i1 %bothcond.i.i, label %bb202.i.i, label %bb301.i.i
Factoring out 3 common predecessors.
On the path from any blocks other than bb23.i57.i.i, the load and compare
are dead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@50096 91177308-0d34-0410-b5e6-96231b3b80d8
2008-04-22 07:05:46 +00:00
