On Jul 21, 3:13 pm, Eyahlin <amost...@[EMAIL PROTECTED]
> wrote:
> 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!
Hi Allan,
While the AST LCC IR is suitable for optimizations like algebraic
simplifications and CSE, it isn't generally very optimization
friendly. You are better off writing a tree walker and emit your 3-
address IR and write optimization p***** over them. In this case you
will obviously lose the retagetability lburg provides, but mapping 3-
address IR to DLX machine code should be fairly trivial. If you are
adventurous you can use lburg as your tree walker and experiment
writing an ir.md to emit your machine-independent 3-address IR into
memory(with a few hacks in emitcode() I think - sorry it was a long
time ago!). In this case, you still need to figure out how to create
BB and CFG - this will need modifications in reduce() - everytime you
hit a if-else or loop boundary etc you need to create new BB etc. You
can write your optimizations, coloring allocator, list scheduler etc
etc to work on this. All these are more hacks than clean solutions, so
I think writing a tree walker and a new optimizing back-end is the
best solution.
Does gcc have an option to generate code for DLX? If so, you can write
a C generating back end for lcc - c.md and compile it using gcc. This
is only good if you need practice writing md files for lburg!
T.
|
