over ambitious optimizers

over ambitious optimizers

[Mike Linnig]

Folks,

I compiled the following procedure and discovered that the validated
compiler I was using had optimized away the first assignment of I. I was
really testing something else, but should it have deleted that assignemnt?

I can imagine that the function SOMEINT actually used the value of I in
it's calculation (it would be in the scope of I).

Is this an over ambitious optimizer?

	Mike Linnig,
	Texas Instruments

----------------------------------------------------------------------
PROCEDURE leftside(i: IN OUT integer) IS

TYPE myarray  IS ARRAY(integer RANGE 1..15) OF integer;
anarray: myarray;

FUNCTION someint RETURN integer IS SEPARATE;

BEGIN
  I := 5;	-- OPTIMIZED AWAY !
  anarray(someint) := 3;
  i := 7;
END; 

Re: over ambitious optimizers

[Robert Firth]

In article <8806241657.AA23329@ti.com> linnig@skvax1.csc.ti.COM (Mike Linnig) writes:
   Folks,
   
   I compiled the following procedure and discovered that the validated
   compiler I was using had optimized away the first assignment of I. I was
   really testing something else, but should it have deleted that assignemnt?
   
   I can imagine that the function SOMEINT actually used the value of I in
   it's calculation (it would be in the scope of I).
   
   Is this an over ambitious optimizer?
   
   	Mike Linnig,
   	Texas Instruments
   
   ----------------------------------------------------------------------
   PROCEDURE leftside(i: IN OUT integer) IS
   
   TYPE myarray  IS ARRAY(integer RANGE 1..15) OF integer;
   anarray: myarray;
   
   FUNCTION someint RETURN integer IS SEPARATE;
   
   BEGIN
     I := 5;	-- OPTIMIZED AWAY !
     anarray(someint) := 3;
     i := 7;
   END; 

The optimisation is indeed incorrect.  The function SOMEINT, whose body
is unknown, can legally access the (non-local) variable I, as you state,
and such access should yield the value 5.  This is not an illegal alias,
since the access would use the simple name "I", as declared in the header
of LEFTSIDE.

If the compiler is the one I suspect, the error is in the phase that
performs liveness analysis of variables.  It does not recognise that
a call of a subprogram whose body is in the scope of the variable is
a potential access path to the variable.