Re: Code Generation

[colin at field dot medicine dot adelaide dot edu dot au]

> > 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.
> 
> This might be the problem. *Somebody* has to modify the compiler, for
> a seemingly special application. Such a change has to be maintained.
> If it gets used, a detailed specification of what it does and how it
> works is necessary. To the compiler writer, this is insignificantly
> different from putting the desired functionality into the compiler in
> the first place, where this option has the advantage of being
> semantically cleaner.

I think we're not agreed that including explicit functionality is necessarily cleaner than including a functional reference.  If there were a number of different applications which might make exclusive use of the compiler's information (and I'm guessing there are) then it seems to me to be semantically cleaner to provide the hook, and decouple the implementation.

Case in point: the gcov stuff.  I haven't checked, but it appears from this discussion that it emits code to increment a pointer, whereas for semantic/block-level fine-grained profiling, it ought to increment a pointer and store the sum of a delta into a location.

If gcov emitted a macro instead, then the macro definition could selectively be made to handle either function.  If we go the `everything in the compiler' route, then (a) the maintenance load is heavier for compiler writers, (b) there are more switches for the compiler, (c) the compiler's doing more things that a compiler probably doesn't need to do.

Secondly, although I didn't make it clear, I'd be prepared to add the macro stuff to the compiler, too, because I think it's within my capabilities.

I wanted to float the idea of opening up the back-end to people like me, who really +don't+ want to tinker with compilers, or distribute compilers, but who need access to some of the metadata in the compiler.  I think the best way to do it, once and for all, is to define an interface for the backend transfer of the metadata, and I think the least intrusive way is as I've described.

It seemed to me to be necessary to guage the feeling of people who are focused on the larger compiler, rather than an instance of its use, before undertaking what is to me an arduous task.

Colin.