Hi, On Mon, 25 Nov 2013, David Malcolm wrote:
> I'm not a fan of these "_layout" names, but I'm not sure what better to > call them. Perhaps: > GSS_OMP_PARALLEL_LAYOUT -> GSS_OMP_WITH_CLAUSES_CHILD_FN_DATA_ARG > GSS_OMP_SINGLE_LAYOUT -> GSS_OMP_WITH_CLAUSES > GSS_OMP_ATOMIC_STORE_LAYOUT -> GSS_OMP_WITHOUT_SEQ_WITH_VAL > with analogous names for the corresponding structs. The preexisting name for these structs has a _base suffix (gimple_statement_with_ops_base and gimple_statement_with_memory_ops_base are indeed in the same situation in that no gimple codes exist that directly make use of that gss, unlike e.g. GSS_BASE which does have some direct users). (I do like more selfdescribing names, though, so perhaps the existing _base variants could also use some renaming, but it should either be no _base names at all, or only _base names (i.e. no additional _layout for some other names)). > Another approach to this would be to entirely eliminate these shared > layout types, going purely with the conceptual is-a relationships > between the types, say, by replacing the gengtype switch on GSS_ value > with a switch on GIMPLE_ code. Given that this might affect the speed > of GC (bigger switch statements), I went with the relatively more > conservative change. I think it makes sense to keep storage layout and gimple codes separate, but still have them both structured. The former allows easier changes when looking at data layout problems (like memory optimizations, or GC), the latter easier transformations related to higher level logic of the data structures. Ciao, Michael.
