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 77E73384F031 for ; Mon, 13 Feb 2023 11:15:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 77E73384F031 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=1676286904; 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=1K0nngQVWfXr5qwnnBTF8PnG5Chnd50DMtBRFBknGsQ=; b=XSlHRt3qZouonvCKyi1jUAlakhsd3FcjhIRLTdlNs+IoE/hFzC/EEtRW9ljg0NJNFEhBfz GhUBYGpIAoTn9z9uy8wQNCt/tFolD5CAnaamZ1d9sxpOrV+LfcpzZDkQ6zjfbbsknB4x6L TlAH0dSbxEX1omieUeZHYxWeW/udxp8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-586--qt3vqDeMZKqrbZSKyp4Bw-1; Mon, 13 Feb 2023 06:14:44 -0500 X-MC-Unique: -qt3vqDeMZKqrbZSKyp4Bw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AB3A6801CFC; Mon, 13 Feb 2023 11:14:35 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6AFFD492B16; Mon, 13 Feb 2023 11:14:35 +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 31DBEWwc3945110 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 13 Feb 2023 12:14:32 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 31DBELot3945108; Mon, 13 Feb 2023 12:14:21 +0100 Date: Mon, 13 Feb 2023 12:14:21 +0100 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] tree-optimization/108691 - indirect calls to setjmp Message-ID: Reply-To: Jakub Jelinek References: <20230213110058.0C9B61391B@imap2.suse-dmz.suse.de> MIME-Version: 1.0 In-Reply-To: <20230213110058.0C9B61391B@imap2.suse-dmz.suse.de> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 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.5 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 Mon, Feb 13, 2023 at 12:00:56PM +0100, Richard Biener wrote: > DCE now chokes on indirect setjmp calls becoming direct because > that exposes them too late to be subject to abnormal edge creation. > The following patch honors gimple_call_ctrl_altering for those and > _not_ treat formerly indirect calls to setjmp as calls to setjmp. > > Unfortunately there's no way to have an indirect call to setjmp > properly annotated (the returns_twice attribute is ignored on types). > > RTL expansion late discovers returns-twice for the purpose of > adding REG_SETJMP notes and also sets ->calls_setjmp > (instead of asserting it is set). There's no good way to > transfer proper knowledge around here so I'm using ->calls_setjmp > as a flag to indicate whether gimple_call_ctrl_altering was set. > > Comments on what's the most sensible thing to do here? Supporting > returns_twice on indirect calls wouldn't be difficult, so we're > talking about how to handle this kind of "legacy" situation? One thing is supporting returns_twice on function types, but another one is that initially none of the calls will be marked that way and even later, it is up to the user if they mark it or not. Could we e.g. prevent turning such indirect calls into direct calls? Anyway, notice_special_calls is called in various spots, not just DCE, wouldn't it be better to simply not set calls_setjmp flag in there if the current function already has cfg and the call isn't ctrl altering? Jakub