This is the mail archive of the
mailing list for the GCC project.
Re: Handling non-constant bounds in extract_range_from_cond
- From: Laurent GUERBY <laurent at guerby dot net>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 29 Nov 2004 23:23:02 +0100
- Subject: Re: Handling non-constant bounds in extract_range_from_cond
- References: <10411292219.AA02138@vlsi1.ultra.nyu.edu>
On Mon, 2004-11-29 at 23:19, Richard Kenner wrote:
> Somehow I just don't like the idea of purposely generating something
> for the sole purpose of not allowing an optimizer to see it. It's
> indeed possible, but it seems like overkill to me for an optimization
> that's not likely to be all that useful.
But the whole point of 'Valid is to have a way to tell the compiler to
forget about these optimizations, so performance isn't really
an argument. It is the *only* way to do that within Ada
- may be also with Import/Export tricks and assuming the
compiler won't do inlining but that's kind of "outside" Ada.
> And, as a programmer, what do you think about the "X in Foo" operation?
> Would you expect that to be the same as X'Valid or would you be
> comfortable viewing that as a bounded error?
X in Foo can be optimized at will, just as X <= B, etc...
X'Valid shoud not, that's the usefullness of this construct.
AARM 13.9.2(3) note a says:
3.a Ramification: Having checked that X'Valid is True, it is safe to
read the value of X without fear of erroneous execution caused by
abnormality, or a bounded error caused by an invalid representation.
Such a read will produce a value in the subtype of X.
If you optimize, that's not safe anymore.