From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22129 invoked by alias); 27 Nov 2012 18:20:52 -0000 Received: (qmail 22109 invoked by uid 22791); 27 Nov 2012 18:20:50 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_DD,TW_HR,TW_OV,TW_TJ X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Nov 2012 18:20:38 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qARIKYXC032688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 13:20:34 -0500 Received: from zalov.redhat.com (vpn1-7-172.ams2.redhat.com [10.36.7.172]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qARIKQGU020790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2012 13:20:28 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id qARIKP4G029244; Tue, 27 Nov 2012 19:20:25 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id qARIK1Qi029138; Tue, 27 Nov 2012 19:20:01 +0100 Date: Tue, 27 Nov 2012 18:20:00 -0000 From: Jakub Jelinek To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org, Hans-Peter Nilsson , Alexandre Oliva Subject: Re: [RFA:] fix PR55030, wrong code from __builtin_setjmp_receiver Message-ID: <20121127182001.GD2315@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20121127120347.GU2315@tucnak.redhat.com> <20520021.fBU7p54CN9@polaris> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20520021.fBU7p54CN9@polaris> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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-11/txt/msg02248.txt.bz2 On Tue, Nov 27, 2012 at 06:35:52PM +0100, Eric Botcazou wrote: > Now I agree that the discussion exists for volatile asms. But you have for > example in the unmodified cse.c: > > /* A volatile ASM invalidates everything. */ > if (NONJUMP_INSN_P (insn) > && GET_CODE (PATTERN (insn)) == ASM_OPERANDS > && MEM_VOLATILE_P (PATTERN (insn))) > flush_hash_table (); That was weird indeed, because asm volatile ("" : : "r" (x)); flushed (for targets that don't add any implicit clobbers) but e.g. asm volatile ("" : : "r" (x) : "r23"); wouldn't (then the pattern is a parallel with ASM_OPERANDS and some CLOBBERs). The effect of that is that it never triggered on i?86/x86_64, because those have the implicit fprs/flags clobbers. 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. 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). 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. 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. Jakub