From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10247 invoked by alias); 13 Sep 2007 11:20:37 -0000 Received: (qmail 10239 invoked by uid 22791); 13 Sep 2007 11:20:37 -0000 X-Spam-Check-By: sourceware.org Received: from mx-out.libertysurf.net (HELO mail.libertysurf.net) (213.36.80.91) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Sep 2007 11:20:28 +0000 Received: from [192.168.1.3] (91.164.43.253) by mail.libertysurf.net (7.3.118.8) id 46943B0C0066CCE6; Thu, 13 Sep 2007 13:20:19 +0200 From: Eric Botcazou To: Hans-Peter Nilsson Subject: Re: [RFA:] Split REG_LABEL into REG_LABEL_TARGET and REG_LABEL_OPERAND Date: Thu, 13 Sep 2007 13:15:00 -0000 User-Agent: KMail/1.7.1 Cc: gcc-patches@gcc.gnu.org References: <200709130203.l8D236jg010538@ignucius.se.axis.com> In-Reply-To: <200709130203.l8D236jg010538@ignucius.se.axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709131320.42357.ebotcazou@libertysurf.fr> 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: 2007-09/txt/msg01168.txt.bz2 > > You're not updating label_is_jump_target_p to take into account the > > operands of REG_LABEL_TARGET notes, so can't you be creating > > REG_LABEL_OPERAND notes for them? > > (I assume you mean s/can't/shouldn't/ and "REG_LABEL_TARGET > notes for them". If not, please rephrase the question.) Can't the new code in find_reloads create REG_LABEL_OPERAND notes for operands of REG_LABEL_TARGET notes on the same insn, because label_is_jump_target_p only returns true for the JUMP_LABEL? > If there's a problem, the remedy would be to update > label_is_jump_target_p to be less simplified than its heading > says; to handle REG_LABEL_TARGET notes. Yes, that was exactly what I was wondering about. > They aren't supposed to (must not) be handled here. This code > is only for REG_LABEL_OPERAND notes needing to be updated; > non-jump-insns moved around without notes being updated. Same > comment about label_is_jump_target_p maybe being too simple > applies. (Since you have to ask, this function needs a comment > to this effect.) Yes, it's again the non-handling of REG_LABEL_TARGET notes by label_is_jump_target_p that I was thinking of. > It's the core machinery for targets with branch-target > registers, to have the label recorded as a branch target before > further optimizations moves the set and use of that register > apart. Otherwise, those branches will all be treated as > computed jumps. Hm, we'll still have the REG_LABEL_OPERAND note > on the register load, but then again, so we did before too. > I'll check that this still happens and add a comment actually > mentioning "branch-target register"! OK, but IIUC this is a new feature, isn't it? > > Please add a small comment, one can easily think there is a typo in the > > second part of the disjunction: JUMP_LABEL (insn) != label. > > Will do. Thanks. > > "Put in line with jump.c copy by only adding notes for labels actually > > referenced in the insn" but AFAICS mark_jump_label doesn't do that. > > Uhm, it does; it iterates on the insn, and when it finds > LABEL_REFs, it adds unique REG_LABEL_OPERAND notes (and sets the > JUMP_LABEL field and emits REG_LABEL_TARGET notes, but they > weren't the issue here). It no longer emit duplicates. AFAICS it iterates on X, not INSN, and never checks that X is mentioned in INSN like add_label_notes now does. -- Eric Botcazou