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