This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Target FUNCTION_{PRO,EPI}LOGUE question


Fergus Henderson wrote:
> The cost of switch versus indirect functional call is going to be
> pretty much a wash.  So I think the main benefit of this proposed
> approach would be avoiding the range checks when pushing stuff
> onto our hand-coded stacks.  And there may be other ways of achieving that.

I'd prefer that the greater concern is source readability and
maintainability.
The complexity of GCC is already an impediment to potential developers.

> If you organize things by function, then adding a new type will require
> adding code everywhere.  If you organize things by data type, then
> adding a new function will require adding code everywhere.

As I learn the compiler, I prefer to study one tree node type at once. 
It would be helpful to have all the functions that operate on one tree
type grouped, perhaps in a single source file.  (I realize that my
opinion is not universal, and I tend to be a bit dogmatic about OOP.)

Trees could be more extensible with vtables.  For example, debug_tree
could print lang-specific trees meaningfully.

> I think that for compilers in general and gcc in particular
> it is better to organize things by function rather than by
> data type, since adding a new compiler pass is a more common
> operation than adding a new kind of node to your abstract syntax tree.

I don't follow... why does a compiler pass benefit from function-centric
rather than type-centric coding?

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]