From: Jeff Law <law@redhat.com>
To: Andrew MacLeod <amacleod@redhat.com>,
gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [patch 0/9] Flattening and initial module rebuilding
Date: Thu, 09 Jul 2015 16:29:00 -0000 [thread overview]
Message-ID: <559EA174.9010706@redhat.com> (raw)
In-Reply-To: <559DDFAA.50400@redhat.com>
On 07/08/2015 08:42 PM, Andrew MacLeod wrote:
> blah, not so trivial. One of the primary things predict.h does is
> create enum br_predictor by including predict,def.. so moving that enum
> doesnt really make sense.
>
> Fixing gimple,h isn't too bad, I could split the prediction stuff out
> into gimple-predict.h and include it in the 4 places its needed (as you
> might be able to tell, Ive tried this :-)
>
> However, it doesn't do much good. cfghooks.h is included by
> basic-block.h.. which is needed virtually everywhere :-P
I don't guess we're approaching a world where the front-ends don't need
basic-block (and thus cfghooks, predictions, etc etc).
> The other option is to pull cfghooks.h out of basic-block.h and include
> it seperately on its own.. What is the reason its in there now? It
> appears to not have a cyclic dependency which is the usual reason to
> have an include in the middle of a file. Or perhaps the reason no
> longer exists? There is a comment at the top of cfghooks.h :
> /* Only basic-block.h includes this. */
> but no rationale.
I don't recall. It may have seemed to make sense at the time :-) You'd
have to do the archaeology and even if you did, you might not get an answer.
>
> I moved it to the very bottom of the file and everything still seems to
> compile fine I can try flattening it out of basic-block.h and only
> including it in places that need it... that should eliminate the need to
> put predict.h in a lot of places I would think.
If it's not too much trouble, seems like it might be worth trying. It
just feels like the prediction bits shouldn't be that pervasive.
jeff
next prev parent reply other threads:[~2015-07-09 16:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-07 13:40 Andrew MacLeod
2015-07-07 13:43 ` [patch 1/9] header additions and aggregators Andrew MacLeod
2015-07-07 13:44 ` [patch 2/9] flatten regset.h Andrew MacLeod
2015-07-07 13:45 ` [patch 3/9] Flatten lra-int.h Andrew MacLeod
2015-07-07 13:46 ` [patch 4/9] Flatten sel-sched-dump.h and sel-sched-ir.h Andrew MacLeod
2015-07-07 14:01 ` Alexander Monakov
2015-07-07 14:07 ` Andrew MacLeod
2015-07-07 13:46 ` [patch 5/9] Flatten ira-int.h Andrew MacLeod
2015-07-07 13:47 ` [patch 6/9] Flatten gimple-streamer.h Andrew MacLeod
2015-07-07 13:49 ` [patch 7/9] Flatten cfgloop.h Andrew MacLeod
2015-07-07 13:50 ` [patch 8/9] Flatten df.h Andrew MacLeod
2015-07-07 13:51 ` [patch 9/9] Final patch with all changes Andrew MacLeod
2015-07-07 22:03 ` Pedro Alves
2015-07-07 22:10 ` Andrew MacLeod
2015-07-07 22:21 ` [patch 0/9] Flattening and initial module rebuilding Jeff Law
2015-07-07 23:53 ` Andrew MacLeod
2015-07-08 22:43 ` Jeff Law
2015-07-09 2:43 ` Andrew MacLeod
2015-07-09 16:29 ` Jeff Law [this message]
2015-07-09 17:06 ` Andrew MacLeod
2015-07-09 17:48 ` Jeff Law
2015-07-09 18:00 ` Andrew MacLeod
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=559EA174.9010706@redhat.com \
--to=law@redhat.com \
--cc=amacleod@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).