Re: [PATCH] checking version of rtl flag access macros

[Janis Johnson <janis187 at us dot ibm dot com>]

On Mon, May 06, 2002 at 02:45:31PM -0700, Richard Henderson wrote:
> On Mon, May 06, 2002 at 01:39:08PM -0700, Janis Johnson wrote:
> >  The flag checking doesn't add a noticeable
> > amount of time to a mainline bootstrap and test run.
> 
> Leave it separate then, but do add the configure switch and default on.

OK.  Can that be done as a separate patch after this one is in?

> 
> > +#define RTX_INTEGRATED_P(RTX)	\
> > +  (RTL_FLAG_CHECK8((RTX), INSN, CALL_INSN, JUMP_INSN, INSN_LIST,	\
> > +		   BARRIER, CODE_LABEL, CONST, NOTE)->integrated)
> 
> INSN_LIST?  Really?
> 
> > +#define RTX_FRAME_RELATED_P(RTX)	\
> > +  (RTL_FLAG_CHECK5((RTX), INSN, CALL_INSN, JUMP_INSN, BARRIER,	\
> > +		   SET)->frame_related)
> 
> A barrier cannot be frame-related.  And, frankly, I have a hard time
> imagining that JUMP_INSN or CALL_INSN could either.
> 
> SET is right out.
> 
> > +#define CONST_OR_PURE_CALL_P(RTX)	\
> > +  (RTL_FLAG_CHECK3((RTX), CALL_INSN, NOTE, EXPR_LIST)->unchanging)
> 
> Why would this be called on anything other than CALL_INSN?
> 
> I suppose you put these in for a reason, i.e. some bootstrap did
> fail.  I suppose we can put the patch in anyway and address each
> of the errors separately in turn.

That's why I said that some of the uses look rather dubious, but these
are really all used.  Finding them is easy; just turn on the checks,
remove codes from the list, and see what blows up.

I'm worried about turning the checks on before people have tried them
on other architectures (and with Ada), because I'm sure there are other
strange things that will turn up that will break bootstraps or cause
tests to fail.  It would be better to find those out by volunteers at
first, rather than turning them on all at once.

Janis