Paolo Bonzini <bonz...@gnu.org> writes: > Also, in general compiler IRs are used in so many places that a > "pattern matching" style (similar to ML) actually works better than a > "class hierarchy" style. In other words, I doubt that C++ would > remove many of the switch statements we have in the code. With > respect to this, I'm curious about Ian's experience with gccgo.
In the gccgo IR I don't represent everything with a single type. Instead, I use a separate base class for types, expressions and statements (in Go there is more of a distinction between expressions and statements than there is in C/C++). I represent specific types, etc., as child classes. The base class uses a protected virtual function interface which the child classes implement. However, as you observe, some code does need to use pattern matching, so that approach is awkward to use by itself. I also declare an enum in the base class, and so given a pointer to the base class you can examine that enum to know which kind of object you have. Some operations are naturally described as virtual functions, such as converting to GENERIC or the general IR walker. Others are naturally described by examining the enums, such as checking whether two types are compatible. The main advantage of using virtual functions in the IR is that it significantly reduces the number of switch statements that have to be updated to add a new kind of IR. Instead most of the operations are kept in one place, in the child class implementation. To be clear, I don't think it would be appropriate at this time to use virtual functions for trees, GIMPLE, or RTL. Ian
