Thanks for replying!
DLX is a hypothetical machine proposed by Hennessy and Patterson in
their book "Computer Architecture: A Quantitative Approach". It's
supposed to be an educational tool for students taking up a basic
course in computer architecture; to expose them without getting them
lost in the technical details. It's a RISC and is very similar to
MIPS.
I'll be writing a compiler for a 32-bit machine with dual-core
capability, so optimizations are a MUST if I'm to exploit parallelism.
I think peephole optimizations would really help. After all, they work
on the part of the compiler where everything gets integrated again --
the actual generated code. However, from what I've researched, I've
learned that I must implement the dual core optimizations earlier on
in the intermediate code, where independent threads are to be
separated for each processor. One of the requirements for the
splitting of the code is control flow analysis.
I do agree with LCC having an unclean separation between its
optimization parts. Arithmetic Strength Reduction was handled in
simp.c. Common sub-expression elimination was implemented by
converting the AST into a DAG, and then un-DAGging it again for the
optimizer. These optimizations are scope-specific, and they only
optimize mostly on the compound statements level. I need something on
the function level, where all the intermediate code of a function can
all be viewed and rearranged for optimization purposes, reflecting
changes on the symbol tables if necessary.
Since you've successfully coded a way to detect the basic blocks,
could you share the way you've programmed it? I really am not sure
where analysis.c comes in with the other original blocks in LCC-WIN32,
so I don't know at which phase it executes. Right now, it's all
guesses, but I have a hunch that the basic blocks are the ticket to
getting the intermediate code before code generation.
Again, thank you for replying!
|
