From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by server2.sourceware.org (Postfix) with ESMTPS id 9DB6B3948A49 for ; Mon, 9 Mar 2020 12:55:05 +0000 (GMT) Received: by mail-lf1-x143.google.com with SMTP id t21so7575623lfe.9 for ; Mon, 09 Mar 2020 05:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=OocBUGuiE+vVqVvtXwnll14LpCfOUPfFy41SGDxFpmA=; b=AD7rQQZPh5L/e4WT/hmdw2KFB+E6qUsn5RdLkbnfH6FT7Bt3yRwa8RnN0eNpYGU+O1 Yorzot1MECP8+UA96IIDCJAWF56KGX3Ltss5vgXaTGjEwid5djS+o3QnkepHZPYYMa3b rL2nqoOhFVkHAX8Cpy8mrzsqi7gqz829CXlGXfenU6Dm71vR/uMSgbcVZnbGH2K0sTn0 DmOOrPVSjxpDa2EFl5zPHBKpJ4s9qD2cvcYLwxIvB01Rj41SJNAiTehDEpBI4ERXltdS oy0Z8AXw+u89BH4HsXx4QnJ1CPPJZk8ApbgHbvXhWRRIvXMCN0ybxDuHshhQwjlsyyM3 3+uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=OocBUGuiE+vVqVvtXwnll14LpCfOUPfFy41SGDxFpmA=; b=P3y4yaK/oHy023b1vvx8qSzo7McGd94YYSfuex3NzpSw4+9n2bGaCSVaw8iys5hst9 M/s/bRXgdCK7XXczUEciDOgnWN4HmDyaC6Pcr+HgW3WXSV1wue4Ja1roam9j1Yu0eqOJ dwlVcYuZRC0j7ZMqYCiQNY3GDOfR707PbUv5LX1fA/RqwpcR427UFhUYJl3oQPk0mcY1 gVMVJ8cFw//XXomB+Adh4w/s7bF1YWXEcxZPigapikSHwx5C+qQOvt3btADgm/MWnlkw l8CvBcNZwzaKTm2n2VFEHdViCsw4QUoyFTxZJky8jHV2/NEuJmSzLrC637TMNInkxd70 OCZg== X-Gm-Message-State: ANhLgQ0cGoD9cytpoGK0EscJ8SW57OgESAF6cPZNpsQg0KPuWXhATR0G X+3bg2RiEL9tylP5GtV2AtLQaBNHgbVT+mocHDA= X-Google-Smtp-Source: ADFU+vvxIs2H4zDLV3zRPKzDj6euog1x7qSGXZy6HmsS07fUwzy7cUL0AuWIwIBkM9u0sdjEjaHPFsFjvLBNxdN22n0= X-Received: by 2002:ac2:4c14:: with SMTP id t20mr6093470lfq.193.1583758504294; Mon, 09 Mar 2020 05:55:04 -0700 (PDT) MIME-Version: 1.0 References: <20200307171244.1959-1-jwjagersma@gmail.com> <20200307192023.GK22482@gate.crashing.org> In-Reply-To: From: Richard Biener Date: Mon, 9 Mar 2020 13:54:53 +0100 Message-ID: Subject: Re: [PATCH v2] generate EH info for volatile asm statements (PR93981) To: "J.W. Jagersma" , Segher Boessenkool , GCC Patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Mon, 09 Mar 2020 12:55:06 -0000 On Mon, Mar 9, 2020 at 1:14 PM Richard Sandiford wrote: > > Thanks for doing this. > > "J.W. Jagersma" writes: > > On 2020-03-07 20:20, Segher Boessenkool wrote: > >> Hi! > >> > >> On Sat, Mar 07, 2020 at 06:12:45PM +0100, J.W. Jagersma wrote: > >>> The following patch extends the generation of exception handling > >>> information to cover volatile asms too. This was already mostly > >>> implemented, and only minor changes are required in order to make it > >>> work. > >> > >> This should wait for stage 1, IMO. Looks pretty good to me, thanks! > > > > Hi, thanks for your response. > > What does stage 1 refer to? I'm sorry, this is my first gcc patch and > > I'm still learning how this all works. > > > >> Some comments: > >> > >>> +When non-call exceptions (@option{-fnon-call-exceptions}) are enabled, a > >>> +@code{volatile asm} statement is also allowed to throw exceptions. If it > >>> +does, then the compiler assumes that its output operands have not been written > >>> +yet. > >> > >> That reads as if the compiler assumes the outputs retain their original > >> value, but that isn't true (I hope!) The compiler assumes the output > >> are clobbered, but it doesn't assume they are assigned any definite > >> value? > > > > Register outputs are assumed to be clobbered, yes. For memory outputs > > this is not the case, if the asm writes it before throwing then the > > memory operand retains this value. It should be the user's > > responsibility to ensure that an asm has no side-effects if it throws. > > I guess one problem is that something like "=&m" explicitly says that > the operand is clobbered "early", and I think it would be fair for > "early" to include clobbers before the exception. So IMO we should > allow at least early-clobbered memory outputs to be clobbered by the > exception. I think memory operands are fine - my original concern was about register outputs and SSA form that should reflect the correct def on the EH vs non-EH edge. From a "miscompile" perspective doing nothig which means pretending the asm actually set the output could lead us to false DCE of the old value: int foo = 0 try { asm volatile ("..." : "=r" (foo)); } catch (...whatever...) { foo should be still zero, but SSA doesn't have the correct use here } that means the compiler really assumes the asm will populate the outputs even when it throws. Test coverage for that would be nice. > And if we do that, then I'm not sure there's much benefit in trying to > treat the non-earlyclobber memory case specially. > > It would be good to have testcases for the output cases. E.g. for: > > int foo; > int bar = 0; > try > { > foo = 1; > asm volatile ("..." : "=m" (foo)); > } > catch (...whatever...) > { > bar = foo; > } > ...use bar... > > What does "bar = foo" read? Is it always undefined behaviour if executed? > Or does it always read "foo" from memory? Can it be optimised to "bar = 1"? > Is "foo = 1" dead code? > > Thanks, > Richard