On 09/20/2016 04:38 AM, Bernd Schmidt wrote:
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
RETURN or a SIMPLE_RETURN rtx.
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.
But what this doesn't answer is why we stuff RETURN/SIMPLE_RETURN into
the JUMP_LABEL field of a return. I simply can't remember any rationale
behind that.
I suspect that if we dig further, we'll find that we can accomplish
whatever the goal was behind that decision in a way that easily works in
a world where we have separated rtx objects from objects that are part
of the insn chain.
Just to be clear, I don't see us going to a world where everything we
have as an rtx today is a statically typed object. But there are things
that I think make sense to carve out, the most obvious being objects
which are part of the insn chain.
jeff
