Re: [PATCH] Improve PR30911 and PR31023, Ada and VRP

[Richard Guenther <rguenther at suse dot de>]

On Mon, 31 Mar 2008, Richard Kenner wrote:

> I'm sorry for the late response: I'm travelling at the moment.
> 
> > > That's not correct.  Either a object is "invalid" or is bounded by the
> > > ranges of the subtype.  And "invalid" is a property that VRP could
> > > potentially detect (it's mostly a static property).
> > 
> > But validness is only determined by bounds checking on the base type,
> 
> Certainly not!  Were that the case, then my statement would have been
> meaningless.  "Validity" is a completely *independent* status of an object.
> Yes, if there's a validity test, you know that the object is subsequently
> valid, but the converse is *not* true.

[...]

Note that it is completely meaningless what "Valid" or "Invalid" is.
The point I'm trying to make is that the middle-end semantics of
an integral sub-type cannot be "whatever Ada requires for its
currently enabled checking mode".  If Adas requirements (or "wants"
for optimal optimization) differ with frontend settings then it
has to emit different IL for the middle-end for the different
semantics it wants.

Thus, at the moment the middle-end cannot assume anything about
the range of a variable in a sub-type just because that variable
is in that sub-type.  It _can_ do so for variables in base-types.
Conversions to/from sub-types to their base-type do not create
code thus those conversions are basically useless.  Due to this
belief various "strange" things happen, such as creating
arithmetic in sub-types by fold, building of out-of-range
integer constants in sub-types, etc.

So I see only harm in the current non-existing middle-end semantics
of integral sub-types.  Thus I recommend to disallow using them
for variables exposed to the middle-end.

Now what I ask the Ada guys for:  please define the semantics
of sub-types for the middle-end.  Stick to _one_ semantics, independent
of whatever mode the Ada frontend is in, and adjust the Ada frontend
to emit code that is safe under these semantics.

Is this too much asked?

My plan to get rid of subtypes in the middle-end (and to sanitize other
types as well) would be to add a debug_type field to all DECL nodes
and at gimplification time do

  debug_type = type;
  type = make_middle_end_type (debug_type);

this has as a prerequesite mandatory gimplifying in unit-at-a-time mode.
Once we emit debug-info early for DECLs we can make debug_type reference
a dwarf DIE instead of the original type tree.

Thanks for reading this far,
Richard.