[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [f-cpu] dynamic code reuse (fwd)



  I guess taht the answer from Devik was ment to
be sent to the list, so I just forward it. By the
way, thanx for the answer!

Regards,
     Martin

---------- Forwarded message ----------
Date: Tue, 9 Dec 2003 14:11:04 +0100 (CET)
From: devik <devik@cdi.cz>
To: Martin Vahi <martinv@physic.ut.ee>
Subject: Re: [f-cpu] dynamic code reuse

> > To answer your question it will be very hard to add to gcc.
> > One need to decide that "this" is block of code which will
> > probably produce repetable result ....
>
>   I wonder, if it could be written directly in to the
> compiler, that "please save those results, as we might reuse
> them", and in that case, couldn't that be just a matter of
> software, so that the optimization can be implemented on
> almost any CPU with some registers to "spare"?

With the difference that such instruction would allow you to
catch differing inputs to the block. Like:

int f(int x) {
        int i=0,j=0;
        while (i++<1000) j += x/((i&3)+1);
        return j;
}

Gcc will now expand to code which will do 1000 cycles each
12 x86 insns long including shift & div. Clever compiler
knows that i&3 can have only 4 values (in fact gcc knows
it as it computes ranges of all expressions) and precompute
these 4 divisions.
However it will not be exception precise because should we
hit division by zero (we will not) then exception would be
thrown too early.
But we can use that Nico's "caching" insn to decide at runtime
whether result of x/((i&3)+1) is known for given i and reuse it.
For code above on it would mean about 3 times faster run (less divs).

I have the same opinion as Martin Vahi that compiler good enough
to spot places where to place such insn should be able to such
code transformations (like exception aware GCSE) which would
render such insn almost unuseful.

devik
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/