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

Qing Zhao qing.zhao@oracle.com
Mon Nov 29 22:56:12 GMT 2021


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?

         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?



> 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