From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-331416-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 28891 invoked by alias); 9 Nov 2012 12:48:04 -0000
Received: (qmail 28855 invoked by uid 22791); 9 Nov 2012 12:48:02 -0000
X-SWARE-Spam-Status: No, hits=-5.0 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_ZJ
X-Spam-Check-By: sourceware.org
Received: from mail-da0-f47.google.com (HELO mail-da0-f47.google.com) (209.85.210.47)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Nov 2012 12:47:58 +0000
Received: by mail-da0-f47.google.com with SMTP id s35so1568561dak.20        for <gcc-patches@gcc.gnu.org>; Fri, 09 Nov 2012 04:47:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.66.80.66 with SMTP id p2mr31247913pax.84.1352465277612; Fri, 09 Nov 2012 04:47:57 -0800 (PST)
Received: by 10.66.246.232 with HTTP; Fri, 9 Nov 2012 04:47:57 -0800 (PST)
In-Reply-To: <20121109123617.GA1886@tucnak.redhat.com>
References: <CAK1BsWrsVu4TRW50RW0X7G4RSguSAjhqFPe-tkeXKaurr=sX1A@mail.gmail.com>	<CAFULd4b0y6GGZsn1s4-RXc1mAvZGrhGd4YQBhfLgeMWmv2eXPA@mail.gmail.com>	<CAK1BsWoL5hsfZprf-a8zxG+Bhe9SwGFwqxHxOw9UX+bbsFD5oQ@mail.gmail.com>	<CAFULd4bJXT-nnAk6HCn2C=+jhfiUD-fAe3LK8AYd9jgqQQHvKQ@mail.gmail.com>	<CAFULd4bdxuKbYYS7TcyRfjNukLvJ0d5pOD7zJGAyKEQLPq7z2Q@mail.gmail.com>	<CAK1BsWpL69eRHTD8dzVOm9xtOqtjcr6z3B2tvb_VikWPzKT0Dw@mail.gmail.com>	<CAFULd4YaVLCYF=Huw_kDozTBTcZnGUAy7xOcV+VEweOWZ5Cigg@mail.gmail.com>	<CAFULd4YyRVY4BzD+csZAqCCmB7v3YEwAaOpNW9QsMXEbCkFw+Q@mail.gmail.com>	<CAK1BsWrRTFUC8EnODa1r94_bkkhP+xgkw15qPTf+z=AXqjtXoA@mail.gmail.com>	<CAFULd4bw0ma79MtGiKM_4Kt29O32rsME0mW05rnBephE3dxjiQ@mail.gmail.com>	<20121109123617.GA1886@tucnak.redhat.com>
Date: Fri, 09 Nov 2012 12:48:00 -0000
Message-ID: <CAFULd4ZAoG6_oQcG9YcR_k+kOUbyG_jw3ag0e+0zk37VEA-swg@mail.gmail.com>
Subject: Re: [off-list] Re: [PATCH] Vzeroupper placement/47440
From: Uros Bizjak <ubizjak@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Vladimir Yakovlev <vbyakovl23@gmail.com>, "H.J. Lu" <hjl.tools@gmail.com>, 	Igor Zamyatin <izamyatin@gmail.com>, gcc-patches@gcc.gnu.org
Content-Type: text/plain; charset=ISO-8859-1
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2012-11/txt/msg00738.txt.bz2

On Fri, Nov 9, 2012 at 1:36 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Nov 09, 2012 at 01:29:18PM +0100, Uros Bizjak wrote:
>> On Fri, Nov 9, 2012 at 1:18 PM, Vladimir Yakovlev <vbyakovl23@gmail.com> wrote:
>> >> These assert should tell you what is wrong with the control flow.
>> >> Please look at control_flow_insn_p, which condition returns true.
>> >
>> > There is a note after call insn.
>> >
>> > (call_insn:TI 908 35558 50534 1681 (call (mem:QI (symbol_ref:DI
>> > ("_gfortran_stop_string") [flags 0x41] <function_decl 0x7ffff7eb6200
>> > _gfortran_stop_string>) [0 _gfortran_stop_string S1 A8])
>> >         (const_int 0 [0])) huygens.fppized.f90:190 616 {*call}
>> >      (expr_list:REG_DEAD (reg:DI 5 di)
>> >         (expr_list:REG_DEAD (reg:SI 4 si)
>> >             (expr_list:REG_NORETURN (const_int 0 [0])
>> >                 (nil))))
>> >     (expr_list:REG_FRAME_RELATED_EXPR (use (reg:DI 5 di))
>> >         (expr_list:REG_BR_PRED (use (reg:SI 4 si))
>> >             (nil))))
>> > (note 50534 908 909 1681 (expr_list:REG_DEP_TRUE (concat:DI (reg:DI 5 di)
>> >         (const_int 0 [0]))
>> >     (expr_list:REG_DEP_TRUE (concat:SI (reg:SI 4 si)
>> >             (const_int 0 [0]))
>> >         (nil))) NOTE_INSN_CALL_ARG_LOCATION)
>> >
>>
>> Huh, this RTX is ignored:
>
> NOTE_INSN_CALL_ARG_LOCATION is fine, even after a REG_NORETURN call.
> It is just a way how to pass call argument details to dwarf2out.
> If you have a pass after var-tracking, you need to skip over it.

Yes, but postreload mode switching should come before pro_and_epilogue
anyway, otherwise create_pre_exit won't work:

--mode-switching.c (222)--
	/* If this function returns a value at the end, we have to
	   insert the final mode switch before the return value copy
	   to its hard register.  */
	if (EDGE_COUNT (EXIT_BLOCK_PTR->preds) == 1
	    && NONJUMP_INSN_P ((last_insn = BB_END (src_bb)))
	    && GET_CODE (PATTERN (last_insn)) == USE
	    && GET_CODE ((ret_reg = XEXP (PATTERN (last_insn), 0))) == REG)
--mode-switching.2 (228)--

I believe that this will work OK if the pass is inserted before
prologue generation pass.

Uros.