🚀 go-pugleaf

On 13 Oct 90 20:43:18 GMT, jlg@lanl.gov (Jim Giles) said:

jlg> From article <PCG.90Oct13114804@odin.cs.aber.ac.uk>, by
jlg> pcg@cs.aber.ac.uk (Piercarlo Grandi):

pcg> I most strongly object to call this 'aggressive optimization'. It makes
pcg> 'aggressive optimization' look respectable.

pcg> Aggressive optimization is where the optimizer rewrites your program in
pcg> a supposedly similar form behind your back. [...]


jlg> Grandi comes up with this one periodically.  I can never pin him down
jlg> on a meaning.

I am sorry on this -- it is a fairly imprecise concept and I seem not to
be able to express it clearly, even if I have given at least several
examples. I doubt it can be defined precisely, even if certainly more
precisely than pornography... :-)

jlg> A compiler is a tool which transforms one representation of a
jlg> program (the source) into a semantically equivalent form (the
jlg> object code) in another language.  If the compiler changes the
jlg> semantics of the program during this process, it is _BROKEN_.  The
jlg> optimizer, as part of the compiler, must obey this same constraint.
jlg> If the optimizer changes the semantics of a code, it is _BROKEN_.

Yes, as long as the result is correct, an optimizer can do what it
wants. But here we are not interested on what a correct optimizer can
do; we are interested in what is proper or cost/effective for an
optimizer to do. In particular if there is reason to reckon that certain
types of optimization are hard to get right, that is the generated code
is incorrect with higher probability, they may not be very cost
effective. In practice the probability of code being generated
incorrectly is indeed an increasing function of optimizer complexity,
and of the level of semantic restructing performed by it.

So the statement:

jlg> An optimizer may be as "aggressive" as the compiler implementor
jlg> wants to make it - as long as it doesn't alter the semantics of the
jlg> code it's translating.

is true but not interesting -- it is a tautology. The interesting
question is which transformations, when going from source to target
code, are worth doing, performance and reliability wise.

Maybe I can find a more understandable way of expressing my thought:

I reckon, with some supportive reasoning that I will not repeat here,
that the tranformations that do not involve any "horizontal" rewriting
of a program's logic are worthwhile. I mean by this tranformations that
preserve the structure of the algorithm being translated.

If the structure is relatively underspecified (a very high level
language) then there is considerable scope for clever implementation
strategies. If it is relatively precisely specified (C, other systems
implementation languages) then it should be respected. I also regard
attempts at reinterpreting low level languages as high level ones, to
get around this, as dangerous, or at least inferior to using languages
designed at the desired level in the first instance.

Aggressive optimization is the idea that restructuring a program *in the
course of translation* is both feasible and advantageous, and desirable
(cost effective).

My contention is that logic restructuring optimizations are more cost
effective instead at the source level, whether automatic or manual, and
that often automatic is not necessary, manual is sufficient.

My main reason for surmising so is that automatic program analysis and
rewriting is often far more difficult than code planning and synthesis,
and the benefits are not as often competitive with those of more limited
and safer alternatives (source analysis and rewriting).

More shortly: when -O[2345....] will not raise substantially the
probability of getting broken code in most compilers, when it will not
result in huge increases in compile time or space, and when it will give
substantially better results than hand tuned code, then I will BELIEVE!
:-).
--
Piercarlo "Peter" Grandi           | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk