[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)
{
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:1
# 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:1
# 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
--- 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
--- 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 #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
--- 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 #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
--- 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 = i1;
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
