Re: LCC Optimizations: Where is the IR to optimize?



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 passes, 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 important 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.

.



Relevant Pages

  • LCC Optimizations: Where is the IR to optimize?
    ... too am currently coding a compiler for a DLX machine. ... LCC 3.6's front end and do some machine-independent optimizations ... we could easily tap the intermediate code data structure at ... external data structure codehead. ...
    (comp.compilers.lcc)
  • Re: WaitForSingleObject() will not deadlock
    ... One is to hijack the semantics of volatile to disable compiler optimizations ... and otherwise let the compiler to agressive optimization. ... Agressive optimizations are the ones that work on the edge of the semantics of the ... Because the compiler can see into lock and unlock, it is able to reduce f ...
    (microsoft.public.vc.mfc)
  • Re: WaitForSingleObject() will not deadlock
    ... represent an incorrect implementation of the language. ... the *compiler* does not guarantee this. ... but to state it in terms of the execution instead of the formal semantics of the language ... as long as the optimizations do not change the semantics of the language). ...
    (microsoft.public.vc.mfc)
  • Re: optimized code
    ... > loop invariants are handled by the JIT not by the compiler fron-ends. ... generates the best optimized MSIL of any of the .NET languages. ... standard native code optimizations on MSIL code. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: c compilation - gcc vs visual c
    ... I recently compiled a numerically intensive c project under cygwin gcc ... MS focuses a lot more on specific optimizations, ... the simplest approach, however (and the one I currently use in my compiler), ... (silly code), are ones I focus on fixing. ...
    (comp.lang.c)