This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Unintended variable renaming in SSA replacement table


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 <law@redhat.com> wrote:

> 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.
>> What I do not understand is: Why does gcc change the names on the rhs?
> Because uses that are reached by the new names obviously have to get updated.  The SSA updater is supposed to relieve passes from the burden of trying to figure out how to handle updates on their own.  You copy the blocks, update your cfg, remove unreachables, then let the ssa updater handle updating the ssa graph.
> 
> If you're using the block copier, but doing your own updates, then you'll need some kind of hack to avoid the standard update mechanisms. I'm not immediately aware of a "blessed" way to do that.  You'll need to hack somethign up.
> 
> jeff
> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]