🚀 go-pugleaf

In article <1992Nov18.154754.1848@udel.edu>, carroll@dori.cis.udel.edu (Mark C. Carroll) writes:
|> [...]
|> Optimization is a _very_ difficult business. Any optimization has
|> interactions with other optimizations, in terribly complex (and not
|> necessarily well-understood) ways. Making any change to the
|> optimization process can have broad affects on the entire process.
|> [...]

Yes.  Consider, for example, the last three things done by the 
compiler: 1) instruction selection; 2) register allocation; and
3) instruction scheduling.  On a CISC machine, this could be *very*
difficult.  For example, a memory/memory instruction doesn't
need any registers, but may alter the optimal instruction order,
which alters the optimal register allocation, which may mean that
you should now use a register/memory instruction instead.  Each
of these three parts of compilation feed-back into the other two
in compilicated ways.  (This is one of the reasons that CISC
machines are harder to write compilers for than RISC machines
are.)

|> Any optimization, particularly on modern architectures, has got to
|> consider its affect on pipeline fills, branch predictions, register
|> allocations, memory and cache uses, and dozens of other factors.  Do
|> you think that you're qualified to judge what affect your two-cycle
|> savings will have on the rest of your program? If so, you're in the
|> wrong field - you should be designing compilers.

To be fair to Dr. Rubin, he wants to be able to specify information
that the high-level language cannot directly represent.  In particular, 
many high level languages don't have the capability to directly express 
operations that modern machines can do.  In these instances, the machine's 
assembly language is higher-level than the so-called high-level language 
you're compiling from.  You need to be able to tell the compiler what to 
do.  For example, on vector machines there are often vector merges based 
on the vector mask - but C doesn't have a way to directly instruct that 
a given integer be stored into (or read from) the vector mask!  Coding 
around this in C would require that you rely on the compiler being able 
to *infer* from some standard C construct that the vector mask is what 
you're after.  Most compilers aren't up to it.  But, if you could just
say: "use the vector mask", the code would, very likely, run much
faster.

-- 
J. Giles