This is the mail archive of the
mailing list for the GCC project.
Re: [patch] The remainder of tree-flow.h refactored.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Diego Novillo <dnovillo at google dot com>
- Date: Wed, 9 Oct 2013 13:06:46 +0200
- Subject: Re: [patch] The remainder of tree-flow.h refactored.
- Authentication-results: sourceware.org; auth=none
- References: <524EF235 dot 5080803 at redhat dot com> <CAFiYyc3wmp5N76QqTgBOeBvy=Eu6fj175+Xf0VwgxxNgfHzjHQ at mail dot gmail dot com> <5253F01F dot 1060609 at redhat dot com> <525495EA dot 5020609 at redhat dot com>
On Wed, Oct 9, 2013 at 1:31 AM, Andrew MacLeod <email@example.com> wrote:
> On 10/08/2013 07:44 AM, Andrew MacLeod wrote:
>> On 10/08/2013 06:22 AM, Richard Biener wrote:
>>> graphite.h should be unnecessary with moving the pass struct like you
>>> did for other loop opts. Likewise tree-parloops.h (well, ok, maybe
>>> you need parallelized_function_p, even though it's implementation is
>>> gross ;)). Likewise tree-predcom.h.
>> fair enough. Yes, I've already seen a few things that madfe my skin crawl
>> and I had to resist going down a rathole for :-)
>>> unvisit_body isn't generic enough to warrant moving out of gimplify.c
>>> (the only user).
>>> The force_gimple_operand_gsi... routines are in gimplify.c because they
>>> gimplify! And you moved them but not force_gimple_operand[_1]!?
>> OK, let me make the above adjustments, and I'll recreate a patch without
>> the gimple/gimplfy parts, and re-address that separately. I forget the
>> details of my include issues there at the moment.
> Here's the adjusted patch which doesn't contain the ugly gimple, gimplify,
> and tree stuff. I'll deal with that once everything else settles.
> I removed tree-predcom.h and graphite.h and also moved the parallel_loops
> pass into tree-parloops.c... but we still need predcom.h :-P. oh well. I
> think most of its pretty straightforward.
> Bootstraps on x86_64-unknown-linux-gnu, and running regressions. Assuming no
> issues, OK?