Re: Retargetable Compiler Environment for DSPs?

Oliver Wahlen <oliver.wahlen@post.rwth-aachen.de> wrote:
>This is why I find your idea of a modular compiler for all "flavours"
>of DSPs very interesting. The question is if one can find an IR or
>lets better say a set of IR-Levels (HIR,MIR,LIR) that is powerfull
>enough to address all DSP architectural features that are currently
>available. I am interested in your opinion if this is a critical
>issue or if the problem would "only" be to program all the
>optimization and code generation modules and some sort of controller
>for their interaction.
>


    The modern view of compiler design (at least in my opinion) is of
    incremental IR to IR translation. One of the issues discussed is
    SIMD, which as Oliver noted is becoming increasingly popular in
    DSPs (at least small scale SIMD).


    The IR does not have to reflect SIMD in its nodes. Rather, a
    higher level statement is translated into IR targeted at SIMD.
    This may sound like I'm contradicting myself, so let me give an
    example. Consider a Fortran 90 statement like (its been a while
    so please forgive any syntax errors):


        integer A(100), B(100), C(100)


        A = B + C


    In the high level IR this might be represented as


            store
                A
                plus
                    load
                        B
                    load
                        C


    If we have a DSP that has, say, four arithmetic units capable
    of doing four additions at the same time a "strip mining" loop
    must be generated. So the IR above would be translated into
    the lower level IR which included the loop:


        for (i = 0; i < 100; i += 4)
              A(i:i+3) = B(i:i+3) + C(i:i+3)


    Note that such a transformation is specified before the control flow
    graph is generated. Other transformations/optimizations, like
    multiple issue for a VLIW are generated after the flow graph is
    created.


    If a compiler is viewed as a set of components and phases, it should
    be possible to plug in the appropriate pieces without having to
    rewrite large parts of the compiler. This should allow a compiler
    to support a family of related architectures (e.g., RISC processors
    with various architectural features).


    I am less certain of this approach when it comes to a processor like
    the IA64. Certainly the high level parts of the compiler (front
    end, flow graph creation, common subexpression elimination, perhaps
    data dependency analysis) might be reused. But the IA64 seems to
    require a global design after the flow graph is created. I'm not
    sure how reusable such a compiler would be for other processors
    which did not have a similar architecture. So I've been leaning
    toward the idea that one should implement a compiler for the IA64
    and a compiler for other architectures (e.g., classic RISCs and
    DSPs). They might share components, but the demands of optimizing
    for the IA64 seem so unique to that kind of architecture that I'm
    not sure how generalizable the back end beyond the flow graph would
    be. I know that there are compiler groups that plan to share their
    IA64 compiler with other targets. But I'm concerned that this would
    be a maintenance nightmare.


>In how far do you think that "crafted" means writing compiler
>components by hand: You can write a pattern matcher completely by hand
>but you can also generate one based on a pattern matcher description
>(which you wrote by hand).


    I work a lot with the ANTLR parser generator, which among other
    things allows a tree pattern matcher to be built. I'm still
    undecided whether this really saves a lot of time. Certainly I have
    not found a huge difference in productivity and flexibility, as I
    have between a hand written parser and a parser generator created
    parser (e.g., parser generators are much more productive and
    flexible). Whether a tool like ANTLR is used or the tree walker is
    written by hand, the programmer must still define the IR to IR
    translation. So in this sense I mean "by hand". Also, the
    optimization phases much be written and an pattern matching tool
    will not same much time here.


    Ian Kaplan
    iank@bearcave.com
    www.bearcave.com

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