From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30270 invoked by alias); 28 May 2019 15:16:40 -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 30262 invoked by uid 89); 28 May 2019 15:16:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=explain X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 May 2019 15:16:39 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CCDC6306CA50; Tue, 28 May 2019 15:16:27 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-52.ams2.redhat.com [10.36.116.52]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 590CBEC16A; Tue, 28 May 2019 15:16:26 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x4SFGOAV029014; Tue, 28 May 2019 17:16:24 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x4SFGKiZ029013; Tue, 28 May 2019 17:16:20 +0200 Date: Tue, 28 May 2019 15:31:00 -0000 From: Jakub Jelinek To: "H.J. Lu" Cc: GCC Patches , Uros Bizjak , Jan Hubicka , =?utf-8?B?5YiY6KKL6byg?= Subject: Re: V2 [PATCH] i386: Insert ENDBR for NOTE_INSN_DELETED_LABEL only if needed Message-ID: <20190528151620.GM19695@tucnak> Reply-To: Jakub Jelinek References: <20190215041332.24720-1-hjl.tools@gmail.com> <20190216150211.GA13329@gmail.com> <20190528085725.GF19695@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg01836.txt.bz2 On Tue, May 28, 2019 at 08:10:19AM -0700, H.J. Lu wrote: > On Tue, May 28, 2019 at 1:57 AM Jakub Jelinek wrote: > > > > On Sat, Feb 16, 2019 at 07:02:11AM -0800, H.J. Lu wrote: > > > > For NOTE_INSN_DELETED_LABEL, we should check if forced_labels to see > > > > if its address is taken. Also ix86_init_large_pic_reg shouldn't set > > > > LABEL_PRESERVE_P (in_struct) since NOTE_INSN_DELETED_LABEL is suffcient > > > > to keep the label. > > > > Can you explain when is it ever needed to emit ENDBR on > > NOTE_INSN_DELETED_LABEL? Only labels that are proven not to be ever > > branched to are turned into deleted labels, so I think the right answer is > > never emit any ENDBR on those... > > > > This condition is checked by gcc.target/i386/cet-label-5.c in the > patch. For > > void * > func (void) > { > return &&bar; > bar: > return 0; > } > > we generate: > > (note/s 4 2 10 2 ("bar") NOTE_INSN_DELETED_LABEL 2) > (insn:TI 10 4 11 2 (set (reg/i:DI 0 ax) > (label_ref:DI [4 deleted])) > "/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/cet-label-5.c":13:1 > 66 {*movdi_internal} > (nil)) > (insn 11 10 20 2 (use (reg/i:DI 0 ax)) > "/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/cet-label-5.c":13:1 > -1 > (nil)) We shouldn't generate ENDBR in that case, nothing can goto to bar (otherwise it would remain a normal label, not a deleted label). Jakub