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.
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.
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
