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.129.124]) by sourceware.org (Postfix) with ESMTPS id E151D3883F14 for ; Thu, 8 Dec 2022 12:20:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E151D3883F14 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670502050; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=Y41xe3a7+t6sKomsu9dN0/H5H2mwNkBzP/HhEGnOX9Y=; b=T4Kgb3QUvT0l7h26/fn9XP0ExpZFo21jpXeBTvsrrs71b/cymXJ5tDh7+1Jl5Gik3Fyq86 nlQFJh/t3jGBD3Hnmgb2h0PkdFefgU24CSIDE6CpVTExtzRaTSVw61GNKgFn2JvIQnIEdp IaBnPcRi9lZ61Ih3vUvJ5TRIqNx1glE= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-675-pQ7Qg4q4M8GkBpeMu93qsg-1; Thu, 08 Dec 2022 07:20:47 -0500 X-MC-Unique: pQ7Qg4q4M8GkBpeMu93qsg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B22821C0514A; Thu, 8 Dec 2022 12:20:46 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.114]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6EB6A40C2064; Thu, 8 Dec 2022 12:20:46 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 2B8CKfEq1995932 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 8 Dec 2022 13:20:42 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2B8CKfdK1995931; Thu, 8 Dec 2022 13:20:41 +0100 Date: Thu, 8 Dec 2022 13:20:40 +0100 From: Jakub Jelinek To: "Jose E. Marchesi" Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization Message-ID: Reply-To: Jakub Jelinek References: <20221208105944.660323-1-jose.marchesi@oracle.com> MIME-Version: 1.0 In-Reply-To: <20221208105944.660323-1-jose.marchesi@oracle.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 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=-3.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Dec 08, 2022 at 11:59:44AM +0100, Jose E. Marchesi via Gcc-patches wrote: > gcc/ChangeLog > > * expr.cc (expand_expr_divmod): Avoid side-effects of trying > sequences involving funcalls in optimization. That looks wrong. The globals for mentioned calls just shouldn't be emitted during expansion, especially if it is bigger annoyance than just having some extra symbols in the symbol table. expand_expr_divmod is definitely not the only place where something is expanded and later not used, lots of other places in the expander do that, and more importantly, there are over 80 optimization passes after expansion, many of them can remove code determined to be dead, and while lots of dead code is removed in GIMPLE optimizations already, definitely not all. So, rather than add hacks for this in a single spot, much better is to emit the globals only for stuff that is actually needed (so during final or immediately before it). Jakub