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. >
