This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [Patch tree-ssa] RFC: Enable path threading for control variables (PR tree-optimization/54742).

From: Jeff Law <law at redhat dot com>
To: Richard Biener <richard dot guenther at gmail dot com>, 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>, "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 09:17:36 -0600
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> <CAFiYyc06hSV_R+4mKTFzYz8H4HHxxy+B5KAHwS+aZBWNsC=+TQ at mail dot gmail dot com>

On 10/18/13 04:55, Richard Biener wrote:

On Fri, Jun 21, 2013 at 11:21 PM, Steve Ellcey <sellcey@mips.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.

Thanks,
James


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
be reworked?

It trivially falls out of the work I'm doing. The biggest question willbe what to do about the loop structures. For the FSA case from coremarkthe loop structures get mucked up way beyond repair.

My thoughts were to generally continue to not allow major damage to theloop structures when threading jumps -- with the exception being if wecan eliminate an indirect or tablejump at the top of a loop. Possiblyfurther restricting it to the jump threading done after our loopoptimizers have completed.

I haven't looked at that heuristic yet as I've primarily focused onhaving the right infrastructure to correctly update the SSA and CFG inthe general case.




jeff

References:
- Re: [Patch tree-ssa] RFC: Enable path threading for control variables (PR tree-optimization/54742).
  - From: Richard Biener

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]