Re: Code Generation

[Colin McCormack <colin at field dot medicine dot adelaide dot edu dot au>]

Ken asks:
> I can only see two possible advantages to doing it with assembler
> macros: (1) processing the assembly code through a filter, which
> complicates the compilation process quite a bit, or (2) hacking the
> assembler itself is easier than hacking the compiler, but only because
> the assembler is a simpler program, in part because it *doesn't* have
> any of this sort of stuff in it.  What is your reason for wanting to
> do it here?

>From where I stand, as a compiler user, a compiler's a big, complicated,
sensitive, temperamental program.  If I can arrange for a simple
post-process to do a job, I see no reason to make the compiler any
bigger or more complex, to make others pay for the facility even though
they may never need it, or to saddle others with the task of supporting
the more complex code.

Decoupling what can be decoupled seems to make sense to me for this
reason.  The minimally intrusive interface I can envisage is an
assembler macro.  An assembler macro can be distributed as an add-on,
it's small, it can be conditionally turned into an identity
transformation, it can capture all the information the compiler has, and
selectively use it.

None of the applications I suggested are performance-critical.  Dumping
the whole register set and reloading it wouldn't (to me) be an
unacceptable overhead while running a Checker-like check of my code.

It would seem to me that compiling in a function call given a
-fcoldstore option and generating a macro ``call'' for the same purpose
given the same option makes no real difference, except that I can
conditionally assemble-out the macro call, at no runtime performance
cost, and little compile-time cost.

It just seems to me that there's a wealth of information painstakingly
calculated by the compiler which could be propagated to later
post-processes at fairly low cost, and in doing this, the compiler
immediately and adequately supports all the possible post processes
(those I can dream up, those others will dream up.)

I really can't see how it loses if, for example, the gcov code spits a
macro which could additionally server for profiling.

Having said this, I agree that Checker-like functionality is so
intimately wound up with what the compiler's doing that it may be
smarter to do it in-compiler.  I just wouldn't +dare+ suggest that
anyone else be asked to do it, and I wouldn't be able or prepared to do
it myself, where I would be prepared to consider writing the macros
mentioned.

Colin.