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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 3D19F3858027 for ; Tue, 22 Feb 2022 17:58:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3D19F3858027 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-330-zRNApojLMHGkE3deL2UzmA-1; Tue, 22 Feb 2022 12:57:58 -0500 X-MC-Unique: zRNApojLMHGkE3deL2UzmA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D689284A5F1 for ; Tue, 22 Feb 2022 17:57:57 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.125]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 982BD87544; Tue, 22 Feb 2022 17:57:20 +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 21MHvI17526202 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 22 Feb 2022 18:57:18 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 21MHvH0v526201; Tue, 22 Feb 2022 18:57:17 +0100 Date: Tue, 22 Feb 2022 18:57:17 +0100 From: Jakub Jelinek To: Andrew MacLeod Cc: gcc-patches , Aldy Hernandez Subject: Re: [PATCH 0/2] tree-optimization/104530 - proposed re-evaluation. Message-ID: Reply-To: Jakub Jelinek References: <9328c989-f5c0-084b-4f66-d705d023d474@redhat.com> MIME-Version: 1.0 In-Reply-To: <9328c989-f5c0-084b-4f66-d705d023d474@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.1 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_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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: Tue, 22 Feb 2022 17:58:01 -0000 On Tue, Feb 22, 2022 at 12:39:28PM -0500, Andrew MacLeod wrote: > > That is EH, then there are calls that might not return because they leave > > in some other way (e.g. longjmp), or might loop forever, might exit, might > > abort, trap etc. > Generally speaking, calls which do not return should not now be a problem... > as long as they do not transfer control to somewhere else in the current > function. I thought all of those cases are very relevant to PR104530. If we have: _1 = ptr_2(D) == 0; // unrelated code in the same bb _3 = *ptr_2(D); then in light of PR104288, we can optimize ptr_2(D) == 0 into true only if there are no calls inside of "// unrelated code in the same bb" or if all calls in "// unrelated code in the same bb" are guaranteed to return exactly once. Because, if there is a call in there which could exit (that is the PR104288 testcase), or abort, or trap, or loop forever, or throw externally, or longjmp or in any other non-UB way cause the _1 = ptr_2(D) == 0; stmt to be invoked at runtime but _3 = *ptr_2(D) not being invoked, then we can't optimize the earlier comparison because ptr_2(D) could be NULL in a valid program. While if there are no calls (and no problematic inline asms) and no trapping insns in between, we can and PR104530 is asking that we continue to optimize that. Jakub