Re: [RFA:] Split REG_LABEL into REG_LABEL_TARGET and REG_LABEL_OPERAND

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> > 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