From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTP id 53D08394354F for ; Wed, 18 Mar 2020 23:56:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 53D08394354F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@kernel.crashing.org Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jEiYN-0005r2-6j for gcc-patches@gcc.gnu.org; Wed, 18 Mar 2020 19:56:52 -0400 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 Received: from gate.crashing.org ([63.228.1.57]:51918) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jEiYN-0005qS-0M for gcc-patches@gcc.gnu.org; Wed, 18 Mar 2020 19:56:51 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 02INukKK022415; Wed, 18 Mar 2020 18:56:47 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 02INukLK022414; Wed, 18 Mar 2020 18:56:46 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 18 Mar 2020 18:56:46 -0500 From: Segher Boessenkool To: Michael Matz Cc: Richard Sandiford , "J.W. Jagersma" , gcc-patches@gcc.gnu.org Subject: Re: [PATCH v2] generate EH info for volatile asm statements (PR93981) Message-ID: <20200318235646.GQ22482@gate.crashing.org> References: <92b0f41e-754a-9dcd-8035-f064a5229e42@gmail.com> <7804a7b4-d9d9-7a00-59fe-88d55ead0e7a@gmail.com> <20200313145828.GQ22482@gate.crashing.org> <20200316190204.GC22482@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 63.228.1.57 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: Wed, 18 Mar 2020 23:56:53 -0000 On Tue, Mar 17, 2020 at 03:32:34PM +0000, Michael Matz wrote: > On Mon, 16 Mar 2020, Richard Sandiford wrote: > > Similarly for non-call exceptions on other statements. It sounds like > > what you're describing requires the corresponding definition to happen > > for memory outputs regardless of whether the asm throws or not, so that > > the memory appears to change on both excecution paths. Otherwise, the > > compiler would be able to assume that the memory operand still has its > > original value in the exception handler. > > Well, it's both: on the exception path the compiler has to assume that the > the value wasn't changed (so that former defines are regarded as dead) or > that it already has changed (so that the effects the throwing > "instruction" had on the result (if any) aren't lost). The easiest for > this is to regard the result place as also being an input. > > (If broadened to all instructions under -fnon-call-exceptions, and not > just to asms will have quite a bad effect on optimization capabilities, > but I believe with enough force it's already possible now to construct > miscompiling testcases with the right mixtures of return types and ABIs) It's a tradeoff: do we want this to work for almost no one and get PRs that we cannot solve, or do we generate slightly worse assembler code for -fnon-call-exceptions? I don't think this is a difficult decision to make, considering that you already get pretty bad performance with that flag (if indeed it works correctly at all). Segher