Move SSA macros and declarations out of tree.h

[Richard Guenther]

On Fri, Oct 1, 2010 at 1:43 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 1 October 2010 11:51, Richard Guenther <richard.guenther@gmail.com> wrote:
>>
>> Hm, I don't see this as an improvement.
>>
>> SSA name is a tree.  So it should be in tree.h.  The only argument
>> could be that ssa_use_operand_d belongs in tree-ssa-operands.h
>> (but is not there because of cyclic dependencies I think).
>
> SSA tree node is a derived type of tree type. Conceptually tree type
> should not require SSA tree node to build. The current implementation
> does not allow that, so I have to include tree-ssa-node.h in tree.h,
> but it is conceivable that in the future this constraint will
> disappear. I could put back tree-ssa-node.h into tree.h, but having it
> in a separate file shows that they are two different things and it
> indicates that tree.h is not the place to declare SSA stuff.
>
> Moreover, this patch enables to use tree.h in the FE/plugins/external
> applications without importing any SSA macros/functions. GCC wants
> modularity or not?
>
> Since there is no design or clearly defined library boundaries, the
> best we can do is separate things into modular header files.
>
>> Adding more headers isn't necessarily a good idea.  Instead stripping
>> tree.h to its core pieces (keep the tree stuff only) and moving function
>> declarations to where they make more sense would be a better thing
>> to do.
>
> That is exactly what my patch does *except* that the current
> implementation does not allow me to separate the SSA tree node types
> declaration from tree.h. But the physical separation of
> tree-ssa-node.h indicates that tree is the base type and tree_ssa_name
> the derived type. Moreover, I thought it is a desired goal to split
> the trees in the future, isn't it?

Sorry, an SSA name is a tree node.  It does belong in tree.h, not
in a separate SSA whatever header file.

> Moreover, people have problems finding the SSA interface in tree.h,
> because logically it does not belong there, hence, tree-ssa.h should
> be much easier to find.

I disagree.

> Do you object to the whole patch, only to the tree-ssa-node.h file
> separated from tree.h?

To the whole patch.

> It is already very hard to contribute to GCC, could you please explain
> how you envision a modular GCC?

GCC doesn't become more modular by this kind of fake modularity.

Trees are (and will likely be for a long time) a central piece that
spreads everywhere.  To deny that doesn't make GCC easier to grok.

There are a lot of header files (and .c files!) that have aggregated
functions that are used very commonly (tree-dfa.c is one such
weird file, tree-flow*.h is another).  I would like to see improved
modularity by separating the common helpers out from where
they first appeared in optimization passes and later got exported.

Thus, modularity is first identify commonly used helpers, move them
to a more logical place (which isn't always a new .c file) and eventually
document them.

If you think that the SSA accessors are hard to find then direct to
them by means of documentation in a more logical place like
for example tree-ssa-operands.h (if that's really a more logical place).

Note that IMHO our headers should mainly follow the implementation,
not serve as high-level documentation.

Thanks,
Richard.

> Cheers,
>
> Manuel.
>