[PATCH] middle-end: Skip initialization of opaque type register variables [PR103127]
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 <firstname.lastname@example.org> 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?
> 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.
> 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)
> + /* 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