On Tue, Apr 10, 2012 at 4:46 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: >> Class hierarchy is one such feature that is useful. Assuming we have >> two hierarchies for gcc: one for values rooted at ValExp, and one for >> gimple stmts rooted at GimpInst. >> >> 1) For IR browsing, >> *) all the macro accessors can be eliminated -- a big plus for debugging; > > Not that clear, if all the macros are replaced by tons of inline functions, > the debugging experience can be actually significantly worse. Already some > the > inline functions used like tree_operand_length used by TREE_OPERAND_LENGTH > macro are extremely annoying from debugging POV. >
To avoid debugging POV, in the code, a line of code can be used to convert it to the right pointer type and assign it to a temp variable. This line of code can be optimized away, but temp variable of the right pointer type can improve debuggability. >> *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) >> >> e.g. >> exp->as_component_ref().get_field() .. >> exp->as_mem_access().get_base() ... >> exp->as_mem_acesss().get_address() --> produces the >> address expression for memory access >> exp->as_mem_access().get_alias_handle () >> >> gimple_inst->serialize (&fixup_list) --> a virtual >> function overriden by actual instruction types that knows its byte >> code format. > > That silently assumes we want to change basic GIMPLE/tree data structures > to virtual classes, which is a significant change that has a significant > cost as well. E.g. all such changed data structures grow by a virtual > pointer field. Those data structures are heavily optimized for memory > footprint. > Not to mention it is very questionable if the above stuff is more readable > than what we currently have. > Agree. -- Chiheng Xu
