[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