RTL type checking and '0' format codes

RTL type checking and '0' format codes

[Zack Weinberg]

I have been looking into implementing type checking for RTL, much like
the type checking for trees we already have.  The various XFOO
macros would check the slot against the format, and abort if it was
invalid.

'0' format codes cause problems.  '0' is documented to mean that the
slot is only valid in a specific pass, and should be ignored
otherwise.  They aren't initialized in gen_rtx_FOO, and they're
ignored in generic copy-or-examine-RTL code.

Most '0' slots are always addressed with a specific type, but the
information on their type isn't in the format.  LABEL_NUSES,
JUMP_LABEL, LABEL_REFS, LABEL_NEXTREF, and CONTAINING_INSN are like
this.  We would like to type check them.

In NOTEs, '0' means that the slot can contain any of five different
things depending on what sort of NOTE it is.

In ADDRESSOF, '0' is used because someone was too lazy to fix
everything to understand 't'. :)


What I'd like to do is eliminate '0' in favor of a set of codes that
carry type info and indicate that this slot is only valid sometimes.
We need analogues for 's', 'i', and 'e'.  We also need a type code for
bb info.  I'd use 'F', 'I', 'R', and 'B' respectively (F for file, R
for reference).  In addition, I want to replace NOTE with a family of
RTL types, one for each possible meaning of a negative
NOTE_LINE_NUMBER.

This is a fairly major undertaking, but doesn't require great skill,
and I've already found a few bugs while doing the feasibility study.
The benefits of type-checking RTL are obvious.

Comments?

zw

Re: RTL type checking and '0' format codes

[Jeffrey A Law]

  In message < 199908162310.QAA09148@zack.bitmover.com >you write:
  > 
  > I have been looking into implementing type checking for RTL, much like
  > the type checking for trees we already have.  The various XFOO
  > macros would check the slot against the format, and abort if it was
  > invalid.
Excellent!  We actually had someone working on this earlier, but we could never
get a copyright assignment for the work, so it never got integrated.

  > '0' format codes cause problems.  '0' is documented to mean that the
  > slot is only valid in a specific pass, and should be ignored
  > otherwise.  They aren't initialized in gen_rtx_FOO, and they're
  > ignored in generic copy-or-examine-RTL code.
Right.

  > Most '0' slots are always addressed with a specific type, but the
  > information on their type isn't in the format.  LABEL_NUSES,
  > JUMP_LABEL, LABEL_REFS, LABEL_NEXTREF, and CONTAINING_INSN are like
  > this.  We would like to type check them.
I'd punt initially and get the basic checking code installed.  Then return
to this issue.

jeff

Re: RTL type checking and '0' format codes

[Zack Weinberg]

Jeffrey A Law wrote:
>   In message < 199908162310.QAA09148@zack.bitmover.com >you write:
>   > 
>   > I have been looking into implementing type checking for RTL, much like
>   > the type checking for trees we already have.
[...]
>   > Most '0' slots are always addressed with a specific type, but the
>   > information on their type isn't in the format.  LABEL_NUSES,
>   > JUMP_LABEL, LABEL_REFS, LABEL_NEXTREF, and CONTAINING_INSN are like
>   > this.  We would like to type check them.
> I'd punt initially and get the basic checking code installed.  Then return
> to this issue.

Agree, and I'm actually testing a patch that does this even as we
speak.  It has knock-on effects all over the code and my patch backlog
is getting quite large, so I won't be able to submit it for awhile.

zw

Re: RTL type checking and '0' format codes

[Jeffrey A Law]

  In message < 199908162310.QAA09148@zack.bitmover.com >you write:
  > 
  > I have been looking into implementing type checking for RTL, much like
  > the type checking for trees we already have.  The various XFOO
  > macros would check the slot against the format, and abort if it was
  > invalid.
Excellent!  We actually had someone working on this earlier, but we could never
get a copyright assignment for the work, so it never got integrated.

  > '0' format codes cause problems.  '0' is documented to mean that the
  > slot is only valid in a specific pass, and should be ignored
  > otherwise.  They aren't initialized in gen_rtx_FOO, and they're
  > ignored in generic copy-or-examine-RTL code.
Right.

  > Most '0' slots are always addressed with a specific type, but the
  > information on their type isn't in the format.  LABEL_NUSES,
  > JUMP_LABEL, LABEL_REFS, LABEL_NEXTREF, and CONTAINING_INSN are like
  > this.  We would like to type check them.
I'd punt initially and get the basic checking code installed.  Then return
to this issue.

jeff

RTL type checking and '0' format codes

[Zack Weinberg]

I have been looking into implementing type checking for RTL, much like
the type checking for trees we already have.  The various XFOO
macros would check the slot against the format, and abort if it was
invalid.

'0' format codes cause problems.  '0' is documented to mean that the
slot is only valid in a specific pass, and should be ignored
otherwise.  They aren't initialized in gen_rtx_FOO, and they're
ignored in generic copy-or-examine-RTL code.

Most '0' slots are always addressed with a specific type, but the
information on their type isn't in the format.  LABEL_NUSES,
JUMP_LABEL, LABEL_REFS, LABEL_NEXTREF, and CONTAINING_INSN are like
this.  We would like to type check them.

In NOTEs, '0' means that the slot can contain any of five different
things depending on what sort of NOTE it is.

In ADDRESSOF, '0' is used because someone was too lazy to fix
everything to understand 't'. :)


What I'd like to do is eliminate '0' in favor of a set of codes that
carry type info and indicate that this slot is only valid sometimes.
We need analogues for 's', 'i', and 'e'.  We also need a type code for
bb info.  I'd use 'F', 'I', 'R', and 'B' respectively (F for file, R
for reference).  In addition, I want to replace NOTE with a family of
RTL types, one for each possible meaning of a negative
NOTE_LINE_NUMBER.

This is a fairly major undertaking, but doesn't require great skill,
and I've already found a few bugs while doing the feasibility study.
The benefits of type-checking RTL are obvious.

Comments?

zw

Re: RTL type checking and '0' format codes

[Zack Weinberg]

Jeffrey A Law wrote:
>   In message < 199908162310.QAA09148@zack.bitmover.com >you write:
>   > 
>   > I have been looking into implementing type checking for RTL, much like
>   > the type checking for trees we already have.
[...]
>   > Most '0' slots are always addressed with a specific type, but the
>   > information on their type isn't in the format.  LABEL_NUSES,
>   > JUMP_LABEL, LABEL_REFS, LABEL_NEXTREF, and CONTAINING_INSN are like
>   > this.  We would like to type check them.
> I'd punt initially and get the basic checking code installed.  Then return
> to this issue.

Agree, and I'm actually testing a patch that does this even as we
speak.  It has knock-on effects all over the code and my patch backlog
is getting quite large, so I won't be able to submit it for awhile.

zw