PR19038 causes regression of 3.9% in SPEC int

Jeffrey A Law law@redhat.com
Thu Dec 30 00:05:00 GMT 2004


On Thu, 2004-12-30 at 00:32 +0100, Steven Bosscher wrote:

> Of course it wouldn't result in wrong code, but it does lead to odd
> situations where some change to the source code would cause such a
> missed optimization and result in completely unexpected changes in
> the generated code.  IMVHO we should avoid such situations, and the
> cost of marking back edges is almost nothing (especially compared
> to some other tree-ssa passes.
> 
> Also note that the second tail call optimizations pass, one of the
> passes that may create back edges, is run after the last DCE pass,
> which is the last pass to mark back edges.
> 
> But oh well you are the boss...  Mind if I add this comment so at
> least it's clear that not calling mark_dfs_back_edges is deliberate?
How about this.  You generate a case where EDGS_DFS_BACK is not properly
set at this point in the code, given that we'll put in a call to mark
the back edges along with a testcase in the testsuite to verify  that
things are being done correctly.

Just because I don't see much value in catching this kind of corner
case doesn't mean I won't accept a patch which catches the corner
case.

jeff




More information about the Gcc-patches mailing list