[Bug middle-end/18041] New: OR of two single-bit bitfields is inefficient

[Bug middle-end/18041] New: OR of two single-bit bitfields is inefficient

[kazu at cs dot umass dot edu]

Consider:

struct B {
  unsigned bit0 : 1;
  unsigned bit1 : 1;
};

void
foo (struct B *b)
{
  b->bit0 = b->bit0 | b->bit1;
}

./cc1 -O2 -fomit-frame-pointer -mregparm=3 generates

foo:
	movb	(%eax), %dl  <- one load
	movb	%dl, %cl
	shrb	%cl
	orl	%edx, %ecx
	andl	$1, %ecx
	movl	(%eax), %edx <- another load from the same place
	andl	$-2, %edx
	orl	%ecx, %edx   <- the second OR
	movl	%edx, (%eax)
	ret

We could do something like

	movb	(%eax), %cl
	movb	%cl, %dl
	shrb	%dl
	andl	$1, %edx
	orl	%ecx, %edx
	movb	%dl, (%eax)
	ret

or

	movb	(%eax), %dl
	testb	$2, %dl
	je	.L6
	orl	$1, %edx
	movb	%dl, (%eax)
.L6:
	ret

expr.c actually has code intended to emit the second suggestion
(look for "Check for |= or &= of a bitfield" in expr.c), but it is
practically disabled because we get tree like this

  b->bit0 = (<unnamed type>) (unsigned char)
              ((signed char) b->bit0 | (signed char) b->bit1)

whereas the code in expr.c expects

  b->bit0 = b->bit0 | b->bit1;

The code is not triggered even in gcc-3.3.  Probably it is practically
disabled for a long time.

-- 
           Summary: OR of two single-bit bitfields is inefficient
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: enhancement
          Priority: P2
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: kazu at cs dot umass dot edu
                CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu


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

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-17 17:01 -------
Hmm, there is only one load on PPC (with either side):
same bit layout as below:
        lwz r0,0(r3)
        rlwinm r2,r0,0,31,31
        rlwinm r9,r0,31,31,31
        or r2,r2,r9
        rlwimi r0,r2,0,31,31
        stw r0,0(r3)
        blr
The oposite bit layout:
        lwz r0,0(r3)
        srwi r2,r0,31
        rlwinm r9,r0,2,31,31
        or r2,r2,r9
        rlwimi r0,r2,31,0,0
        stw r0,0(r3)
        blr

-- 


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

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-17 17:05 -------
Confirmed about the extra and (I don't know why the extra load is in x86).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-10-17 17:05:33
               date|                            |


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

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-07 06:02 -------
This is a much harder problem than doing a simplification at combine time because we have five 
instructions to worry about.

-- 


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

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-05-11 10:53:00 UTC ---
Author: rguenth
Date: Wed May 11 10:52:57 2011
New Revision: 173650

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173650
Log:
2011-05-11  Richard Guenther  <rguenther@suse.de>

    PR tree-optimization/18041
    * tree-ssa-forwprop.c (simplify_bitwise_and): Rename to ...
    (simplify_bitwise_binary): ... this.  Handle operand conversions
    by applying them to the result instead.
    (tree_ssa_forward_propagate_single_use_vars): Adjust.  CSE tree code.

    * gcc.dg/tree-ssa/forwprop-13.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-13.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-forwprop.c

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-05-10 11:38:50 UTC ---
With a patch I have we now optimize at the tree level to

<bb 2>:
  D.2686_2 = b_1(D)->bit0;
  D.2688_4 = b_1(D)->bit1;
  D.2693_10 = D.2688_4 ^ D.2686_2;
  b_1(D)->bit0 = D.2693_10;
  return;

and with bitfield lowering applied to

<bb 2>:
  BF.0_2 = MEM[(struct B *)b_1(D)];
  D.2694_6 = BF.0_2 >> 1;
  D.2701_18 = D.2694_6 ^ BF.0_2;
  D.2696_12 = BF.0_2 & 4294967294;
  D.2697_13 = D.2701_18 & 1;
  BF.2_14 = D.2697_13 | D.2696_12;
  MEM[(struct B *)b_1(D)] = BF.2_14;
  return;

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-05-06 13:23:11 UTC ---
Mine.  With bitfield lowering I see

<bb 2>:
  BF.0_2 = MEM[(struct B *)b_1(D)];
  D.2686_3 = (<unnamed-unsigned:1>) BF.0_2;
  D.2687_4 = (unsigned char) D.2686_3;
  D.2694_6 = BF.0_2 >> 1;
  D.2688_7 = (<unnamed-unsigned:1>) D.2694_6;
  D.2689_8 = (unsigned char) D.2688_7;
  D.2690_9 = D.2689_8 | D.2687_4;
  D.2691_10 = (<unnamed-unsigned:1>) D.2690_9;
  D.2696_12 = BF.0_2 & 4294967294;
  D.2697_13 = (unsigned int) D.2691_10;
  BF.2_14 = D.2697_13 | D.2696_12;
  MEM[(struct B *)b_1(D)] = BF.2_14;
  return;

there is the possibility to associate truncations/widenings with |& so
D.2689_8 | D.2687_4 becomes (unsigned char) D.2688_7 | D.2686_3
and the truncation (<unnamed-unsigned:1>) D.2690_9 can be combined
with it.