This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: RFC - Refactor tree.h


On Aug 10, 2013, at 3:03 AM, Richard Biener <richard.guenther@gmail.com> wrote:
> Mike Stump <mikestump@comcast.net> wrote:
>> On Aug 9, 2013, at 3:36 PM, Diego Novillo <dnovillo@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.

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