Re: [patch] for PRs 27639 and 26719

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

> Some specific questions which should be documented somewhere: what
> does it mean for TREE_TYPE of an INTEGER_TYPE to be non-NULL?  When
> does language independent code need to look at the TREE_TYPE field?
> What guarantees do we have for the TREE_TYPE field: e.g., will it
> always be INTEGER_TYPE?  What is the relationship between the
> TYPE_PRECISION, TYPE_SIZE, and TYPE_MODE of the two types?

Agreed that this needs to be better documented but one answer is that
TREE_TYPE of an INTEGER_TYPE can also be an ENUMERAL_TYPE.

> Your statement suggest that we don't need to care about subtypes in
> the middle-end, which implies that we never need to look at the
> TREE_TYPE field (except for debug info, of course).  Yet I know that
> is not true, because we have code that does look at that field, e.g.,
> build_range_check, int_fits_type_p.  And there is apparently in issue
> in the loop optimizers.  So when does the middle-end need to care?

That's a hard one.  I'd like to argue that it never should expect,
as you say, for debug info.  The single exception is that if it's trying
to guess the bounds of the subtype and finds them variable, it can go
back to the base type for the (looser) bound.  build_range_check is
somewhat special in that it's sort of part of the front end interface
and not really middle-end per se (is it ever called after gimplification?)
and likewise, I think for int_fits_type_p.

I'd like to understand the references to the base type in the loop optimizers
because it seems suspicious to me.