Re: Compiling for DSP chips

In article <13148@june.cs.washington.edu> pardo@cs.washington.edu (David Keppel) writes:
>In particular, you can tell GCC that certain hard registers are
>clobbered, so GCC can perform register allocation around those
>instructions.


>If the machine description knows about those
>instructions, then I think that it is also possible to define
>optimizations over those instructions, even if the compiler itself
>doesn't ``know'' how to emit them.


For example:


static inline void *
_inline_memcpy (void *dst, void *src, unsigned int len) {
void *t1, *t2;
unsigned int t3;


__asm volatile ("rep;movsb %0, %1, %2" : "=D" (t1), "=S" (t2), "=c" (t3)
: "0" (dst), "1" (src), "2" (len));
return (temp1);
}


Although gcc does not know what the 'rep;movsb' string means, from the
information I've told it, it knows that it needs to set up three registers
(edi, esi, and ecx), and that they will be clobbered. I have also told it
that the values for those registers will initially be in the parameters dst,
src, and len; but, after the instruction completes, to move them into t1,
t2, and t3, respectively.


Where the optimization comes into effect is that gcc can (and will) emit the
code such that register movement is as minimal as possible (i.e., it will
try to make sure that the values I want to memcpy are already in the
respective registers, if it can). Also, without the 'volatile,' gcc is
likely to get rid of the instruciton completely, if the modified values are
never used (I just tried it, and my trivial case ended up losing the movsb,
since I never used the values!).


Where this can come into play is something like:


static __inline const double
__inline_sin(double x) {
double temp;
__asm ("fsin" : "=f" (temp) : "0" (x));
return (temp);
}


where gcc will get rid of the entire inline function, if it can determine
that none of the values are used.


Incidently, I have yet to see a commercial compiler where I can do this.
It's really a pity, too, since, although the inline assembly syntax is a bit
bizarre, it's far more powerful than the "normal" method of doing it.


--
Sean Eric Fagan
seanf@sco.COM
uunet!sco!seanf
(408) 458-1422
--

Return to the comp.compilers page.
Search the comp.compilers archives again.