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 E55663858D1E for ; Mon, 15 Jan 2024 15:06:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E55663858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E55663858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705331180; cv=none; b=Yx9aNvGf8tjwV+Z92DvGYfR80zCA2Ef84vGiGaYgsrT4I7zYtm3w865FvP/LH9pBrHRd4dj3DDPnmtWvDw5YKcQ7yROCsp7YFWcklr2Q+Y+VxRcV6DnefIoxr0MttA4Wd8wezBcczOMuX8t5G3i3MsQt0V1d/Jdmv5dgtEZjK1U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705331180; c=relaxed/simple; bh=21V/GB9TAz8yw+t6Z9W0iquB8mMr+yvGAWfGLyh2kSw=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=c0f1KuZOq0mydfofH3hN0+xt+VbhqbHSMh8jnxZ97LEkr5bpoCDyVvLcbC8cXK6v2eSc7H5LfPZ7e0ZwGEsri/LxSp8WoW+AoQ8ZfllIWCPf5GL+6JN/cEApxVYdPzTEX/fSy2dRTKz8ZrTqLSJP7bxgCq2xOss+2pLZLEY3BRI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1705331169; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=i5mMhpL/lx9vZqireQxPBIFSQXEuqg3ABmQLj0wE2sg=; b=iI645t0SrV8TRaxtEuFVWkr8jegyyJCYG7+GVmVkhMqSEHCZNjzX7ManbsYW2//vo0qZae FHbyO2SW8/gZDS9Cz0Hl1LUShCS4jmyZjx9Eyo4TZPUDnHdCeONLkFmEXQf7oGEhBcZeF8 NHRqYxUwuhoLDvW7u1dVALoftvIqHqE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-440-ICWp0MU7PD26h5Wh1nRgmw-1; Mon, 15 Jan 2024 10:06:08 -0500 X-MC-Unique: ICWp0MU7PD26h5Wh1nRgmw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D3E69185A780; Mon, 15 Jan 2024 15:06:07 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 977883C25; Mon, 15 Jan 2024 15:06:07 +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 40FF64ZQ1556151 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 15 Jan 2024 16:06:05 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 40FF64rN1556150; Mon, 15 Jan 2024 16:06:04 +0100 Date: Mon, 15 Jan 2024 16:06:03 +0100 From: Jakub Jelinek To: Qing Zhao Cc: Richard Biener , gcc Patches Subject: Re: HELP: Questions on unshare_expr Message-ID: Reply-To: Jakub Jelinek References: <50C8811D-9C2A-4FFB-9FC5-D24C5A76F868@oracle.com> <70C34042-B741-4697-9524-396CB9D40DF8@gmail.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 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=-4.2 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_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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 Mon, Jan 15, 2024 at 02:54:26PM +0000, Qing Zhao wrote: > So, before gimplification, when inserting tree node, we don’t need manually > add unshare_expr since the gimplification will automatically unshare nodes. There are cases where unshare_expr is needed even then, such as the uses in the sanitizer, because code is then modifying suboperands in place later on and if things are shared bad things happen. If trees can be shared until they are unshared before gimplification, one doesn't need to worry about it, sure. > However, during or after gimplfication, when inserting nodes, we should manually > add unshare_expr when we put the same “tree” into multiple operands. Yes. > > Using a SAVE_EXPR avoids redundant code but it also requires > > that the SAVE_EXPR uses are ordered. > > “Require the SAVE_EXPR uses are ordered”, does this mean that > SAVE_EXPRs for the same node should be in a correct order? Or something else? The basic requirement is that SAVE_EXPR is evaluated somewhere in a code which dominates all other uses of the SAVE_EXPR. Say SAVE_EXPR , if (x) use1 (SAVE_EXPR ); else use2 (SAVE_EXPR ); is fine, but if (x) use1 (SAVE_EXPR ); else use2 (SAVE_EXPR ); is not. Because in the latter case, it will be gimplified into evaluating the complex expression in the conditional code guarded on if (x != 0), save into some temporary variable and then in the else code just use that temporary variable, except it is uninitialized then. Jakub