On 09/20/2016 01:16 AM, Segher Boessenkool wrote:
On Mon, Sep 19, 2016 at 06:07:46PM -0400, Trevor Saunders wrote:
- JUMP_LABEL can be a return which is not an insn.  That also seems
  like something that should be improved at some point.
The JUMP_LABEL field within a JUMP_INSN?  That sounds like a bug.

yes, see the comment before the declaration of rtx_jump_insn::jump_label ()
it can be either a possibly deleted label, or a RETURN or SIMPLE_RETURN
expression.  Memory usage concerns aside its a tempting design to
change, but at the moment itts definitely intended to work this way,
there's plenty of code that checks ANY_RETURN_P (JUMP_LABEL (x)).

Yes.  But rtl.texi still says:

  Return insns count as jumps, but since they do not refer to any
  labels, their @code{JUMP_LABEL} is @code{NULL_RTX}.

And the comment at the top of jump.c:

   Each CODE_LABEL has a count of the times it is used
   stored in the LABEL_NUSES internal field, and each JUMP_INSN
   has one label that it refers to stored in the
   JUMP_LABEL internal field.  With this we can detect labels that
   become unused because of the deletion of all the jumps that
   formerly used them.  The JUMP_LABEL info is sometimes looked
   at by later passes.  For return insns, it contains either a

It's intentional, and really there's nothing wrong with it, or with operands[] containing CODE_LABELs. The problem is trying to force a static type system onto a dynamically typed data structure.


Reply via email to