Bug 25112 - [m68k] Suboptimal equality comparisons with small integers
Summary: [m68k] Suboptimal equality comparisons with small integers
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.2.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on: 81613
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-27 02:11 UTC by Kazu Hirata
Modified: 2017-07-29 23:22 UTC (History)
2 users (show)

See Also:
Host:
Target: m68k-elf
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-11-28 05:02:38


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kazu Hirata 2005-11-27 02:11:53 UTC
Consider:

int bar (void);

void
foo (void)
{
  int a = bar ();
  if (a == 1)
    bar ();
}

./cc1 -quiet -O2 -m5200 -fomit-frame-pointer generates

foo:
        move.l %a2,-(%sp)
        lea bar,%a2
        jbsr (%a2)
        moveq #1,%d1
        cmp.l %d0,%d1
        jbne .L4
        jbsr (%a2)
.L4:
        move.l (%sp)+,%a2
        rts

Note that

        moveq #1,%d1
        cmp.l %d0,%d1

can be replaced with

        subq.l #1,%d1

as long as the comparison is either == or !=, and %d1 dies at the comparison.

A similar optimization can be done for an equality comparison with
a negative numbers between -8 and -1, inclusive.
Comment 1 Andrew Pinski 2005-11-28 05:02:38 UTC
Confirmed.
Comment 2 Jeffrey A. Law 2016-11-18 17:38:52 UTC
Note that due to the 2-address nature of the m68k, this transformation is only valid when both registers die.

We need the register holding the immediate to die because the register will no longer be holding that immediate.

We need the register we're comparing against the immediate to die because we're going to change its value.

Finally the register we're comparing against the immediate must be a data register otherwise addq/subq will not set the condition codes.

It essentially needs to be a 3 insn -> 3 insn peephole2.  The key realization is that we're going to depend on test elimination in final to eliminate the comparison.  The peep2 just makes it painfully obvious to final how to do that.

Patch nearly ready...
Comment 3 Jeffrey A. Law 2016-11-18 21:53:04 UTC
Author: law
Date: Fri Nov 18 21:52:32 2016
New Revision: 242605

URL: https://gcc.gnu.org/viewcvs?rev=242605&root=gcc&view=rev
Log:
	PR target/25112
	* config/m68k/m68k.c (moveq feeding equality comparison): New
	peepholes.
	* config/m68k/predicates.md (addq_subq_operand): New predicate.
	(equality_comparison_operator): Likewise.

	PR target/25112
	* gcc.target/m68k/pr25112: New test.

Added:
    trunk/gcc/testsuite/gcc.target/m68k/pr25112.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/m68k/m68k.md
    trunk/gcc/config/m68k/predicates.md
    trunk/gcc/testsuite/ChangeLog
Comment 4 Jeffrey A. Law 2016-11-18 21:53:53 UTC
Fixed on the trunk for gcc-7.