From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13405 invoked by alias); 1 Dec 2012 00:03:25 -0000 Received: (qmail 13390 invoked by uid 22791); 1 Dec 2012 00:03:23 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,TW_DD,TW_HR,TW_OV,TW_TJ X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 01 Dec 2012 00:03:16 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id A7A83CB2979; Sat, 1 Dec 2012 01:03:19 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mZFbAtSFg2m; Sat, 1 Dec 2012 01:03:19 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 505C4CB2105; Sat, 1 Dec 2012 01:03:19 +0100 (CET) From: Eric Botcazou To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org, Hans-Peter Nilsson , Alexandre Oliva Subject: Re: [RFA:] fix PR55030, wrong code from __builtin_setjmp_receiver Date: Sat, 01 Dec 2012 00:03:00 -0000 Message-ID: <5168941.MITq8HrSd0@polaris> User-Agent: KMail/4.7.2 (Linux/3.1.10-1.16-desktop; KDE/4.7.2; x86_64; ; ) In-Reply-To: <20121127182001.GD2315@tucnak.redhat.com> References: <20520021.fBU7p54CN9@polaris> <20121127182001.GD2315@tucnak.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-12/txt/msg00000.txt.bz2 > I was mainly arguing with the sentence that for asm volatile, the output > constraints (did you mean outputs and clobbers?) have essentially no > meaning. While for some optimizations perhaps it might be desirable > to treat asm volatile as full optimization barrier, I'm not sure about all > of them (i.e. it would be important to look for performance degradations > caused by that change), and for var-tracking I'd argue that asm vs. asm > volatile is completely unimportant, if the asm volatile pattern (or even > UNSPEC_VOLATILE) doesn't say it clobbers or sets hard register XYZ, then it > can't change it (well, it could but is responsible of restoring it), > similarly for memory, if it doesn't clobber "memory" and doesn't set some > memory, it can't do that. Yes, I meant outputs and clobbers. The origin of all this is: `blockage' This pattern defines a pseudo insn that prevents the instruction scheduler and other passes from moving instructions and using register equivalences across the boundary defined by the blockage insn. This needs to be an UNSPEC_VOLATILE pattern or a volatile ASM. Now the typical blockage insn is that of the x86: ;; UNSPEC_VOLATILE is considered to use and clobber all hard registers and ;; all of memory. This blocks insns from being moved across this point. (define_insn "blockage" [(unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)] "" "" [(set_attr "length" "0")]) [Note the pretty adamant comment about UNSPEC_VOLATILE here...] So, if UNSPEC_VOLATILE is not treated specially, the blockage insn of most ports won't block hard register equivalences. And blockages are precisely used to do that, see e.g. the untyped_call pattern of the x86: /* The optimizer does not know that the call sets the function value registers we stored in the result block. We avoid problems by claiming that all hard registers are used and clobbered at this point. */ emit_insn (gen_blockage ()); That being said, I agree that volatile asms are a separate discussion. > So, do you object even to the var-tracking change (which would mean if > var-tracking found that say some variable's value lives in hard register 12, > when encountering asm volatile it would mean to forget about that even when > hard register 12 isn't clobbered by the asm, nor set)? For now > var-tracking seems to be the most important issue, as we generate invalid > debug info there (latent before, but never hit on inline asm on x86_64/i686 > except on setjmp calls). For volatile asms, no, thanks for fixing the fallout on this side. > As for other passes, the r193802 change e.g. regresses slightly modified > pr44194-1.c testcase on x86_64, > struct ints { int a, b, c; } foo(); > void bar(int a, int b); > > void func() { > struct ints s = foo(); > int x; > asm volatile ("" : "=r" (x)); > bar(s.a, s.b); > } > > func: > .LFB0: > - xorl %eax, %eax > subq $24, %rsp > .LCFI0: > + xorl %eax, %eax > call foo > - movq %rax, %rcx > - shrq $32, %rcx > - movq %rcx, %rsi > - movl %eax, %edi > + movq %rax, (%rsp) > + movl %edx, 8(%rsp) > + movl 4(%rsp), %esi > + movl (%rsp), %edi > addq $24, %rsp > .LCFI1: > jmp bar > > To me it looks like an unnecessary pessimization, the volatile there > I understand that just it doesn't want to be moved around (e.g. scheduled > before the foo call or after bar), that it can't be DCEd, but as it doesn't > mention it modifies memory, I don't understand why it should force some > registers to stack and back when it has no way to know the compiler would be > emitting anything like that at all. > Compare that to > asm volatile ("" : "=r" (x) : : "memory"); > in the testcase, where the r193802 commit makes no difference, the > stores/loads are done in both cases. OK, I agree that the fallout for DSE, and the effect on memory in general, is undesirable, especially for volatile asms. > For CSE, I'd agree it should treat asm volatile as barriers, so for cselib.c > we probably need some additional cselib_init flag how we want to treat > volatile asms... For UNSPEC_VOLATILE, perhaps even DSE should stay > conservative, but for var-tracking.c I still don't see a reason for that. Thank you (as well as the others) for the detailed feedback. Clearly my initial stance on this was a bit extreme and needs to be watered down. I'll ponder about this over the week-end and propose something next week. -- Eric Botcazou