RE: porting of gcc peephole opt

> Hello, I have a question regarding gcc: If I reuse gcc
> peephole opt in
> another compiler as an independent phase, what is the main work to do?


ebo_special is starting to depress me as well, I just can't find the time to
rewrite it :)
(GNU comment: this is *still* freedom-compliant, right?)


> My current understanding is that since the peephole rules are
> defined in
> this way:
> (define_peephole
> [insn-pattern-1
> insn-pattern-2
> ...]
> "condition"
> "template"
> "optional insn-attributes"),
>
> we need first to translate our own code into RTL, then port
> the related
> compilation component to use the above rule, after that, translate the
> resulting RTL to our code again.
>
> Any comment please?


Since define_peephole generates assembly strings and runs as a final
compilation action, you might want to take a look in define_peephole2
(RTL to RTL transformation). I just skimmed gcc-3.3 and it seems to
be performed by peephole2_optimize in recog.c, but I'm afraid that it
will never work with OP * due to the recursive nature of rtx data
type. If you have a machine description file, you would just need to
define your peephole patterns there (otherwise the compiler will
probably die due to unrecognized insn error). Translating from one IR
to another is never an easy task (especially when it is discouraged by
the FSF) because even if you can map your compiler instruction to GCC
pattern and vice versa, you still have to deal with uninitialized
variables that could have been properly set only by a complete GCC
running from main() . In addition, an rtx pattern usually has
multiple alternatives, so accurate mapping of OP * to rtx and back can
be done only after register allocation.


Barak.

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