[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

[steven at gcc dot gnu dot org]

------- Comment #5 from steven at gcc dot gnu dot org  2006-04-27 20:46 -------
So I asked myself, why are we not catching this in vrp?  I know we can derive
ranges from types, so why don't we derive a [0,1] range from the bitfield load?

It turns out that we make _all_ loads VARYING right away, so we end up with:


Value ranges after VRP:

b_1: ~[0B, 0B]  EQUIVALENCES: { b_2 } (1 elements)
b_2: VARYING
D.1882_3: VARYING
D.1883_4: [0, 1]  EQUIVALENCES: { } (0 elements)
D.1884_5: [0, +INF]  EQUIVALENCES: { } (0 elements)
D.1885_6: [0, 127]  EQUIVALENCES: { } (0 elements)
D.1886_7: [0, +INF]  EQUIVALENCES: { } (0 elements)


ior (b)
{
  <unnamed type> D.1886;
  unsigned char D.1885;
  signed char D.1884;
  signed char D.1883;
  <unnamed type> D.1882;

<bb 2>:
  D.1882_3 = b_2->bit;
  D.1883_4 = (signed char) D.1882_3;
  D.1884_5 = D.1883_4 | 1;
  D.1885_6 = (unsigned char) D.1884_5;
  D.1886_7 = (<unnamed type>) D.1885_6;
  b_2->bit = D.1886_7;
  return;

}


where, at least so it seems to me, we could find something like,
D.1882_3: [0, 1] (etc.)


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2006-02-18 18:24:49         |2006-04-27 20:46:04
               date|                            |


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

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-04-27 21:14 -------
(In reply to comment #5)
> So I asked myself, why are we not catching this in vrp?  I know we can derive
> ranges from types, so why don't we derive a [0,1] range from the bitfield load?
> D.1883_4: [0, 1]  EQUIVALENCES: { } (0 elements)
> D.1884_5: [0, +INF]  EQUIVALENCES: { } (0 elements)

>   D.1884_5 = D.1883_4 | 1;

Shouldn't we find that D.1884_5 is 1 at this point because _4 was [0,1]
and [0, 1] | 1 is just 1?


-- 


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

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

[steven at gcc dot gnu dot org]

------- Comment #7 from steven at gcc dot gnu dot org  2006-04-27 21:32 -------
Yes, BIT_IOR_EXPR is also not handled.


-- 


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

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2006-05-05 09:13 -------
Here is a quick prototype addition for VRP, it does not handle the generic case
only [0, 1] | 1:
Index: tree-vrp.c
===================================================================
--- tree-vrp.c  (revision 113452)
+++ tree-vrp.c  (working copy)
@@ -1276,6 +1276,7 @@ extract_range_from_binary_expr (value_ra
       && code != MIN_EXPR
       && code != MAX_EXPR
       && code != BIT_AND_EXPR
+      && code != BIT_IOR_EXPR
       && code != TRUTH_ANDIF_EXPR
       && code != TRUTH_ORIF_EXPR
       && code != TRUTH_AND_EXPR
@@ -1319,6 +1320,7 @@ extract_range_from_binary_expr (value_ra
      the operands is VR_VARYING or symbolic range.  TODO, we may be
      able to derive anti-ranges in some cases.  */
   if (code != BIT_AND_EXPR
+      && code != BIT_IOR_EXPR
       && code != TRUTH_AND_EXPR
       && code != TRUTH_OR_EXPR
       && (vr0.type == VR_VARYING
@@ -1568,6 +1570,27 @@ extract_range_from_binary_expr (value_ra
          return;
        }
     }
+  else if (code == BIT_IOR_EXPR)
+    {
+      /* FIXME.  Handle only: [0, 1] | [1, 1], this should be expanded to
handle:
+         [ a, b ] | [b | b]. */
+      if (vr1.type == VR_RANGE
+         && vr1.min == vr1.max
+         && integer_onep (vr1.max)
+         && vr0.type == VR_RANGE
+         && integer_zerop (vr0.min)
+         && integer_onep (vr0.max))
+       {
+         type = VR_RANGE;
+         min = build_int_cst (TREE_TYPE (expr), 1);
+         max = build_int_cst (TREE_TYPE (expr), 1);
+       }
+      else
+       {
+         set_value_range_to_varying (vr);
+         return;
+       }
+    }
   else
     gcc_unreachable ();



-- 


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

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2006-10-24 13:07 -------
We should at least fold

  b->bit = (<unnamed type>) (unsigned char) ((signed char) b->bit | 1);

to

  b->bit = (<unnamed type>) ((signed char) b->bit | 1);


-- 


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

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

[aldot at gcc dot gnu dot org]

------- Comment #10 from aldot at gcc dot gnu dot org  2009-06-07 16:54 -------
4.3.3 does not simplify it, 4.4.0 onward do.

for reference
4.3.3:
Substituing values and folding statements

Constants propagated:      0
Copies propagated:         0
Predicates folded:         0

ior (bD.1193)
{
  <unnamed-unsigned:1> D.1200;
  unsigned charD.10 D.1199;
  signed charD.9 D.1198;
  signed charD.9 D.1197;
  <unnamed-unsigned:1> D.1196;

  # BLOCK 2 freq:10000
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  # VUSE <SMT.4D.1206_7(D)> { SMT.4D.1206 }
  D.1196_2 = bD.1193_1(D)->bitD.1192;
  D.1197_3 = (signed charD.9) D.1196_2;
  D.1198_4 = D.1197_3 | 1;
  D.1199_5 = (unsigned charD.10) D.1198_4;
  D.1200_6 = (<unnamed-unsigned:1>) D.1199_5;
  # SMT.4D.1206_8 = VDEF <SMT.4D.1206_7(D)> { SMT.4D.1206 }
  bD.1193_1(D)->bitD.1192 = D.1200_6;
  return;
  # SUCC: EXIT [100.0%] 

}


4.4.0:
Pass statistics:
----------------
Constants propagated: 1
Number of ASSERT_EXPR expressions inserted: 1
Statements deleted: 5

ior (struct B * bD.1247)
{
  <unnamed-unsigned:1> D.1254;
  unsigned charD.10 D.1253;
  signed charD.9 D.1252;
  signed charD.9 D.1251;
  <unnamed-unsigned:1> D.1250;

  # BLOCK 2 freq:10000
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  # SMT.10D.1266_8 = VDEF <SMT.10D.1266_7(D)> { SMT.10D.1266 }
  bD.1247_1(D)->bitD.1246 = 1;
  return;
  # SUCC: EXIT [100.0%] 

}


-- 

aldot at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.3.3
      Known to work|                            |4.4.0


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

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2009-06-08 15:40 -------
Thus fixed.


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-24 20:16 -------
I think this is now fixed on the mainline at the RTL level:
ior:
        movl    4(%esp), %eax
        orb     $1, (%eax)
        ret



-- 


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

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-07 05:55 -------
For the RTL level (at least on PPC), we could combine the following instructions and simplify them:
(insn 15 13 16 0 (set (reg:SI 124)
        (const_int 1 [0x1])) 293 {*movsi_internal1} (nil)
    (nil))
(insn 17 16 18 0 (set (zero_extract:SI (reg:SI 125)
            (const_int 1 [0x1])
            (const_int 0 [0x0]))
        (reg:SI 124)) 112 {insvsi} (insn_list:REG_DEP_TRUE 15 (insn_list:REG_DEP_TRUE 16 (nil)))
    (expr_list:REG_DEAD (reg:SI 124)
        (nil)))
into:
(set (reg:SI 121)
       (ior:SI (reg:SI 119)
                 (const_int -2147483648 [0xffffffff80000000])))


For x86 we need to combine and simplify the following code (which is not simplified at the tree level or 
RTL level yet, well is is optimizated with my tree combiner to the correct thing):
unsigned f(unsigned i)
{
 unsigned t = i&1;
 t|=1;
 t|=(i&~1);
 return t;
}

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org


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

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-15 05:31 -------
Well or just fold being fixed.

-- 


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

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-16 13:57 -------
Confirmed, this needs a tree combiner.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-10-16 13:57:26
               date|                            |


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