Re: An issue for the SC: horrible documentation quality of GCC

[Michael S. Zick <mszick at goquest dot com>]

On Saturday 10 May 2003 11:07 am, David Edelsohn wrote:
> >>>>> Zdenek Dvorak writes:
>
> Zdenek> The sane way
> Zdenek> how to write a compiler is to run these generic passes first, then
> Zdenek> run machine-dependent passes that may eventually fix the mistakes
> Zdenek> the previous optimizations have done (due to their generic ideas
> being Zdenek> not right in some corner cases). This way we would get
> approximately Zdenek> the same results, but in much more transparent way.
>
> 	This assumes that the mistakes can be corrected with a later
> machine-dependent pass, which is not always correct.  Plus it takes more
> compile time to correct the mistakes instead of choosing the correct
> heuristics in the first place.  The generic pass already needs to apply
> *some* heuristic.
>
> David
In support of David's conclusions; given two, simplified, extreme cases:

For a constant value which does not fit within an instruction field of an
instruction that is otherwise required;

Choosing where that constant value will be held during its lifetime is
clearly a hardware dependant decision.

On a 1024 register machine, you would probably choose to keep it
in a register.

On a 3 register machine, then keeping it in a register is probably not
a good choice.  This hardware designer probably has made provisions
to handle this situation ( a fast base page pool, fast stack ops, something).

The initial "generic", "hardware independent" code which does the bulk of
the transformations from source language representations to machine
representations should not be blindly generating any specific choice.

Doing so requires that someone envision, write, and maintain code that
later "undoes" those decisions.  Code which the compiler must execute.

All of which is an argument for the existing "hardware independent" 
transformations WITH consideration of "hardware parameterizations".
(Note the word: "BLINDLY" two sentences above.)

My point here, is that it would be better to strengthen and broaden the
usage of the "hardware parameterizations" in the "generic, hardware
independent" transformations than to rely on later "hardware dependant"
passes (which must be separately envisioned, written, maintained forever
and executed by the compiler) to "clean up" any "bad decisions".

Even to the extent that doing so might have a negative effect on the
generic pass'es performance.  Everything the compiler "gets right" at
this stage eliminates mucho (technical term there) later code.

And, in returning to the subject of this thread, it would be nice if each
function had at least a "statement of intent" at the point of definition.

Mike