[PATCH] middle-end: Skip initialization of opaque type register variables [PR103127]

Qing Zhao qing.zhao@oracle.com
Tue Nov 30 17:59:57 GMT 2021



> On Nov 30, 2021, at 2:37 AM, Richard Biener <richard.guenther@gmail.com> wrote:
> 
> On Mon, Nov 29, 2021 at 11:56 PM Qing Zhao <qing.zhao@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 <bergner@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;
>> 



More information about the Gcc-patches mailing list