[M3devel] comparisons vs. subranges

Tony Hosking hosking at cs.purdue.edu
Sat Mar 13 19:03:18 CET 2010


Jay,

I am disturbed that you are inserting optimisations into the front-end that don't really belong there.  The front-end is responsible for semantics and not optimisation. It was never designed to be an optimising compiler.  There are better ways to go about working in optimisation, but I would hate to muddy the waters of the front-end the way you seem to intend.   Let's not go down this path until there is consensus!   One approach would involve communicating more information to the "back"-ends (actually, the gcc back-end should be considered a middle-end from the global perspective of optimising compilers).  For example, the back-ends gets very little in the way of type information (as you note w.r. to CARDINAL).  In any case, I suggest that you not obsess about performance right now but simply concentrate on correctness in your backend.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 13 Mar 2010, at 05:19, Jay K wrote:

> <*UNUSED*>PROCEDURE CardinalGE0(a:CARDINAL):BOOLEAN=BEGIN RETURN a>=0; END CardinalGE0;
> <*UNUSED*>PROCEDURE CardinalEQN1(a:CARDINAL):BOOLEAN=BEGIN RETURN a=-1; END CardinalEQN1;
> 
>  
> Seems to me, the front end should notice these.
> The first should always be TRUE.
>    And possibly, possibly warn.
> The second should always be FALSE.
>    And possibly, possibly warn.
>  
> "Generic" programming often hits this sort of thing though, a good reason not to warn.
> Programmer might also be working with existing code and have changed INTEGER to CARDINAL.
>   Or be defending against future maintainers changing CARDINAL to INTEGER.
>  
>  
> The backend isn't give enough information, because CARDINAL = INTEGER as far
> as it is told. Due to the half range of CARDINAL and LONGCARD, that isn't wrong.
> The only way to get unsigned types is to use ADDRESS from what I see.
>  
>  
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100313/67218c4d/attachment-0002.html>


More information about the M3devel mailing list