Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

    The Ada front end works by doing an unchecked conversion of X to
    t'Base, followed by a range check. The issue is to stop range
    propagation through the unchecked conversion.

And as we discussed on the phone, the core of the problem is that Gigi
treats unchecked conversions of numeric types as if they were normal
conversions (in order to make them work for different size types) and
GCC is (properly) propagating information through those conversions.

What has to happen is that we need some sort of way of indicating that it's
not permissible to derive information through a particular conversion.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VA

[Kai Henningsen]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner)  wrote on 12.08.05 in <10508121750.AA15217@vlsi1.ultra.nyu.edu>:

> What has to happen is that we need some sort of way of indicating that it's
> not permissible to derive information through a particular conversion.

That may be the only practical solution, but it seems to me it's not the  
perfect solution.

The point is that there are two different kinds of value range  
calculations. You have value range information from program flow, and you  
have value range information from types.

You want 'Valid optimization to ignore range information from types,  
because that's what you're checking for in the first place.

On the other hand, you *want* to use range information from program flow.  
For example, if you just assigned a constant, you *know* the exact range  
of the thing. Or maybe you already passed a program point where any out-of- 
range value would have been caught by an implicit 'Valid. It could  
optimize away a lot of implicit 'Valid checks done, say, on the same  
variable used as an array index multiple times.

Now that is certainly nontrivial to implement, and may not be worth it for  
gcc. But I believe it would be better than the other way.

MfG Kai

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VA

[Laurent GUERBY]

Isn't it possible to attach some information on a comparison
statement that tells code generation never to never
optimize away this particular comparison even if it
seems to be able to prove it is always true or false?
(just like volatile does for memory read)

For code executed after this kind of comparison code generation (except
other of such comparison) can of course assume information gained from
the comparison, so we get the best of both world.

Laurent

On Fri, 2005-08-12 at 22:08 +0200, Kai Henningsen wrote:
> kenner@vlsi1.ultra.nyu.edu (Richard Kenner)  wrote on 12.08.05 in <10508121750.AA15217@vlsi1.ultra.nyu.edu>:
> 
> > What has to happen is that we need some sort of way of indicating that it's
> > not permissible to derive information through a particular conversion.
> 
> That may be the only practical solution, but it seems to me it's not the  
> perfect solution.
> 
> The point is that there are two different kinds of value range  
> calculations. You have value range information from program flow, and you  
> have value range information from types.
> 
> You want 'Valid optimization to ignore range information from types,  
> because that's what you're checking for in the first place.
> 
> On the other hand, you *want* to use range information from program flow.  
> For example, if you just assigned a constant, you *know* the exact range  
> of the thing. Or maybe you already passed a program point where any out-of- 
> range value would have been caught by an implicit 'Valid. It could  
> optimize away a lot of implicit 'Valid checks done, say, on the same  
> variable used as an array index multiple times.
> 
> Now that is certainly nontrivial to implement, and may not be worth it for  
> gcc. But I believe it would be better than the other way.
> 
> MfG Kai
> 

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VA

[Mike Stump]

On Aug 12, 2005, at 3:45 PM, Laurent GUERBY wrote:
> Isn't it possible to attach some information on a comparison
> statement that tells code generation never to never
> optimize away this particular comparison even if it
> seems to be able to prove it is always true or false?

Cough, hack, ick.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VA

[Robert Dewar]

Mike Stump wrote:
> On Aug 12, 2005, at 3:45 PM, Laurent GUERBY wrote:
> 
>> Isn't it possible to attach some information on a comparison
>> statement that tells code generation never to never
>> optimize away this particular comparison even if it
>> seems to be able to prove it is always true or false?
> 
> 
> Cough, hack, ick.

i really think the better hack is one that says
do not propagate type range info through a
conversion, or perhaps says "drop any information you think
you have deduced about the range of this expression, if
either

a) that info comes from type range analysis

or

b) u do not know where it came from

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VA

[Robert Dewar]

Kai Henningsen wrote:

> The point is that there are two different kinds of value range  
> calculations. You have value range information from program flow, and you  
> have value range information from types.
> 
> You want 'Valid optimization to ignore range information from types,  
> because that's what you're checking for in the first place.
> 
> On the other hand, you *want* to use range information from program flow.  
> For example, if you just assigned a constant, you *know* the exact range  
> of the thing. Or maybe you already passed a program point where any out-of- 
> range value would have been caught by an implicit 'Valid. It could  
> optimize away a lot of implicit 'Valid checks done, say, on the same  
> variable used as an array index multiple times.
> 
> Now that is certainly nontrivial to implement, and may not be worth it for  
> gcc. But I believe it would be better than the other way.

right, i agree completely with this analysis, very nice clear
statement. Now how difficult is this to implement?