This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/68541] [6 Regression] Path splitting causes if-conversion miss
- From: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 22 Dec 2015 22:39:56 +0000
- Subject: [Bug tree-optimization/68541] [6 Regression] Path splitting causes if-conversion miss
- Auto-submitted: auto-generated
- References: <bug-68541-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68541
--- Comment #3 from Jeffrey A. Law <law at redhat dot com> ---
So a couple updates.
First the path splitting code has been moved to -O3 and above so anyone trying
to reproduce would need to use -O2 -fsplit-paths.
The unnecessary duplication pointed out by Richi has been fixed.
I'm not sure what Richi is talking about in c#1 with regard to the conditional.
The duplicated block is:
;; basic block 7, loop depth 1
;; pred: 5
;; 6
# s_1 = PHI <s_10(5), s_11(6)>
ivtmp.6_2 = ivtmp.6_3 + 1;
if (ivtmp.6_2 != _21)
goto <bb 10>;
else
goto <bb 8>;
;; succ: 10
;; 8
Essentially consider block #7 duplicated into its predecessors, blocks #5 and
#6 respectively.
As I've been sitting here starting at the dumps, one heuristic is starting to
come to mind. The idea behind path splitting is to enable CSE. For there to be
any CSE, some statement in the duplicated block must be fed by a statement in a
predecessor block. That implies there's actually an intervening PHI. We can
potentially key things off the existence of those PHIs.
That heuristic would seem to prevent path splitting in this case. None of the
statements in the duplicated block have operands which are fed from a
predecessor block (through a PHI).