On 10/18/13 04:55, Richard Biener wrote:
On Fri, Jun 21, 2013 at 11:21 PM, Steve Ellcey <sell...@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 will
be what to do about the loop structures. For the FSA case from coremark
the loop structures get mucked up way beyond repair.
My thoughts were to generally continue to not allow major damage to the
loop structures when threading jumps -- with the exception being if we
can eliminate an indirect or tablejump at the top of a loop. Possibly
further restricting it to the jump threading done after our loop
optimizers have completed.
I haven't looked at that heuristic yet as I've primarily focused on
having the right infrastructure to correctly update the SSA and CFG in
the general case.
jeff
