| Summary: | [3.3/3.4 regression] loop miscompiled on ppc32 | ||
|---|---|---|---|
| Product: | gcc | Reporter: | marcus |
| Component: | rtl-optimization | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | debian-gcc, gcc-bugs, rth, selinger, zippel |
| Priority: | P2 | Keywords: | wrong-code |
| Version: | 3.3 | ||
| Target Milestone: | 3.3.2 | ||
| Host: | powerpc-*-* | Target: | powerpc-*-* |
| Build: | powerpc-*-* | Known to work: | |
| Known to fail: | Last reconfirmed: | 2003-07-12 06:17:07 | |
| Attachments: | testcase for 11319 | ||
|
Description
marcus
2003-06-25 13:20:59 UTC
Created attachment 4279 [details]
testcase for 11319
This is a total dup of 9745 but I will put the simplified testcase in that one. *** This bug has been marked as a duplicate of 9745 *** The patch that fixed PR 9745 did not fix this one. It is a closely related problem, but there are multiple problems here. See http://gcc.gnu.org/ml/gcc/2003-07/msg00668.html for a discussion of various issues related to this problem. Confirmed with gcc 3.3 branch and mainline (20030710). I could also reproduce this on powerpc-apple-darwin6.6 so this is at least powerpc-*-*. The regression in PR 11319 was introduced or exposed by this patch: 2002-02-07 Richard Henderson <rth@redhat.com> PR optimization/2463 * alias.c (find_base_value): Recall base values for fixed hard regs. * loop.c (loop_regs_update): Don't use single_set on non-insns. The regression hunt took place on powerpc-linux using the test case from the attachment in comment #1 compiled with -O2 and then executed. Richard's patch did not introduce the problem, it just exposed it. In the old days, a sequence was an insn chain if more than one instruction, and a pattern if only one instruction. In the single insn case, which is the common case, the loop.c code was passing the pattern to single_set which failed, and thus prevented it from calling record_base_value. Richard's patch fixed it to call record_base_value as intended, thus exposing the alias.c problem fixed by my patch in PR 10021. This incidentally points out a problem with loop_regs_update. The !INSN_P code is obsolete and should be removed. Subject: Bug 11319 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: wilson@gcc.gnu.org 2003-08-12 05:26:15 Modified files: gcc : ChangeLog alias.c Log message: PR optimization/11319 PR target/10021 * alias.c (find_base_value, case REG): Return 0 not src if no base found. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.706&r2=1.16114.2.707 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/alias.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.181.2.2&r2=1.181.2.3 Subject: Bug 11319 CVSROOT: /cvs/gcc Module name: gcc Changes by: wilson@gcc.gnu.org 2003-08-12 05:28:45 Modified files: gcc : ChangeLog alias.c Log message: PR optimization/11319 PR target/10021 * alias.c (find_base_value, case REG): Return 0 not src if no base found. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.769&r2=2.770 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/alias.c.diff?cvsroot=gcc&r1=1.198&r2=1.199 *** Bug 10021 has been marked as a duplicate of this bug. *** *** Bug 11366 has been marked as a duplicate of this bug. *** The bug has been fixed by the alias.c patch. However, there were questions raised about the effect of the patch on the performance of gcc compiled code. I have left the bug report open for now as a reminder to look into this issue. I have checked in a patch to fix the loop_regs_update !INSN_P problem I mentioned earlier. http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00397.html I have done SPEC testing on a Pentium4 system running GNU/Linux. I used -O2 -march=pentium4 as the gcc optimization options. I see no significant effect on the performance for those benchmarks that I could get running. I do see a noticable drop in 301.apsi performance after the first loop_regs_update patch went in, but it went back up after the alias.c patch went in, so the problem seems to have corrected itself. PowerPC performance tests are pending. I have now run SPEC on a PowerMac G5. The only noticable performance change I
see is a 3% improvement in mesa with my patches, but 3% is small enough that it
could be within my measurement error.
David Edelsohn has agreed that my patches did not introduce performance
regressions. See
http://gcc.gnu.org/ml/gcc/2003-09/msg00377.html
So I am not closing this problem report.
*** Bug 12243 has been marked as a duplicate of this bug. *** |