Re: Unintended variable renaming in SSA replacement table

2015-03-18 Thread Benedikt Huber
Thnaks to your explanation I found a way to do it: 1) Duplicate the blocks 2) Fix cfg, phis, and dominators 3) manually call update_ssa 4) Edit rhs uses By doing 4) after 3) subsequent calls to update_ssa, do not alter the operands anymore. On 17 Mar 2015, at 20:10, Jeff Law wrote: > On 03/17

Re: Unintended variable renaming in SSA replacement table

2015-03-17 Thread Jeff Law
On 03/17/2015 12:54 PM, Benedikt Huber wrote: Thank you for the answer. I made sure that each variable is only assigned exactly once. duplicate_block already generates new names for all lhs. After that I edited all rhs to the uses I wanted for the unrolling, so SSA-form should still be intact. Wh

Re: Unintended variable renaming in SSA replacement table

2015-03-17 Thread Benedikt Huber
Thank you for the answer. I made sure that each variable is only assigned exactly once. duplicate_block already generates new names for all lhs. After that I edited all rhs to the uses I wanted for the unrolling, so SSA-form should still be intact. What I do not understand is: Why does gcc change t

Re: Unintended variable renaming in SSA replacement table

2015-03-17 Thread Jeff Law
On 03/17/2015 06:32 AM, Benedikt Huber wrote: Hi, I have a problem with a transformation pass I wrote. The pass is meant to pipeline and unroll lookups in linked lists. After my pass is run, gcc renames a variable, which leads to wrong results. Part of my pass's dump, which is as I want it. ..