On August 27, 2020 7:45:15 PM GMT+02:00, Gary Oblock <g...@amperecomputing.com>
wrote:
>Richard,
>
>>You need to call update_stmt () if you change SSA operands to
>>sth else.
>
>I'm having trouble parsing the "sth else" above. Could you
>please rephrase this if it's important to your point. I take
>what you mean is if you change any SSA operand to any
>statement then update that statement.
If you change any SSA operand of any stmt to a different SSA name or a constant
then you need to update the stmt containing the SSA operand.
In _1 = _2 + 3; _2 is an SSA operand of that stmt.
Richard.
>Thanks,
>
>Gary
>________________________________
>From: Richard Biener <richard.guent...@gmail.com>
>Sent: Thursday, August 27, 2020 2:04 AM
>To: Gary Oblock <g...@amperecomputing.com>
>Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org>
>Subject: Re: Questions regarding update_stmt and release_ssa_name_fn.
>
>[EXTERNAL EMAIL NOTICE: This email originated from an external sender.
>Please be mindful of safe email handling and proprietary information
>protection practices.]
>
>
>On Wed, Aug 26, 2020 at 11:32 PM Gary Oblock via Gcc <gcc@gcc.gnu.org>
>wrote:
>>
>> I'm having some major grief with a few related things that I'm try to
>> do. The mostly revolve around trying to change the type of an SSA
>name
>> (which I've given up in favor of creating new SSA names and replacing
>> the ones I wanted to change.) However, this seems too has its own
>> issues.
>>
>> In one problematic case in particular, I'm seeing a sequence like:
>>
>> foo_3 = mumble_1 op mumble_2
>>
>> bar_5 = foo_3 op baz_4
>>
>> when replace foo_3 with foo_4 the (having the needed new type.)
>>
>> I'm seeing a later verification phase think
>>
>> bar_5 = foo_4 op baz_4
>>
>> is still associated with the foo_3.
>>
>> Should the transformation above be associated with update_stmt and/or
>> release_ssa_name_fn? And if they are both needed is there a proper
>> order required. Note, when I try using them, I'm seeing some
>malformed
>> tree operands that die in horrible ways.
>>
>> By the way, I realize I can probably simply create a new GIMPLE stmt
>> from scratch to replace the ones I'm modifying but this will cause
>> some significant code bloat and I want to avoid that if at all
>> possible.
>
>You need to call update_stmt () if you change SSA operands to
>sth else.
>
>> There is an addition wrinkle to this problem with C code like this
>>
>> void
>> whatever ( int x, .. )
>> {
>> :
>> x++;
>> :
>> }
>>
>> I'm seeing x_2 being thought of as default definition in the
>following
>> GIMPLE stmt when it's clearly not since it's defined by the
>statement.
>>
>> x_2 = X_1 + 4
>>
>> My approach has been to simply make the SSA name to replace x_2a
>> normal SSA name and not a default def. Is this not reasonable and
>> correct?
>
>If x_2 is a default def then the IL isn't correct in the first place.
>I doubt
>it is that way, btw. - we have verifiers that would blow up if it
>would.
>
>Richard.
>
>>
>> Thanks,
>>
>> Gary Oblock
>>
>> Gary
>>
>>
>>
>>
>>
>> CONFIDENTIALITY NOTICE: This e-mail message, including any
>attachments, is for the sole use of the intended recipient(s) and
>contains information that is confidential and proprietary to Ampere
>Computing or its subsidiaries. It is to be used solely for the purpose
>of furthering the parties' business relationship. Any unauthorized
>review, copying, or distribution of this email (or any attachments
>thereto) is strictly prohibited. If you are not the intended recipient,
>please contact the sender immediately and permanently delete the
>original and any copies of this email and any attachments thereto.
