[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level
--- 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
--- 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) { D.1200; unsigned charD.10 D.1199; signed charD.9 D.1198; signed charD.9 D.1197; D.1196; # BLOCK 2 freq:1 # PRED: ENTRY [100.0%] (fallthru,exec) # VUSE { 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 = () D.1199_5; # SMT.4D.1206_8 = VDEF { 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) { D.1254; unsigned charD.10 D.1253; signed charD.9 D.1252; signed charD.9 D.1251; D.1250; # BLOCK 2 freq:1 # PRED: ENTRY [100.0%] (fallthru,exec) # SMT.10D.1266_8 = VDEF { 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
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-24 13:07 --- We should at least fold b->bit = () (unsigned char) ((signed char) b->bit | 1); to b->bit = () ((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
--- 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
--- 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
--- 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
--- 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) { D.1886; unsigned char D.1885; signed char D.1884; signed char D.1883; D.1882; : 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 = () 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
--- 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: movl4(%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
--- 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 [0x8000]))) 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
--- 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
--- 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|-00-00 00:00:00 |2004-10-16 13:57:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031