Eyahlin wrote:
> Hi!
>
> I, too am currently coding a compiler for a DLX machine. I plan to use
> LCC 3.6's front end and do some machine-independent optimizations
> before going to the back end. I'm having some problems, though with
> LCC's intermediate code. To quote page 99 in Fraser and Hanson's
> companion book:
>
> "Some compiler interfaces emit abstract machine code, which resembles
> an assembler code for a fictitious machine. The front end emits code
> for the abstract machine, which the back end reads and translates it
> into target code. Abstract machines decouple the front and back ends,
> and make it easy to insert extra optimization p*****, but the extra I/
> O and structure allocation and initialization take time. lcc's tightly-
> coupled interface yields efficient, compact compilers, but it can
> complicate maintenance because changes to the front end may affect the
> back ends."
>
> It's really too bad LCC doesn't emit abstract machine code, beacuse if
> it were, we could easily tap the intermediate code data structure at
> one point and do optimizations there. However, that really isn't the
> case, so I had to trace LCC's program execution and find out at which
> point I could delineate the front and backe ends; i.e., where control
> calls the target-independent modules like mips.c or symbolic.c.
>
> Mr. Navia, I've read analysis.c in LCC-WIN32's source distribution,
> and I saw that you created the control flow graph (CFG) from the
> external data structure codehead. This is also what I've come across
> as I traced through LCC's compilation process. I saw that gencode()
> and emitcode() read the "intermediate code" from codehead, so I guess
> it must follow that all machine-independent optimizations should
> manipulate codehead. However, the DAGs don't seem to be all stored in
> codehead in only one place, as the codehead still further separates
> the codes into compound statements, with one Gen forest allocated for
> each. This kind of complicates the optimizations I'm trying to perform
> to codehead, since I need to access the whole IR all in one place, and
> not only across compound statements. Also, modifying the Gen forests
> in different places in codelist may give problems when codehead enters
> code generation, as there are other kinds in between Gen, Label and
> Jump, such as Defpoint and Blockbeg. Is there a way to "see" the whole
> IR in one place, perform optimizations to it, and not disturb
> codehead's structure in the process? Or are you, perhaps looking at
> the situation in a different way and have a better solution to it
> altogether?
>
> All I really want to do is to perform machine-independent
> optimizations, such as control flow analysis, strength reduction,
> etc., before proceeding to the back end. The data structure I should
> tap should ideally be a global one, so it could be manipulated by any
> module outside of dag.c. However, the optimizations shouldn't destroy
> the code sequence and structure that it can no longer be understood by
> the code generation interface. Any suggestions on which data structure
> to tap, and if your answer's codehead as well, is there a way to
> optimize it without screwing up its structure?
>
> Thank you all in advance. We're all in this compiler business, so
> let's help each other out! :)
>
> Allan
>
Hi Allan
I haven't distributed the source of lcc-win32 since several years now.
It is kind of tricky since the separation from machine description,
front end and back end is not very clean, and you have to understand the
whole program before you can realyy mdoify that stuff. I have developed
a peephole optimizer for lcc-win32? and made quite a few other
optimizations.
Control flow analysis/strength reduction and other "advanced" stuff are
not very im****tant from my point of view. What machine is your
"DLX" ??? Do you really need optimizations at that level?
Or it would be much better to concentrate into a peephole?
It depends.
|
