Re: Moving statements from one BB to other BB.
On Fri, Apr 18, 2008 at 9:34 AM, Sandeep Maram <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Consider the 2 for loops given below.
>
> for (i = 0; i < N ; i++)
> {
> a[i]= 1;
> }
>
> for (i = 0; i < N ; i++)
> {
> j = j+a[i];
> }
>
> The headers of these 2 loops are bb_3, bb_6 respectively. They are as
> follows.
>
> bb_3 (preds = {bb_4 bb_2 }, succs = {bb_4 bb_5 })
> {
> :
> # a_27 = PHI
> # i_24 = PHI
> # a_18 = VDEF { a }
> a[i_24] = 1;
> i_7 = i_24 + 1;
> if (i_7 <= 999)
> goto ;
> else
> goto ;
>
> }
>
> bb_6 (preds = {bb_5 bb_7 }, succs = {bb_7 bb_8 })
> {
> :
> # j_26 = PHI <0(5), j_12(7)>
> # i_25 = PHI <0(5), i_13(7)>
> # VUSE { a }
>
> D.1189_10 = a[i_25];
> D.1190_11 = (unsigned int) D.1189_10;
> j_12 = D.1190_11 + j_26;
> i_13 = i_25 + 1;
> if (i_13 <= 999)
> goto ;
> else
> goto ;
>
> }
>
> I am transfering statements from bb_6 to bb_3 using code -
>
> for (bsi = bsi_start (loop_a->header); !bsi_end_p (bsi);)
> {
> if ((TREE_CODE (bsi_stmt (bsi)) != LABEL_EXPR) && (TREE_CODE
> (bsi_stmt (bsi)) != COND_EXPR))
>{
> bsi_move_before (&bsi, &bsi_b_last);
>}
> else
>{
> bsi_next (&bsi);
>}
> }
>
> After this the two BBs look like -
>
> bb_6 (preds = {bb_5 bb_7 }, succs = {bb_7 bb_8 })
> {
> :
> # j_26 = PHI <0(5), j_12(7)>
> # i_25 = PHI <0(5), i_13(7)>
> if (i_13 <= 999)
> goto ;
> else
> goto ;
>
> }
>
> bb_3 (preds = {bb_4 bb_2 }, succs = {bb_4 bb_5 })
> {
> :
> # a_27 = PHI
> # i_24 = PHI
> # a_18 = VDEF { a }
> a[i_24] = 1;
> # VUSE { a }
>
> D.1189_10 = a[i_25];
> D.1190_11 = (unsigned int) D.1189_10;
> j_12 = D.1190_11 + j_26;
> i_13 = i_25 + 1;
> i_7 = i_24 + 1;
> if (i_7 <= 999)
> goto ;
> else
> goto ;
>
> }
>
> The iterator variables for the 2 loops are i_24, i_25 respectively. So
> when the statements are transferred, there is a problem with i_25 in
> bb_3 . How can I change the name of i_25 to i_24 ?
You can for example add a copy instruction
i_25 = i_24
at the top of the new loop (but you have to remove the existing definition
for i_25 in the old loop then). Otherwise you can change and walk
operands of trees using the immediate use iterators and SET_USE.
Just grep for it and you'll find example uses.
Richard.
Re: Moving statements from one BB to other BB.
Hi,
Consider the 2 for loops given below.
for (i = 0; i < N ; i++)
{
a[i]= 1;
}
for (i = 0; i < N ; i++)
{
j = j+a[i];
}
The headers of these 2 loops are bb_3, bb_6 respectively. They are as follows.
bb_3 (preds = {bb_4 bb_2 }, succs = {bb_4 bb_5 })
{
:
# a_27 = PHI
# i_24 = PHI
# a_18 = VDEF { a }
a[i_24] = 1;
i_7 = i_24 + 1;
if (i_7 <= 999)
goto ;
else
goto ;
}
bb_6 (preds = {bb_5 bb_7 }, succs = {bb_7 bb_8 })
{
:
# j_26 = PHI <0(5), j_12(7)>
# i_25 = PHI <0(5), i_13(7)>
# VUSE { a }
D.1189_10 = a[i_25];
D.1190_11 = (unsigned int) D.1189_10;
j_12 = D.1190_11 + j_26;
i_13 = i_25 + 1;
if (i_13 <= 999)
goto ;
else
goto ;
}
I am transfering statements from bb_6 to bb_3 using code -
for (bsi = bsi_start (loop_a->header); !bsi_end_p (bsi);)
{
if ((TREE_CODE (bsi_stmt (bsi)) != LABEL_EXPR) && (TREE_CODE
(bsi_stmt (bsi)) != COND_EXPR))
{
bsi_move_before (&bsi, &bsi_b_last);
}
else
{
bsi_next (&bsi);
}
}
After this the two BBs look like -
bb_6 (preds = {bb_5 bb_7 }, succs = {bb_7 bb_8 })
{
:
# j_26 = PHI <0(5), j_12(7)>
# i_25 = PHI <0(5), i_13(7)>
if (i_13 <= 999)
goto ;
else
goto ;
}
bb_3 (preds = {bb_4 bb_2 }, succs = {bb_4 bb_5 })
{
:
# a_27 = PHI
# i_24 = PHI
# a_18 = VDEF { a }
a[i_24] = 1;
# VUSE { a }
D.1189_10 = a[i_25];
D.1190_11 = (unsigned int) D.1189_10;
j_12 = D.1190_11 + j_26;
i_13 = i_25 + 1;
i_7 = i_24 + 1;
if (i_7 <= 999)
goto ;
else
goto ;
}
The iterator variables for the 2 loops are i_24, i_25 respectively. So
when the statements are transferred, there is a problem with i_25 in
bb_3 . How can I change the name of i_25 to i_24 ?
Thanks,
Sandeep.
Re: Moving statements from one BB to other BB.
On Thu, Apr 17, 2008 at 5:20 PM, Richard Guenther <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 17, 2008 at 1:35 PM, Sandeep Maram <[EMAIL PROTECTED]> wrote: > > > > On Tue, Apr 15, 2008 at 3:00 PM, Richard Guenther > > <[EMAIL PROTECTED]> wrote: > > > > > > On Tue, Apr 15, 2008 at 7:49 AM, Sandeep Maram <[EMAIL PROTECTED]> > wrote: > > > > On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin <[EMAIL PROTECTED]> > wrote: > > > > > To clarify what Richard means, your assertion that "you have > updated > > > > > SSA information" is false. > > > > > If you had updated the SSA information, the error would not > occur :). > > > > > > > > > > How exactly are you updating the ssa information? > > > > > > > > I am calling update_ssa (TODO_update_ssa), after all the statements > > > > are transferred. > > > > > > > > > > > > > > > > > > The general way to update SSA for this case would be: > > > > > > > > > > For each statement you have moved: > > > > > Call update_stmt (t); > > > > > > > > > > Then call update_ssa (TODO_update_ssa) (or instead use > > > > > rewrite_into_loop_closed_ssa if this is a loop pass). > > > > > > > > > > If you do not call update_stmt in this case, update_ssa won't > actually > > > > > do anything. > > > > > > > > > > Diego, the bsi iterators do not update the statements for you > though > > > > > it is not clear if this is a bug or not. > > > > > > > > > > The bsi iterators call update_modified_stmts, which says: > > > > > > > > > > /* Mark statement T as modified, and update it. */ > > > > > static inline void > > > > > update_modified_stmts (tree t) > > > > > > > > > > However, this only calls update_stmt_if_modified (IE it does not > mark > > > > > the statement as modified and update it, as it claims to). > > > > > > > > > > Sandeep, it should also suffice to call mark_stmt_modified > *before* > > > > > moving the statements (since the above routine should then update > > > > > them). > > > > > > > > > > > > > Thanks. I will use update_stmt, update_ssa now. > > > > > > You need to do more than that - you appearantly are moving uses of > > > SSA names to a place where its definition is not available like if you > do > > > > > > b_1 = 1; > > > a_1 = b_1 + 1; > > > > > > and transform this to > > > > > > a_1 = b_1 + 1; > > > b_1 = 1; > > > > > > which obviously cannot work. So "updating" SSA form won't help you > > > and renaming the symbols will only make the verifier happy and leave > > > you with wrong code. > > > > > > So you need to investigate what exactly you are doing wrong with > > > your stmt movement. > > > > I am considering two consequent fusible loops. These loops have a > > single header and a single latch. I want to move the statements in > > the header of the second loop to the header of the first loop. This > > function will be called only after certain constraints are met. That > > is legality test is performed before fusing these loops. > > > > I think I am transfering all the statements inside the loop correctly. > > But I am doing some mistake with the "iterator variable". > > Well, we cannot do mind-reading here to figure out what exactly you > do wrong. Please have a look at the tree-dumps before and after > your transformation (-fdump-tree-all-vops), this should obviously > explain what is going wrong. I suppose you simply forgot about > PHI nodes. Thank you. Regards, Sandeep. > > Richard. >
Re: Moving statements from one BB to other BB.
On Thu, Apr 17, 2008 at 1:35 PM, Sandeep Maram <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 15, 2008 at 3:00 PM, Richard Guenther > <[EMAIL PROTECTED]> wrote: > > > > On Tue, Apr 15, 2008 at 7:49 AM, Sandeep Maram <[EMAIL PROTECTED]> wrote: > > > On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin <[EMAIL PROTECTED]> > wrote: > > > > To clarify what Richard means, your assertion that "you have updated > > > > SSA information" is false. > > > > If you had updated the SSA information, the error would not occur > :). > > > > > > > > How exactly are you updating the ssa information? > > > > > > I am calling update_ssa (TODO_update_ssa), after all the statements > > > are transferred. > > > > > > > > > > > > > > The general way to update SSA for this case would be: > > > > > > > > For each statement you have moved: > > > > Call update_stmt (t); > > > > > > > > Then call update_ssa (TODO_update_ssa) (or instead use > > > > rewrite_into_loop_closed_ssa if this is a loop pass). > > > > > > > > If you do not call update_stmt in this case, update_ssa won't > actually > > > > do anything. > > > > > > > > Diego, the bsi iterators do not update the statements for you though > > > > it is not clear if this is a bug or not. > > > > > > > > The bsi iterators call update_modified_stmts, which says: > > > > > > > > /* Mark statement T as modified, and update it. */ > > > > static inline void > > > > update_modified_stmts (tree t) > > > > > > > > However, this only calls update_stmt_if_modified (IE it does not > mark > > > > the statement as modified and update it, as it claims to). > > > > > > > > Sandeep, it should also suffice to call mark_stmt_modified *before* > > > > moving the statements (since the above routine should then update > > > > them). > > > > > > > > > > Thanks. I will use update_stmt, update_ssa now. > > > > You need to do more than that - you appearantly are moving uses of > > SSA names to a place where its definition is not available like if you do > > > > b_1 = 1; > > a_1 = b_1 + 1; > > > > and transform this to > > > > a_1 = b_1 + 1; > > b_1 = 1; > > > > which obviously cannot work. So "updating" SSA form won't help you > > and renaming the symbols will only make the verifier happy and leave > > you with wrong code. > > > > So you need to investigate what exactly you are doing wrong with > > your stmt movement. > > I am considering two consequent fusible loops. These loops have a > single header and a single latch. I want to move the statements in > the header of the second loop to the header of the first loop. This > function will be called only after certain constraints are met. That > is legality test is performed before fusing these loops. > > I think I am transfering all the statements inside the loop correctly. > But I am doing some mistake with the "iterator variable". Well, we cannot do mind-reading here to figure out what exactly you do wrong. Please have a look at the tree-dumps before and after your transformation (-fdump-tree-all-vops), this should obviously explain what is going wrong. I suppose you simply forgot about PHI nodes. Richard.
Re: Moving statements from one BB to other BB.
On Tue, Apr 15, 2008 at 3:00 PM, Richard Guenther <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 15, 2008 at 7:49 AM, Sandeep Maram <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > > To clarify what Richard means, your assertion that "you have updated > > > SSA information" is false. > > > If you had updated the SSA information, the error would not occur :). > > > > > > How exactly are you updating the ssa information? > > > > I am calling update_ssa (TODO_update_ssa), after all the statements > > are transferred. > > > > > > > > > > The general way to update SSA for this case would be: > > > > > > For each statement you have moved: > > > Call update_stmt (t); > > > > > > Then call update_ssa (TODO_update_ssa) (or instead use > > > rewrite_into_loop_closed_ssa if this is a loop pass). > > > > > > If you do not call update_stmt in this case, update_ssa won't actually > > > do anything. > > > > > > Diego, the bsi iterators do not update the statements for you though > > > it is not clear if this is a bug or not. > > > > > > The bsi iterators call update_modified_stmts, which says: > > > > > > /* Mark statement T as modified, and update it. */ > > > static inline void > > > update_modified_stmts (tree t) > > > > > > However, this only calls update_stmt_if_modified (IE it does not mark > > > the statement as modified and update it, as it claims to). > > > > > > Sandeep, it should also suffice to call mark_stmt_modified *before* > > > moving the statements (since the above routine should then update > > > them). > > > > > > > Thanks. I will use update_stmt, update_ssa now. > > You need to do more than that - you appearantly are moving uses of > SSA names to a place where its definition is not available like if you do > > b_1 = 1; > a_1 = b_1 + 1; > > and transform this to > > a_1 = b_1 + 1; > b_1 = 1; > > which obviously cannot work. So "updating" SSA form won't help you > and renaming the symbols will only make the verifier happy and leave > you with wrong code. > > So you need to investigate what exactly you are doing wrong with > your stmt movement. I am considering two consequent fusible loops. These loops have a single header and a single latch. I want to move the statements in the header of the second loop to the header of the first loop. This function will be called only after certain constraints are met. That is legality test is performed before fusing these loops. I think I am transfering all the statements inside the loop correctly. But I am doing some mistake with the "iterator variable". Thanks, Sandeep. > > Richard. >
Re: Moving statements from one BB to other BB.
On Tue, Apr 15, 2008 at 11:40 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > > On 4/15/08 1:34 PM, Zdenek Dvorak wrote: > > > Hi, > > > > > > > > > > > > To clarify what Richard means, your assertion that "you have > updated > > > > > SSA information" is false. > > > > > If you had updated the SSA information, the error would not occur > :). > > > > > > > > > > How exactly are you updating the ssa information? > > > > > > > > > > The general way to update SSA for this case would be: > > > > > > > > > > For each statement you have moved: > > > > > Call update_stmt (t); > > > > > > > > > > Then call update_ssa (TODO_update_ssa) (or instead use > > > > > rewrite_into_loop_closed_ssa if this is a loop pass). > > > > > > > > > > If you do not call update_stmt in this case, update_ssa won't > actually > > > > > do anything. > > > > > > > > actually, it will not do anything even if he calls update_stmt, as > the > > > > statements that he is moving are already in ssa form, so update_stmt > > > > will not mark anything for renaming. > > > > > > > > > > > You are partially right (and right where it matters, that it won't fix > > > the problem) > > > That said, update_stmt on ssa form statements will at least reset the > > > vuse/vdef back to original variables for renaming. > > > > > > > I don't think so; as long as you do not introduce new vops (which you > > should not by just moving the statements), update_stmt is a no-op on > > vops too (unless something has changed since the last time I needed > > this), > > > > Right. Moving statements in SSA form needs to introduce name->name > mappings (eg, as is done during loop unrolling). > Yes, calling update_stmt for evry transfer and then calling update_ssa later, didn't work. From the discussions, I understood that I have to change the SSA names in the statements to be transfered, to the corresponding SSA names in the destination block. Can you please tell me , whether there are any functions that manipulate the SSA names ? Thanks, Sandeep. > > Diego. >
Re: Moving statements from one BB to other BB.
On 4/15/08 1:34 PM, Zdenek Dvorak wrote: Hi, > To clarify what Richard means, your assertion that "you have updated > SSA information" is false. > If you had updated the SSA information, the error would not occur :). > > How exactly are you updating the ssa information? > > The general way to update SSA for this case would be: > > For each statement you have moved: > Call update_stmt (t); > > Then call update_ssa (TODO_update_ssa) (or instead use > rewrite_into_loop_closed_ssa if this is a loop pass). > > If you do not call update_stmt in this case, update_ssa won't actually > do anything. actually, it will not do anything even if he calls update_stmt, as the statements that he is moving are already in ssa form, so update_stmt will not mark anything for renaming. You are partially right (and right where it matters, that it won't fix the problem) That said, update_stmt on ssa form statements will at least reset the vuse/vdef back to original variables for renaming. I don't think so; as long as you do not introduce new vops (which you should not by just moving the statements), update_stmt is a no-op on vops too (unless something has changed since the last time I needed this), Right. Moving statements in SSA form needs to introduce name->name mappings (eg, as is done during loop unrolling). Diego.
Re: Moving statements from one BB to other BB.
Hi, > > > To clarify what Richard means, your assertion that "you have updated > > > SSA information" is false. > > > If you had updated the SSA information, the error would not occur :). > > > > > > How exactly are you updating the ssa information? > > > > > > The general way to update SSA for this case would be: > > > > > > For each statement you have moved: > > > Call update_stmt (t); > > > > > > Then call update_ssa (TODO_update_ssa) (or instead use > > > rewrite_into_loop_closed_ssa if this is a loop pass). > > > > > > If you do not call update_stmt in this case, update_ssa won't actually > > > do anything. > > > > actually, it will not do anything even if he calls update_stmt, as the > > statements that he is moving are already in ssa form, so update_stmt > > will not mark anything for renaming. > > > You are partially right (and right where it matters, that it won't fix > the problem) > That said, update_stmt on ssa form statements will at least reset the > vuse/vdef back to original variables for renaming. I don't think so; as long as you do not introduce new vops (which you should not by just moving the statements), update_stmt is a no-op on vops too (unless something has changed since the last time I needed this), Zdenek
Re: Moving statements from one BB to other BB.
On Tue, Apr 15, 2008 at 8:05 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: > Hi, > > > > To clarify what Richard means, your assertion that "you have updated > > SSA information" is false. > > If you had updated the SSA information, the error would not occur :). > > > > How exactly are you updating the ssa information? > > > > The general way to update SSA for this case would be: > > > > For each statement you have moved: > > Call update_stmt (t); > > > > Then call update_ssa (TODO_update_ssa) (or instead use > > rewrite_into_loop_closed_ssa if this is a loop pass). > > > > If you do not call update_stmt in this case, update_ssa won't actually > > do anything. > > actually, it will not do anything even if he calls update_stmt, as the > statements that he is moving are already in ssa form, so update_stmt > will not mark anything for renaming. > You are partially right (and right where it matters, that it won't fix the problem) That said, update_stmt on ssa form statements will at least reset the vuse/vdef back to original variables for renaming. Or at least that is my recollection
Re: Moving statements from one BB to other BB.
Hi, > To clarify what Richard means, your assertion that "you have updated > SSA information" is false. > If you had updated the SSA information, the error would not occur :). > > How exactly are you updating the ssa information? > > The general way to update SSA for this case would be: > > For each statement you have moved: > Call update_stmt (t); > > Then call update_ssa (TODO_update_ssa) (or instead use > rewrite_into_loop_closed_ssa if this is a loop pass). > > If you do not call update_stmt in this case, update_ssa won't actually > do anything. actually, it will not do anything even if he calls update_stmt, as the statements that he is moving are already in ssa form, so update_stmt will not mark anything for renaming. IIRC what he tries to do is loop fusion, and according to the error message that he gets, he probably needs to add the calculations of the induction variable(s) of the original loop to the new one, and replace their uses (or maybe just move phi nodes), Zdenek
Re: Moving statements from one BB to other BB.
On Tue, Apr 15, 2008 at 7:49 AM, Sandeep Maram <[EMAIL PROTECTED]> wrote: > On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > To clarify what Richard means, your assertion that "you have updated > > SSA information" is false. > > If you had updated the SSA information, the error would not occur :). > > > > How exactly are you updating the ssa information? > > I am calling update_ssa (TODO_update_ssa), after all the statements > are transferred. > > > > > > The general way to update SSA for this case would be: > > > > For each statement you have moved: > > Call update_stmt (t); > > > > Then call update_ssa (TODO_update_ssa) (or instead use > > rewrite_into_loop_closed_ssa if this is a loop pass). > > > > If you do not call update_stmt in this case, update_ssa won't actually > > do anything. > > > > Diego, the bsi iterators do not update the statements for you though > > it is not clear if this is a bug or not. > > > > The bsi iterators call update_modified_stmts, which says: > > > > /* Mark statement T as modified, and update it. */ > > static inline void > > update_modified_stmts (tree t) > > > > However, this only calls update_stmt_if_modified (IE it does not mark > > the statement as modified and update it, as it claims to). > > > > Sandeep, it should also suffice to call mark_stmt_modified *before* > > moving the statements (since the above routine should then update > > them). > > > > Thanks. I will use update_stmt, update_ssa now. You need to do more than that - you appearantly are moving uses of SSA names to a place where its definition is not available like if you do b_1 = 1; a_1 = b_1 + 1; and transform this to a_1 = b_1 + 1; b_1 = 1; which obviously cannot work. So "updating" SSA form won't help you and renaming the symbols will only make the verifier happy and leave you with wrong code. So you need to investigate what exactly you are doing wrong with your stmt movement. Richard.
Re: Moving statements from one BB to other BB.
On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote: > To clarify what Richard means, your assertion that "you have updated > SSA information" is false. > If you had updated the SSA information, the error would not occur :). > > How exactly are you updating the ssa information? I am calling update_ssa (TODO_update_ssa), after all the statements are transferred. > > The general way to update SSA for this case would be: > > For each statement you have moved: > Call update_stmt (t); > > Then call update_ssa (TODO_update_ssa) (or instead use > rewrite_into_loop_closed_ssa if this is a loop pass). > > If you do not call update_stmt in this case, update_ssa won't actually > do anything. > > Diego, the bsi iterators do not update the statements for you though > it is not clear if this is a bug or not. > > The bsi iterators call update_modified_stmts, which says: > > /* Mark statement T as modified, and update it. */ > static inline void > update_modified_stmts (tree t) > > However, this only calls update_stmt_if_modified (IE it does not mark > the statement as modified and update it, as it claims to). > > Sandeep, it should also suffice to call mark_stmt_modified *before* > moving the statements (since the above routine should then update > them). > Thanks. I will use update_stmt, update_ssa now. Best Regards, Sandeep. > On Mon, Apr 14, 2008 at 7:10 AM, Richard Guenther > > <[EMAIL PROTECTED]> wrote: > > > > On Mon, Apr 14, 2008 at 12:54 PM, Sandeep Maram <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I have transferred all the statements of one BB( header of one loop) > > > to another BB. After that I have updated SSA information too. > > > But I get this error- > > > > > > definition in block 6 does not dominate use in block 3 > > > for SSA_NAME: i_25 in statement: > > > > This is the problem. > > > > > > > > > # VUSE > > > D.1189_10 = a[i_25]; > > > loop.c:8: internal compiler error: verify_ssa failed > > > > > > Can any one please tell me what is the problem? > > > > > > Thanks, > > > Sandeep. > > > > > >
Re: Moving statements from one BB to other BB.
To clarify what Richard means, your assertion that "you have updated SSA information" is false. If you had updated the SSA information, the error would not occur :). How exactly are you updating the ssa information? The general way to update SSA for this case would be: For each statement you have moved: Call update_stmt (t); Then call update_ssa (TODO_update_ssa) (or instead use rewrite_into_loop_closed_ssa if this is a loop pass). If you do not call update_stmt in this case, update_ssa won't actually do anything. Diego, the bsi iterators do not update the statements for you though it is not clear if this is a bug or not. The bsi iterators call update_modified_stmts, which says: /* Mark statement T as modified, and update it. */ static inline void update_modified_stmts (tree t) However, this only calls update_stmt_if_modified (IE it does not mark the statement as modified and update it, as it claims to). Sandeep, it should also suffice to call mark_stmt_modified *before* moving the statements (since the above routine should then update them). On Mon, Apr 14, 2008 at 7:10 AM, Richard Guenther <[EMAIL PROTECTED]> wrote: > On Mon, Apr 14, 2008 at 12:54 PM, Sandeep Maram <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I have transferred all the statements of one BB( header of one loop) > > to another BB. After that I have updated SSA information too. > > But I get this error- > > > > definition in block 6 does not dominate use in block 3 > > for SSA_NAME: i_25 in statement: > > This is the problem. > > > > > # VUSE > > D.1189_10 = a[i_25]; > > loop.c:8: internal compiler error: verify_ssa failed > > > > Can any one please tell me what is the problem? > > > > Thanks, > > Sandeep. > > >
Re: Moving statements from one BB to other BB.
On Mon, Apr 14, 2008 at 12:54 PM, Sandeep Maram <[EMAIL PROTECTED]> wrote: > Hi, > > I have transferred all the statements of one BB( header of one loop) > to another BB. After that I have updated SSA information too. > But I get this error- > > definition in block 6 does not dominate use in block 3 > for SSA_NAME: i_25 in statement: This is the problem. > # VUSE > D.1189_10 = a[i_25]; > loop.c:8: internal compiler error: verify_ssa failed > > Can any one please tell me what is the problem? > > Thanks, > Sandeep. >
Moving statements from one BB to other BB.
Hi, I have transferred all the statements of one BB( header of one loop) to another BB. After that I have updated SSA information too. But I get this error- definition in block 6 does not dominate use in block 3 for SSA_NAME: i_25 in statement: # VUSE D.1189_10 = a[i_25]; loop.c:8: internal compiler error: verify_ssa failed Can any one please tell me what is the problem? Thanks, Sandeep.
