Re: flatten cfgloop.h

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, Jul 6, 2015 at 8:11 PM, Jeff Law <law@redhat.com> wrote:
> On 07/06/2015 07:38 AM, Michael Matz wrote:
>>
>> Hi,
>>
>> On Sun, 5 Jul 2015, Prathamesh Kulkarni wrote:
>>
>>> Hi,
>>> The attached patches flatten cfgloop.h.
>>> patch-1.diff moves around prototypes and structures to respective
>>> header-files.
>>> patch-2.diff (mostly auto-generated) replicates cfgloop.h includes in c
>>> files.
>>> Bootstrapped and tested on x86_64-unknown-linux-gnu with all front-ends.
>>> Built on all targets using config-list.mk.
>>> I left includes in cfgloop.h commented with #if 0 ... #endif.
>>> OK for trunk ?
>>
>>
>> Does nobody else think that header files for one or two prototypes are
>> fairly silly?
>
> Perhaps, but having a .h file for each .c file's exported objects means that
> we can implement a reasonable policy around where functions are prototyped
> or structures declared.

Yes.  At least for infrastructure files.  I happily make exceptions for things
like tree-vectorizer.h having prototypes for all tree-vect*.c files
(the at least
look related!).  Similar for tree-pass.h containing the interfacing of passes
to the pass manager (instead of having a header file for every pass).

> Contrast to "I put foo in expr.h because that was the most convenient place"
> which over 25+ years has made our header file dependencies a horrid mess.

Yeah - and I think we need to clean this up.  The general guidance of
prototype is in the corresponding .h file is easy.

After doing that we can move functions or even get rid of *.[ch] pairs
(like what is tree-dfa.[ch] other than a kitchen-sink for stuff - certainly
no where "Data flow functions for trees")

Richard.

>
>>
>> Anyway, your autogenerated part contains changes that seem exaggerated,
>> e.g.:
>>
>> +++ b/gcc/bt-load.c
>> @@ -54,6 +54,14 @@ along with GCC; see the file COPYING3.  If not see
>>   #include "predict.h"
>>   #include "basic-block.h"
>>   #include "df.h"
>> +#include "bitmap.h"
>> +#include "sbitmap.h"
>> +#include "cfgloopmanip.h"
>> +#include "loop-init.h"
>> +#include "cfgloopanal.h"
>> +#include "loop-doloop.h"
>> +#include "loop-invariant.h"
>> +#include "loop-iv.h"
>>
>> Surely bt-load doesn't need anything from doloop.h or invariant.h.  Before
>> this goes into trunk this whole autogenerated thing should be cleaned up
>> to add includes only for things that are actually needed.
>
> Agreed.
> jeff
>
>