[Bug middle-end/13191] New: Redundant sign extends

[Bug middle-end/13191] New: Redundant sign extends

[amodra at gcc dot gnu dot org]

The following testcase taken from lmbench shows gcc inserting needless sign
extends to convert intermediate results to ints (ppc64 logical operations are
done on full 64 bit registers).  Ideally, gcc could implement this function with
just one sign extend for the final result.  Different results, but still not
ideal, are seen when using an int for iter.

typedef long iter;

int
do_integer_bitwise (iter iterations, int r)
{
  int s = iterations;
#if 0
  while (iterations-- > 0)
#endif
    {
      r^=iterations; s^=r; r|=s;
      r^=iterations; s^=r; r|=s;
      r^=iterations; s^=r; r|=s;
      r^=iterations; s^=r; r|=s;
    }
  return r;
}

-- 
           Summary: Redundant sign extends
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: amodra at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13191

[Bug middle-end/13191] Redundant sign extends

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pessimizes-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13191

[Bug middle-end/13191] Redundant sign extends

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2003-11-26 00:11 -------
I'm seeing this too on Alpha. Another real-world example:

int parity (unsigned x)
{
  x ^= x >> 16;
  x ^= x >> 8;
  x ^= x >> 4;
  x &= 0xf;
  return (0x6996 >> x) & 1;
}

contains two pointless zero-extensions when compiled on Alpha.

I'm not sure how to approach this; there are powerful general purpose zero/sign
extension elimination algorithms
(http://www.trl.ibm.com/projects/jit/paper/sxt.pdf), but probably a few
more well-placed ad hoc rules would suffice.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13191

[Bug optimization/13191] [64bit] Redundant sign extends

[kazu at cs dot umass dot edu]

------- Additional Comments From kazu at cs dot umass dot edu  2004-02-25 06:01 -------
tree-ssa branch seems to perform better.

mainline:

.do_integer_bitwise:
	xor 4,4,3
	extsw 4,4    <-
	xor 0,3,4
	extsw 9,0    <-
	or 4,4,9
	xor 0,3,4
	extsw 4,0    <-
	xor 9,9,4
	or 0,4,9
	xor 0,0,3
	extsw 4,0    <-
	xor 9,9,4
	extsw 9,9    <-
	or 4,4,9
	xor 3,3,4
	extsw 4,3    <-
	xor 3,9,4
	or 3,3,4
	blr

tree-ssa:

.do_integer_bitwise:
	extsw 3,3    <-
	xor 0,4,3
	xor 9,3,0
	or 0,0,9
	xor 0,0,3
	xor 9,9,0
	or 0,0,9
	xor 0,0,3
	extsw 0,0    <-
	xor 9,9,0
	extsw 9,9    <-
	or 0,0,9
	xor 0,0,3
	xor 3,9,0
	or 3,3,0
	extsw 3,3    <-
	blr


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13191

[Bug optimization/13191] [64bit] Redundant sign extends

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-02-25 06:10 -------
The reason why the tree-ssa is better is from "ter":
do_integer_bitwise (iterations, r)
{
  int s;

<bb 0>:
  r = r ^ iterations;
  s = iterations ^ r;
  r = (r | s) ^ iterations;
  s = s ^ r;
  r = (r | s) ^ iterations;
  s = s ^ r;
  r = (r | s) ^ iterations;
  return r | s ^ r;
}

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13191

[Bug optimization/13191] [64bit] Redundant sign extends

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-02-25 06:15 -------
Well I put the wrong dump in here before, here is the right one:
do_integer_bitwise (iterations, r)
{
  int s.3;
  int s;

<bb 0>:
  s = (int)iterations;
  r = s ^ r;
  s.3 = s ^ r;
  r = s ^ (r | s.3);
  s.3 = s.3 ^ r;
  r = s ^ (r | s.3);
  s.3 = s.3 ^ r;
  r = s ^ (r | s.3);
  return r | s.3 ^ r;

}

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13191

[Bug optimization/13191] [64bit] Redundant sign extends

[kazu at cs dot umass dot edu]

------- Additional Comments From kazu at cs dot umass dot edu  2004-03-03 23:41 -------
I've implemented an ad hoc rule in tree-ssa like so:  Given

b = (type1) a;
c = (type2) b;

I try to eliminate b if b is dead and I can say "c = (type3) a".
It turns out at the end of tree-ssa optimizations, I seem to get two variables
containing the essentially same value, just in different types.

So, yes, the placement is important.  I'm reading the paper Falk pointed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13191

[Bug rtl-optimization/13191] [64bit] Redundant sign extends

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-02 01:24 -------
Hmm, this looks like it is fixed:
L4:
        subf r0,r11,r10
        addi r11,r11,1
        extsw r0,r0
        xor r2,r3,r0
        xor r9,r9,r2
        or r2,r2,r9
        xor r2,r2,r0
        xor r9,r9,r2
        or r2,r2,r9
        xor r2,r2,r0
        xor r9,r9,r2
        or r2,r2,r9
        xor r2,r2,r0
        xor r9,r9,r2
        or r3,r2,r9
        bdnz L4

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13191