Bug 39726 - [5 Regression][cond-optab] ColdFire pessimizations on QImode/HImode tests
Summary: [5 Regression][cond-optab] ColdFire pessimizations on QImode/HImode tests
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.5.0
: P4 normal
Target Milestone: 5.5
Assignee: Paolo Bonzini
URL:
Keywords: missed-optimization
Depends on:
Blocks: 39714 65964
  Show dependency treegraph
 
Reported: 2009-04-10 14:34 UTC by Paolo Bonzini
Modified: 2018-03-22 19:51 UTC (History)
2 users (show)

See Also:
Host:
Target: m68k
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-07-14 22:31:04


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paolo Bonzini 2009-04-10 14:34:36 UTC
unsigned char v;

int baz (unsigned char u, unsigned char w)
{
  if ((u - w) & 0x80)
    v = 1; 
}

Combine does not like as much as for m68k the RTL produced by the optimizers, because of the lack of byte operations:

 (insn 10 9 11 f.c:5 (set (reg:QI 35)
-        (and:QI (subreg:QI (reg:SI 34) 3)
-(insn 11 10 12 f.c:5 (set (cc0)
-        (compare (reg:QI 35)
             (const_int 0 [0x0]))) -1 (nil))

vs.

 (insn 10 9 11 f.c:5 (set (reg:QI 35)
+        (subreg:QI (reg:SI 34) 3)) -1 (nil))
+
+(insn 11 10 12 f.c:5 (set (reg:SI 36)
+        (and:SI (subreg:SI (reg:QI 35) 0)
             (const_int -128 [0xffffff80]))) -1 (nil))

+(insn 12 11 13 f.c:5 (set (reg:QI 37)
+        (subreg:QI (reg:SI 36) 3)) -1 (nil))
+
+(insn 13 12 14 f.c:5 (set (cc0)
+        (compare (reg:QI 37)
             (const_int 0 [0x0]))) -1 (nil))

The extra insn 12 is present because of this in dojump.c:

564           /* The RTL optimizers prefer comparisons against pseudos.  */
565           if (GET_CODE (temp) == SUBREG)
566             {
567               /* Compare promoted variables in their promoted mode.  */
568               if (SUBREG_PROMOTED_VAR_P (temp)
569                   && REG_P (XEXP (temp, 0)))
570                 temp = XEXP (temp, 0);
571               else
572                 temp = copy_to_reg (temp);
573             }
Comment 1 Paolo Bonzini 2009-07-14 22:42:05 UTC
I have a patch.
Comment 2 Paolo Bonzini 2009-08-01 21:25:00 UTC
Hmm, the patch changes a canonicalization in a way that may break some patterns on some targets. :-(

Not sure how to proceed.
Comment 3 Richard Biener 2010-04-06 11:19:54 UTC
GCC 4.5.0 is being released.  Deferring to 4.5.1.
Comment 4 Richard Biener 2010-07-31 09:29:23 UTC
GCC 4.5.1 is being released, adjusting target milestone.
Comment 5 Richard Biener 2010-12-16 13:03:19 UTC
GCC 4.5.2 is being released, adjusting target milestone.
Comment 6 Richard Biener 2011-04-28 14:51:35 UTC
GCC 4.5.3 is being released, adjusting target milestone.
Comment 7 Jakub Jelinek 2013-04-12 15:16:51 UTC
GCC 4.6.4 has been released and the branch has been closed.
Comment 8 Richard Biener 2014-06-12 13:46:07 UTC
The 4.7 branch is being closed, moving target milestone to 4.8.4.
Comment 9 Jakub Jelinek 2014-12-19 13:35:45 UTC
GCC 4.8.4 has been released.
Comment 10 Jeffrey A. Law 2015-05-27 21:13:57 UTC
Author: law
Date: Wed May 27 21:13:25 2015
New Revision: 223781

URL: https://gcc.gnu.org/viewcvs?rev=223781&root=gcc&view=rev
Log:
        PR target/39726
        * gcc.dg/target/m68k/pr39726-1.c: New test.

Added:
    trunk/gcc/testsuite/gcc.target/m68k/pr39726.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
Comment 11 Jeffrey A. Law 2015-05-27 21:14:43 UTC
Recently fixed on trunk by a patch to match.pd.  Not planning to backport to the release branches.
Comment 12 Richard Biener 2015-06-23 08:18:27 UTC
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
Comment 13 Jakub Jelinek 2015-06-26 19:59:17 UTC
GCC 4.9.3 has been released.
Comment 14 Richard Biener 2016-08-03 10:46:30 UTC
GCC 4.9 branch is being closed
Comment 15 Eric Gallager 2018-03-22 19:51:23 UTC
(In reply to Richard Biener from comment #14)
> GCC 4.9 branch is being closed

So is GCC 5 branch.

(In reply to Jeffrey A. Law from comment #11)
> Recently fixed on trunk by a patch to match.pd.  Not planning to backport to
> the release branches.

So FIXED then.