Re: Compiling for DSP chips

>pardo@cs.washington.edu (David Keppel) writes:
>>[Tell gcc hard regs clobbered -> optimize around them.]
>>[If md knows about magic instructions can optimize over them,
>> even the compiler doesn't kow how to emit them.]


In article <7949@scolex.sco.COM> Sean Fagan <seanf@sco.COM> writes:
>[For example, `_inline_memcpy', `__inline_sin'.]


Gcc has the capability to do two things:


* Register allocation and code motion of `asm'-ed stuff. That's
    what Sean described.


* Optimization of instructions that the compiler doesn't know
    how to emit, provided the instructions are in the machine
    description.


I'm much fuzzier on the latter, but I think it works something
like this:


* The machine description contains information about how to
    emit the "div" and "mod" instructions.


* The machine description contains a description of a peephole
    optimization that says something like ``if there's a "div"
    instruction next to a "rem" instruction, and they operate on
    the same operands, then trash the "div" instruction and get
    the results from the "rem" which computes "div" as a side-
    effect".


* The compiler has no way of producing a "rem" instruction.


* The user defines an "asm" that emits a "rem" instruction.


* If the peephole matches, the optimization occurs, even tho'
    the compiler never emitted the "rem".


I don't think this feature is used often on most targets because C
and the gcc IR are pretty well matched. However, I could immagine
the optimizations to be useful on e.g., DSP machines where there are
some machine primitives that match poorly with C semantics but for
which various optimizations could be done with neighboring
instructions.


;-D on ( Looking for a few good digital signals ) Pardo
--
pardo@cs.washington.edu
        {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
--

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