From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124939 invoked by alias); 24 Jan 2019 21:10:19 -0000 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 Received: (qmail 124908 invoked by uid 89); 24 Jan 2019 21:10:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=learn X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 24 Jan 2019 21:10:17 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x0OLA94e022087; Thu, 24 Jan 2019 15:10:10 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x0OLA7Me022086; Thu, 24 Jan 2019 15:10:07 -0600 Date: Thu, 24 Jan 2019 21:13:00 -0000 From: Segher Boessenkool To: Alexander Monakov Cc: Andrey Belevantsev , David Malcolm , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] sched-ebb.c: avoid moving table jumps (PR rtl-optimization/88423) Message-ID: <20190124211006.GK14180@gate.crashing.org> References: <1547832768-62740-1-git-send-email-dmalcolm@redhat.com> <1547830690.7788.176.camel@redhat.com> <4a8b4249-1aa4-92ff-9497-ef17d8f64b80@ispras.ru> 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-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg01468.txt.bz2 On Thu, Jan 24, 2019 at 06:43:38PM +0300, Alexander Monakov wrote: > On Wed, 23 Jan 2019, Alexander Monakov wrote: > > > It appears that sched-deps tries to take notice of a barrier after a jump, but > > similarly to sched-ebb doesn't anticipate that for a tablejump the barrier will > > appear after two more insns (a code_label and a jump_table_data). > > > > If so, it needs a fixup just like the posted change for the assert. I'll fire up > > a bootstrap/regtest. > > Updated patch below (now taking into account that NEXT_INSN may give NULL) > passes bootstrap/regtest on x86_64, also with -fsched2-use-superblocks. > > I'm surprised to learn that a tablejump may be not the final insn in its > containing basic block. It certainly seems like a ripe ground for logic > bugs like this one. Is it really intentional? md.texi says The @samp{tablejump} insn is always the last insn before the jump table it uses. Its assembler code normally has no need to use the second operand, but you should incorporate it in the RTL pattern so that the jump optimizer will not delete the table as unreachable code. but rtl.texi says A @code{jump_table_data} insn is a placeholder for the jump-table data of a @code{casesi} or @code{tablejump} insn. They are placed after a @code{tablejump_p} insn. A @code{jump_table_data} insn is not part o a basic blockm but it is associated with the basic block that ends with the @code{tablejump_p} insn. The @code{PATTERN} of a @code{jump_table_data} is always either an @code{addr_vec} or an @code{addr_diff_vec}, and a @code{jump_table_data} insn is always preceded by a @code{code_label}. The @code{tablejump_p} insn refers to that @code{code_label} via its @code{JUMP_LABEL}. Which of these two is true? Segher