From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTPS id C70663858404 for ; Mon, 18 Oct 2021 17:15:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C70663858404 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-547-ZyiPXV8IOvaFMrSicJtN3w-1; Mon, 18 Oct 2021 13:15:33 -0400 X-MC-Unique: ZyiPXV8IOvaFMrSicJtN3w-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0D9CB1006AA3; Mon, 18 Oct 2021 17:15:32 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.172]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7C36B68D7D; Mon, 18 Oct 2021 17:15:31 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 19IHFSiJ2441804 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 18 Oct 2021 19:15:28 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 19IHFR3X2441803; Mon, 18 Oct 2021 19:15:27 +0200 Date: Mon, 18 Oct 2021 19:15:27 +0200 From: Jakub Jelinek To: Qing Zhao Cc: Richard Biener , gcc-patches Nick Alcock via Subject: Re: [Patch][PR102281]do not add BUILTIN_CLEAR_PADDING for variables that are gimple registers. Message-ID: <20211018171527.GD304296@tucnak> Reply-To: Jakub Jelinek References: <89606056-4D5A-467B-A824-9163D882C35A@oracle.com> <20211018153644.GB304296@tucnak> <26B44186-5317-46E9-A414-97C0F0AC0D83@oracle.com> <20211018164606.GC304296@tucnak> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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: Mon, 18 Oct 2021 17:15:38 -0000 On Mon, Oct 18, 2021 at 05:01:55PM +0000, Qing Zhao wrote: > > The where is typically somewhere in the FEs. > > But, there are two things. > > One is that in order to gimplify it properly, it needs to be marked earlier. > > But the other is that if it is not addressable, then clearing padding in it > > makes not much sense as I've tried to explain, all it could do is making it > > slightly less likely that the var will be optimized into a gimple reg later, > > but if it does, then the padding will not be cleared anyway. > > And it is only at RTL expansion or RA that the var could be assigned into a > > stack location or spilled and at that point is the right time to clear > > padding in there if needed. > > So while the FEs could make it addressable and then you could clear padding, > > it would just penalize code and nothing else, later on the optimizations > > would figure out it is no longer addressable and optimize it into gimple > > reg. > > So, from my understanding so far, adding “!is_gimple_reg(decl)” to decide whether to add __builtin_clear_padding call > is a good and simple solution to this bug? Yes. And if you want to do something during RTL expansion or RA time, do it there incrementally after reasoning why it is needed at those points. E.g. for the spill slots, it doesn't have to be any kind of user variable but can be any kind of intermediate temporary... Jakub