New const function detection code and infinite loops.

Jan Hubicka jhub6202@ss1000.ms.mff.cuni.cz
Tue Aug 31 23:20:00 GMT 1999


On Mon, 23 Aug 1999, Mark Mitchell wrote:

> >>>>> "Jan" == Jan Hubicka <jhub6202@ss1000.ms.mff.cuni.cz> writes:
> 
>     Jan> My current implementation is to handle "pure" functions as
>     Jan> const functions with one extra input parametter (memory). So
>     Jan> function will get removed too.
> 
> But that's a bug.  This program is guaranteed not to call abort in
> ANSI C:
> 
>   void f() {
>     while (1);
>   }
This is not "pure" function in definition I use (I agree that current
detection code is broken in the same way as "const" detection).
But "pure" function in my definition is function that don't have side
effects and as Jeff noted, looping forever is side effect.
> 
>   int main () {
>     f();
>     abort ();
>   }
> 
> I think we need to find a way to solve this problem.
Thats why I've done the finitarity prooving function and why I suggest
futher divide functions into two classes (known to be finite and
pure/const (with pure or const attribute or detected by the testing
function) and known to be deterministics and not writting to memory
(easilly detectable by the current code we have)).

We can keep handling of pure/const functions as we do.
The functions with no side effects may just have this information attached
with tthem, normal non-cseable call will be emmited, but cse will simply
look at additional informaton available for the call (I believe later
we keep track of more such hints as I sugested in my other email)
and not flush the tables.
So code will be still improved, but function will not be subject of
redudnant calls removing/loop optimizations as CONST_CALL functions are.

I think looping forever functions are more hypotetcial then practical
case, we don't need special atribute to represent such functions in
sources.
On the other hand, halting problem is undecidable (well, in fact
theoretically decidable in our model of computation because our machines
are finite), so when we can't prove finitarity we can still attach such
attribute and improve code.

Honza
> 
> --
> Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com
> 



More information about the Gcc mailing list