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
|
