From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id B27113985449 for ; Wed, 11 Aug 2021 16:15:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B27113985449 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 628B81063; Wed, 11 Aug 2021 09:15:03 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8F4DC3F718; Wed, 11 Aug 2021 09:15:02 -0700 (PDT) From: Richard Sandiford To: Qing Zhao Mail-Followup-To: Qing Zhao , Qing Zhao via Gcc-patches , Richard Biener , Jakub Jelinek , Kees Cook , richard.sandiford@arm.com Cc: Qing Zhao via Gcc-patches , Richard Biener , Jakub Jelinek , Kees Cook Subject: Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc References: <52E29277-1403-4755-901A-528116C43FB8@oracle.com> <58ADBC0C-9D44-485B-BB5A-B072664B9C4F@oracle.com> <6FD42B95-F73D-4B75-B83A-BAC4925B1714@oracle.com> Date: Wed, 11 Aug 2021 17:15:01 +0100 In-Reply-To: (Qing Zhao's message of "Wed, 11 Aug 2021 13:44:34 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2021 16:15:05 -0000 Qing Zhao writes: >> On Aug 11, 2021, at 4:02 AM, Richard Sandiford wrote: >>> I came up with the following solution: >>>=20 >>> Define the IFN_DEFERRED_INIT function as: >>>=20 >>> LHS =3D DEFERRED_INIT (SIZE of the DECL, INIT_TYPE, IS_VLA); >>>=20 >>> if IS_VLA is false, the LHS is the DECL itself, >>> if IS_VLA is true, the LHS is the pointer to this DECL that created by >>> gimplify_vla_decl. >>>=20 >>>=20 >>> The benefit of this solution are: >>>=20 >>> 1. Resolved the invalid IR issue; >>> 2. The call stmt carries the address of the VLA natually; >>>=20 >>> The issue with this solution is: >>>=20 >>> For VLA and non-VLA, the LHS will be different,=20 >>>=20 >>> Do you see any other potential issues with this solution? >>=20 >> The idea behind the DECL version of the .DEFERRED_INIT semantics was >> that .DEFERRED_INIT just returns a SIZE-byte value that the caller >> then assigns to a SIZE-byte lhs (with the caller choosing the lhs). >> .DEFEREED_INIT itself doesn't read or write memory and so can be const, >> which in turn allows alias analysis to be more precise. > Yes. That=E2=80=99s right. > >>=20 >> If we want to handle the VLA case using pointers instead then I think >> that needs to be a different IFN. >>=20 >> If we did handle the VLA case using pointers (not expressing an opinion >> on that), then it would be the caller's job to allocate the VLA and work >> out the address of the VLA; > > the current routine =E2=80=9Cgimplify_vla_decl=E2=80=9D has done this alr= eady: > > It created a temporary variable for the address of the VLA, and created a= call to =E2=80=9Calloca=E2=80=9D to allocate the VLA. Right, that's what I mean. It's this alloca that allocates the VLA and determines its address. This address is therefore logically an input rather than an output to the following zero/pattern initialisation. In C you wouldn't write: addr =3D alloca(size); addr =3D initialise(size); to allocate and initialise a size-byte buffer, because initialise() would need to know the address of the memory it's supposed to initialise. The same is true for this gimple code. > My -ftrivial-auto-var-init work just try to use the =E2=80=9Caddress vari= able of the VLA=E2=80=9D in the new .DEFERRED_INIT call to carry it to RTL = expansion phase. > > >> this isn't something that .DEFERRED_INIT >> would work out on the caller's behalf. The address of the VLA should >> therefore be an argument to the new IFN, rather than something that >> the IFN returns. > > Then what=E2=80=99s the LHS of this call? Currently the major issue is th= e LHS is invalid gimple. For this (different, address-taking, VLA-only) IFN, there would be no lhs. The IFN would be similar to a memset. Like I say, this is all hypothetical, based on =E2=80=9Cif we did handle th= e VLA case using pointers=E2=80=9D. As discussed, it would make alias analysis l= ess precise. I was just answering the question about whether there were potential issues. Thanks, Richard