This is the mail archive of the
mailing list for the GCC project.
Re: [Patch tree-ssa] RFC: Enable path threading for control variables (PR tree-optimization/54742).
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Steve Ellcey <sellcey at mips dot com>
- Cc: James Greenhalgh <james dot greenhalgh at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "law at redhat dot com" <law at redhat dot com>, "dnovillo at google dot com" <dnovillo at google dot com>, "amacleod at redhat dot com" <amacleod at redhat dot com>, "ook at ucw dot cz" <ook at ucw dot cz>, "sellcey at imgtec dot com" <sellcey at imgtec dot com>
- Date: Fri, 18 Oct 2013 12:55:08 +0200
- Subject: Re: [Patch tree-ssa] RFC: Enable path threading for control variables (PR tree-optimization/54742).
- Authentication-results: sourceware.org; auth=none
- References: <1371233239 dot 12204 dot 285 dot camel at ubuntu-sellcey> <1371647944-9788-1-git-send-email-james dot greenhalgh at arm dot com> <1371666799 dot 1804 dot 55 dot camel at ubuntu-sellcey> <20130621164330 dot GA23747 at arm dot com> <1371849708 dot 1804 dot 82 dot camel at ubuntu-sellcey>
On Fri, Jun 21, 2013 at 11:21 PM, Steve Ellcey <email@example.com> wrote:
> On Fri, 2013-06-21 at 17:43 +0100, James Greenhalgh wrote:
>> So to my mind, this is all far too tied up in pass ordering details to
>> resolve. Given that all the threading opportunities for my patch are found
>> in dom1 and how fragile the positioning of dom1 is, there is not a great
>> deal I can do to modify the ordering.
>> The biggest improvement I could find comes from rerunning pass_ch
>> immediately after dom1, though I'm not sure what the cost of that
>> would be.
>> I wonder if you or others have any thoughts on what the right thing to
>> do would be?
>> > I am not sure if path threading in general is turned off for -Os but it
>> > probably should be.
>> I agree, jump threading is on at -Os, path threading should not be.
> I think that since it seems to be more a space issue then a time issue,
> the way you currently have it is reasonable. As long as the
> optimization does not happen at -Os then I think we can probably live
> with the space increase.
I suppose with Jeffs recent work on jump-threading through paths
this case in handled and the patch in this thread is obsolete or can
> Steve Ellcey