Mike Stump <mikest...@comcast.net> wrote: >On Aug 10, 2013, at 3:03 AM, Richard Biener ><richard.guent...@gmail.com> wrote: >> Mike Stump <mikest...@comcast.net> wrote: >>> On Aug 9, 2013, at 3:36 PM, Diego Novillo <dnovi...@google.com> >wrote: >>>> This patch is still WIP. It builds stage1, but I'm getting ICEs >>>> during stage 2. >>>> >>>> The patch splits tree.h into three files: >>>> >>>> - tree-core.h: All data structures, enums and typedefs from >>>> tree.h >>>> >>>> - tree-api.h: All extern function definitions from tree.h >>>> >>>> - tree-macros.h: All macro accessors, tree checks and other >>>> inline functions. >>> >>> I don't like this split. You focus in on the details and sort code >by >>> detail. I think this is wrong. > >> I mostly agree - tree-macros.h is a red herring. It should be >tree-core.h and tree.h only. > >I disagree. core isn't a concept that should be binned into. control >flow, call graph, register, arm, alias, allocation, attribute, builtin, >type, eval, jit, symbol, file, floating point, pass, block, stack, >constant, hash, map, range, memory, debug, dump, elf, dwarf, operator, >value, vector, declarations, int, statements, object, storage, >expressions, frame, error, values, mapping, the list is endless. core >is like a bin for important, functions that begin with a, functions I >wrote, big functions, functions implemented with templates, trivial >functions, hard to grasp concepts, simple things, things added in the >last year, old things, fun things, extra things, useful thing, unsorted >things, often used things, and so on… core goes in exactly the wrong >long term direction.
Fact is that we need to separate internal details of tree.h into sth shareable from exactly two places. Tree-core.h and tree.h are both 'tree.h' in some way. Call it tree-internal.h or tree1.h. The goal is to have two distinct and conflicting APIs to trees, one exposed from gimple.h and one from tree.h. And yes, that's a transitional thing - but possibly a very long living one... Richard.
