[PATCH] [Jump-Threading] Fixed jump threading hang issues (PR15386, PR15851)
Dinesh Dwivedi
dinesh.d at samsung.com
Tue Jun 10 05:12:41 PDT 2014
Hi Rafael,
I have seen BBs getting updated more than once even with my patch. It breaks for the case where some
previously added thread is removed and no new thread is introduced.
I am not sure that after this, there is no more threading possible. What all test cases I had showed similar
pattern and after this condition is true, they got stuck in infinite loop. So I can claim that this condition is
one possible indication that jump threading may struck in infinite loop.
We may change breaking condition to see if no new BB is updated in few consecutive iterations in place of
breaking after first occurrence of the condition.
Regards
Dinesh Dwivedi
------- Original Message -------
Sender : Rafael EspĂndola<rafael.espindola at gmail.com>
Date : Jun 10, 2014 17:29 (GMT+05:30)
Title : Re: [PATCH] [Jump-Threading] Fixed jump threading hang issues
(PR15386, PR15851)
On 10 June 2014 01:53, Dinesh Dwivedi <dinesh.d at samsung.com> wrote:
> Each pass iterates over all BBs of the functions and all updated BBs are added to
> 'UpdatedBB' so if first pass adds 3 BBs and second pass adds 2, there will be
> 5 BBs in the list and we will still continue with next pass.
Oh, sorry. I misread it as being the BB updated in this iteration.
So we are sure that a BB is never profitably updated more than once?
> Every change in BBs actually adds atleast one new block XXX.thread and till it finds
> some new block added or updated, it will do next iteration on all BBs of the function.
> and the condition, that will break this is when we are not adding any new block or not
> updatind any new BB.
>
> In attached test case, jump threading stuck between 'for.cond1' and 'for.body' block.
> Here is sample output for few iterations.
> After first iteration:
> for.cond1: ; preds = %for.body.thread, %for.body, %land.rhs
> %div5 = phi i32 [ 0, %for.body.thread ], [ %div, %for.body ], [ %div, %land.rhs ]
> %inc = add nsw i32 %div5, 1
> %cmp = icmp slt i32 %inc, 2
> br i1 %cmp, label %for.body, label %for.cond1.thread
>
> for.cond1.thread: ; preds = %for.cond1
> br label %for.body.thread
>
> for.body.thread: ; preds = %for.cond1.thread
> br label %for.cond1
>
> for.body: ; preds = %for.cond1
> %i.02 = phi i32 [ %inc, %for.cond1 ]
> %div = sdiv i32 %i.02, 2
> %i.0.off = add i32 %i.02, 1
> %0 = icmp ugt i32 %i.0.off, 2
> br i1 %0, label %land.rhs, label %for.cond1
>
> 2nd:
> for.cond1: ; preds = %for.body.thread, %for.body, %land.rhs
> %div5 = phi i32 [ %div, %for.body ], [ %div, %land.rhs ], [ 0, %for.body.thread ]
> %inc = add nsw i32 %div5, 1
> %cmp = icmp slt i32 %inc, 2
> br i1 %cmp, label %for.body, label %for.cond1.thread6
>
> for.cond1.thread6: ; preds = %for.cond1
> br label %for.body.thread
>
> for.body.thread: ; preds = %for.cond1.thread6
> br label %for.cond1
>
> for.body: ; preds = %for.cond1
> %i.02 = phi i32 [ %inc, %for.cond1 ]
> %div = sdiv i32 %i.02, 2
> %i.0.off = add i32 %i.02, 1
> %0 = icmp ugt i32 %i.0.off, 2
> br i1 %0, label %land.rhs, label %for.cond1
>
> and 3rd:
> for.cond1: ; preds = %for.body.thread, %for.body, %land.rhs
> %div5 = phi i32 [ %div, %for.body ], [ %div, %land.rhs ], [ 0, %for.body.thread ]
> %inc = add nsw i32 %div5, 1
> %cmp = icmp slt i32 %inc, 2
> br i1 %cmp, label %for.body, label %for.cond1.thread
>
> for.cond1.thread: ; preds = %for.cond1
> br label %for.body.thread
>
> for.body.thread: ; preds = %for.cond1.thread
> br label %for.cond1
>
> for.body: ; preds = %for.cond1
> %i.02 = phi i32 [ %inc, %for.cond1 ]
> %div = sdiv i32 %i.02, 2
> %i.0.off = add i32 %i.02, 1
> %0 = icmp ugt i32 %i.0.off, 2
> br i1 %0, label %land.rhs, label %for.cond1
>
> I will update test cases as you suggested. Actually I am not sure about test as
> it hangs with trunk and check-all never completes.
Yes, but the patch fixes that, right? If so it is probably a good idea
to make the test a bit stronger than just "it finishes".
Cheers,
Rafael
More information about the llvm-commits
mailing list