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


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?

A comment in update_ssa says:
   We want to replace all the uses of x_1 with the new definitions of
   x_10 and x_11.

That is exactly what I don't want.
Is there a way to tell gcc that the copy of the bb is already in SSA-form?

Thank you and best regards,
Benedikt

On 17 Mar 2015, at 19:25, Jeff Law <law@redhat.com> wrote:

> 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.
>> ...
>>   <bb 19>:
>>   list_38 = list_10->next;
>>   _22 = list_10->info;
>>   _36 = _22->idx;
>>   if (_5 != _36)
>>     goto <bb 16>;
>>   else
>>     goto <bb 14>;
>> 
>>   <bb 16>:
>>   goto <bb 12>;
>> 
>>   <bb 14>:
>>   # list_13 = PHI <list_6(D)(6), list_34(13), 0B(12), 0B(5), 0B(18), list_10(19)>
>> ...
>> 
>> 
>> Corresponding part of the following pass. (list_join.c.148t.fab1)
>> ..
>> SSA replacement table
>> N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j
>> 
>> _1 -> { _17 }
>> _12 -> { _16 }
>> _14 -> { _18 }
>> _22 -> { _7 }
>> _25 -> { _19 }
>> _36 -> { _8 }
>> list_38 -> { list_10 }
>> list_41 -> { list_15 }
>> _42 -> { _20 }
>> ...
>>   <bb 19>:
>>   list_38 = list_10->next;
>>   _22 = list_38->info;
>>   _36 = _22->idx;
>>   if (_5 != _36)
>>     goto <bb 16>;
>>   else
>>     goto <bb 14>;
>> 
>>   <bb 16>:
>>   goto <bb 12>;
>> 
>>   <bb 14>:
>>   # list_13 = PHI <list_6(D)(6), list_34(13), 0B(12), 0B(5), 0B(18), list_38(19)>
>> ...
>> 
>> As you can see, gcc renames list_10 to list_38 in two places, which is not what I want.
>> Why does gcc think this is possible. It seems to me that I need to update some data structure
>> which I don't know of. What am I missing?
>> I already did an updated_stmt in the places where I edit gimple statements.
>> 
>> If I specify TODO_update_ssa, the same renaming already takes place in my pass.
>> bb 19 is a copy of another basic block, maybe this is of relevance.
> Fundamentally SSA_NAMEs appearing in the graph are allowed only a single static assignment.   Thus if you copy a block all SSA_NAMEs in the block have to go through an SSA update to ensure that each has one and only one single static assignment.
> 
> 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]