> On Nov 30, 2021, at 2:37 AM, Richard Biener <richard.guent...@gmail.com>
> wrote:
>
> On Mon, Nov 29, 2021 at 11:56 PM Qing Zhao <qing.z...@oracle.com> wrote:
>>
>> Peter,
>>
>> Thanks a lot for the patch.
>>
>> Richard, how do you think of the patch?
>>
>> (The major concern for me is:
>>
>> With the current patch proposed by Peter, we will generate the call
>> to .DEFERRED_INIT for a variable with OPAQUE_TYPE during gimplification
>> phase,
>> However, if this variable is in register, then the call to
>> .DEFERRED_INIT will NOT be expanded during RTL expansion phase. This
>> unexpanded call to .DEFERRED_INIT might cause some potential IR issue later?
>
> I think that's inconsistent indeed.
Can we treat the call to .DEFERRED_INIT to a NOP during expansion phase if we
cannot expand it to a valid RTL for the OPAQUE_TYPE? Will doing this resolve
the issues?
> Peter, what are "opaque"
> registers? rs6000-modes.def suggests
> that there's __vector_pair and __vector_quad, what's the GIMPLE types
> for those? It seems they
> are either SSA names or expanded to pseudo registers but there's no
> constants for them.
>
>>
>> If the above is a real issue, should we skip initialization for all
>> OPAQUE_TYPE variables even when they are in memory and can be initialized
>> with memset?
>> then we should update “is_var_need_auto_init” in gimplify.c
>> instead. However, the issue with this approach is, we might miss the
>> opportunity to initialize an OPAQUE_TYPE variable if it will be in memory?
>> ).
>
> I think we need to bite the bullet at some point to do register initialization
> not via expand_assignment but directly based on what the LHS expands to.
OPAQUE_TYPE is so special, it should not be the reason to rewrite the register
initialization from my understanding.
If later more issue exposed, it might be necessary to rewrite this part.
Qing
>
> Can they be initialized? I see they can be copied at least.
>
> If such "things" cannot be initialized they should indeed be exempt
> from auto-init. The
> documentation suggests that they act as bit-bucked but even bit-buckets should
> be initializable, thus why exactly does CONST0_RTX not exist for them?
>
> Richard.
>
>
>>
>> Thanks.
>>
>> Qing
>>
>>
>>> On Nov 29, 2021, at 3:56 PM, Peter Bergner <berg...@linux.ibm.com> wrote:
>>>
>>> Sorry for dropping the ball on testing the patch from the bugzilla!
>>>
>>> The following patch fixes the ICE reported in the bugzilla on the
>>> pre-existing
>>> gcc testsuite test case, bootstraps and shows no testsuite regressions
>>> on powerpc64le-linux. Ok for trunk?
>>>
>>> Peter
>>>
>>>
>>> For -ftrivial-auto-var-init=*, skip initializing the register variable if it
>>> is an opaque type, because CONST0_RTX(mode) is not defined for opaque modes.
>>>
>>> gcc/
>>> PR middle-end/103127
>>> * internal-fn.c (expand_DEFERRED_INIT): Skip if VAR_TYPE is opaque.
>>>
>>> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
>>> index 0cba95411a6..7cc0e9d5293 100644
>>> --- a/gcc/internal-fn.c
>>> +++ b/gcc/internal-fn.c
>>> @@ -3070,6 +3070,10 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
>>> }
>>> else
>>> {
>>> + /* Skip variables of opaque types that are in a register. */
>>> + if (OPAQUE_TYPE_P (var_type))
>>> + return;
>>> +
>>> /* If this variable is in a register use expand_assignment.
>>> For boolean scalars force zero-init. */
>>> tree init;
>>
