ifcvt: Fix bitpos calculation in bitfield lowering [PR107229]
Checks
Commit Message
Hi,
The bitposition calculation for the bitfield lowering in loop if
conversion was not
taking DECL_FIELD_OFFSET into account, which meant that it would result in
wrong bitpositions for bitfields that did not end up having representations
starting at the beginning of the struct.
Bootstrappend and regression tested on aarch64-none-linux-gnu and
x86_64-pc-linux-gnu.
gcc/ChangeLog:
PR tree-optimization/107229
* gcc/tree-if-conv.cc (get_bitfield_rep): Fix bitposition calculation.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/pr107229-1.c: New test.
* gcc.dg/vect/pr107229-2.c: New test.
* gcc.dg/vect/pr107229-3.c: New test.
Comments
On Wed, 12 Oct 2022, Andre Vieira (lists) wrote:
> Hi,
>
> The bitposition calculation for the bitfield lowering in loop if conversion
> was not
> taking DECL_FIELD_OFFSET into account, which meant that it would result in
> wrong bitpositions for bitfields that did not end up having representations
> starting at the beginning of the struct.
>
> Bootstrappend and regression tested on aarch64-none-linux-gnu and
> x86_64-pc-linux-gnu.
+ {
+ tree bf_pos = fold_build2 (MULT_EXPR, bitsizetype,
+ DECL_FIELD_OFFSET (field_decl),
+ build_int_cst (bitsizetype, 8));
+ bf_pos = fold_build2 (PLUS_EXPR, bitsizetype, bf_pos,
+ DECL_FIELD_BIT_OFFSET (field_decl));
+ tree rep_pos = fold_build2 (MULT_EXPR, bitsizetype,
+ DECL_FIELD_OFFSET (rep_decl),
+ build_int_cst (bitsizetype, 8));
+ rep_pos = fold_build2 (PLUS_EXPR, bitsizetype, rep_pos,
+ DECL_FIELD_BIT_OFFSET (rep_decl));
you can use the invariant that DECL_FIELD_OFFSET of rep_decl
and field_decl are always the same. Also please use BITS_PER_UNIT
instead of '8'.
Richard.
Added some extra comments to describe what is going on there.
On 13/10/2022 09:14, Richard Biener wrote:
> On Wed, 12 Oct 2022, Andre Vieira (lists) wrote:
>
>> Hi,
>>
>> The bitposition calculation for the bitfield lowering in loop if conversion
>> was not
>> taking DECL_FIELD_OFFSET into account, which meant that it would result in
>> wrong bitpositions for bitfields that did not end up having representations
>> starting at the beginning of the struct.
>>
>> Bootstrappend and regression tested on aarch64-none-linux-gnu and
>> x86_64-pc-linux-gnu.
> + {
> + tree bf_pos = fold_build2 (MULT_EXPR, bitsizetype,
> + DECL_FIELD_OFFSET (field_decl),
> + build_int_cst (bitsizetype, 8));
> + bf_pos = fold_build2 (PLUS_EXPR, bitsizetype, bf_pos,
> + DECL_FIELD_BIT_OFFSET (field_decl));
> + tree rep_pos = fold_build2 (MULT_EXPR, bitsizetype,
> + DECL_FIELD_OFFSET (rep_decl),
> + build_int_cst (bitsizetype, 8));
> + rep_pos = fold_build2 (PLUS_EXPR, bitsizetype, rep_pos,
> + DECL_FIELD_BIT_OFFSET (rep_decl));
>
> you can use the invariant that DECL_FIELD_OFFSET of rep_decl
> and field_decl are always the same. Also please use BITS_PER_UNIT
> instead of '8'.
>
> Richard.
diff --git a/gcc/testsuite/gcc.dg/vect/pr107229-1.c b/gcc/testsuite/gcc.dg/vect/pr107229-1.c
new file mode 100644
index 0000000000000000000000000000000000000000..67b432383d057a630746aa00af50c25fcb527d8e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr107229-1.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* PR tree-optimization/107229. */
+
+int a, c;
+struct {
+ long d;
+ int : 8;
+ int : 27;
+ int e : 21;
+} f;
+void g(int b) { a = a & 1; }
+int main() {
+ while (c)
+ g(f.e);
+ return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/vect/pr107229-2.c b/gcc/testsuite/gcc.dg/vect/pr107229-2.c
new file mode 100644
index 0000000000000000000000000000000000000000..88bffb63d5e8b2d7bcdeae223f4ec6ea4f611bc9
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr107229-2.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* PR tree-optimization/107229. */
+
+int a, c;
+struct {
+ long f;
+ long g;
+ long d;
+ int : 8;
+ int : 27;
+ int e : 21;
+} f;
+void g(int b) { a = a & 1; }
+int main() {
+ while (c)
+ g(f.e);
+ return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/vect/pr107229-3.c b/gcc/testsuite/gcc.dg/vect/pr107229-3.c
new file mode 100644
index 0000000000000000000000000000000000000000..4abd8c14531b40e9dbe9802a8f9a0eabba673c9f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr107229-3.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* PR tree-optimization/107229. */
+
+int a, c;
+struct {
+ long f;
+ long g;
+ long d;
+ int : 8;
+ int : 32;
+ int : 2;
+ int e : 21;
+} f;
+void g(int b) { a = a & 1; }
+int main() {
+ while (c)
+ g(f.e);
+ return 0;
+}
diff --git a/gcc/tree-if-conv.cc b/gcc/tree-if-conv.cc
index e468a4659fa28a3a31c3390cf19bee65f4590b80..01637c5da08d5a2a00a495522fc9a6436a804398 100644
--- a/gcc/tree-if-conv.cc
+++ b/gcc/tree-if-conv.cc
@@ -3298,10 +3298,34 @@ get_bitfield_rep (gassign *stmt, bool write, tree *bitpos,
*struct_expr = TREE_OPERAND (comp_ref, 0);
if (bitpos)
- *bitpos
- = fold_build2 (MINUS_EXPR, bitsizetype,
- DECL_FIELD_BIT_OFFSET (field_decl),
- DECL_FIELD_BIT_OFFSET (rep_decl));
+ {
+ /* To calculate the bitposition of the BITFIELD_REF we have to determine
+ where our bitfield starts in relation to the container REP_DECL. The
+ DECL_FIELD_OFFSET of the original bitfield's member FIELD_DECL tells
+ us how many bytes from the start of the structure there are until the
+ start of the group of bitfield members the FIELD_DECL belongs to,
+ whereas DECL_FIELD_BIT_OFFSET will tell us how many bits from that
+ position our actual bitfield member starts. For the container
+ REP_DECL adding DECL_FIELD_OFFSET and DECL_FIELD_BIT_OFFSET will tell
+ us the distance between the start of the structure and the start of
+ the container, though the first is in bytes and the later other in
+ bits. With this in mind we calculate the bit position of our new
+ BITFIELD_REF by subtracting the number of bits between the start of
+ the structure and the container from the number of bits from the start
+ of the structure and the actual bitfield member. */
+ tree bf_pos = fold_build2 (MULT_EXPR, bitsizetype,
+ DECL_FIELD_OFFSET (field_decl),
+ build_int_cst (bitsizetype, BITS_PER_UNIT));
+ bf_pos = fold_build2 (PLUS_EXPR, bitsizetype, bf_pos,
+ DECL_FIELD_BIT_OFFSET (field_decl));
+ tree rep_pos = fold_build2 (MULT_EXPR, bitsizetype,
+ DECL_FIELD_OFFSET (rep_decl),
+ build_int_cst (bitsizetype, BITS_PER_UNIT));
+ rep_pos = fold_build2 (PLUS_EXPR, bitsizetype, rep_pos,
+ DECL_FIELD_BIT_OFFSET (rep_decl));
+
+ *bitpos = fold_build2 (MINUS_EXPR, bitsizetype, bf_pos, rep_pos);
+ }
return rep_decl;
On Thu, 13 Oct 2022, Andre Vieira (lists) wrote:
> Added some extra comments to describe what is going on there.
Just to note I was confused and DECL_FIELD_OFFSET can indeed be
different (but then are guaranteed to be constant), so the patch
looks correct.
> On 13/10/2022 09:14, Richard Biener wrote:
> > On Wed, 12 Oct 2022, Andre Vieira (lists) wrote:
> >
> >> Hi,
> >>
> >> The bitposition calculation for the bitfield lowering in loop if conversion
> >> was not
> >> taking DECL_FIELD_OFFSET into account, which meant that it would result in
> >> wrong bitpositions for bitfields that did not end up having representations
> >> starting at the beginning of the struct.
> >>
> >> Bootstrappend and regression tested on aarch64-none-linux-gnu and
> >> x86_64-pc-linux-gnu.
> > + {
> > + tree bf_pos = fold_build2 (MULT_EXPR, bitsizetype,
> > + DECL_FIELD_OFFSET (field_decl),
> > + build_int_cst (bitsizetype, 8));
> > + bf_pos = fold_build2 (PLUS_EXPR, bitsizetype, bf_pos,
> > + DECL_FIELD_BIT_OFFSET (field_decl));
> > + tree rep_pos = fold_build2 (MULT_EXPR, bitsizetype,
> > + DECL_FIELD_OFFSET (rep_decl),
> > + build_int_cst (bitsizetype, 8));
> > + rep_pos = fold_build2 (PLUS_EXPR, bitsizetype, rep_pos,
> > + DECL_FIELD_BIT_OFFSET (rep_decl));
> >
> > you can use the invariant that DECL_FIELD_OFFSET of rep_decl
> > and field_decl are always the same. Also please use BITS_PER_UNIT
> > instead of '8'.
> >
> > Richard.
>
Hi Andre,
> The bitposition calculation for the bitfield lowering in loop if conversion
> was not
> taking DECL_FIELD_OFFSET into account, which meant that it would result in
> wrong bitpositions for bitfields that did not end up having representations
> starting at the beginning of the struct.
>
> Bootstrappend and regression tested on aarch64-none-linux-gnu and
> x86_64-pc-linux-gnu.
I tried this patch together with the one for PR tree-optimization/107226
on sparc-sun-solaris2.11 to check if it cures the bootstrap failure
reported in PR tree-optimization/107232. While this restores bootstrap,
several of the new tests FAIL:
+FAIL: gcc.dg/vect/vect-bitfield-read-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-read-1.c scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-read-2.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-read-2.c scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-read-3.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 2 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-read-3.c scan-tree-dump-times vect "vectorized 2 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-read-4.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-read-4.c scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-read-6.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-write-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-write-1.c scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-write-2.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-write-2.c scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-write-3.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-write-3.c scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-write-5.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-bitfield-write-5.c scan-tree-dump-times vect "vectorized 1 loops" 1
For vect-bitfield-read-1.c, the dump has
gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: ==> examining pattern def statement: patt_31 = patt_30 >> 1;
gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: ==> examining statement: patt_31 = patt_30 >> 1;
gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: vect_is_simple_use: operand _ifc__27 & 4294967294, type of def: internal
gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: vect_is_simple_use: vectype vector(2) unsigned int
gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: vect_is_simple_use: operand 1, type of def: constant
gcc.dg/vect/vect-bitfield-read-1.c:25:23: missed: op not supported by target.
gcc.dg/vect/vect-bitfield-read-1.c:23:1: missed: not vectorized: relevant stmt not supported: patt_31 = patt_30 >> 1;
gcc.dg/vect/vect-bitfield-read-1.c:25:23: missed: bad operation or unsupported loop bound.
gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: ***** Analysis failed with vector mode V2SI
Rainer
Hi Rainer,
Thanks for reporting, I was actually expecting these! I thought about
pre-empting them by using a positive filter on the tests for aarch64 and
x86_64 as I knew those would pass, but I thought it would be better to
let other targets report failures since then you get a testsuite that
covers more targets than just what I'm able to check.
Are there any sparc architectures that would support these or should I
just xfail sparc*-*-* ?
For instance: I also saw PR107240 for which one of the write tests fails
on Power 7 BE. I'm suggesting adding an xfail for that one
Kind regards,
Andre
On 13/10/2022 12:39, Rainer Orth wrote:
> Hi Andre,
>
>> The bitposition calculation for the bitfield lowering in loop if conversion
>> was not
>> taking DECL_FIELD_OFFSET into account, which meant that it would result in
>> wrong bitpositions for bitfields that did not end up having representations
>> starting at the beginning of the struct.
>>
>> Bootstrappend and regression tested on aarch64-none-linux-gnu and
>> x86_64-pc-linux-gnu.
> I tried this patch together with the one for PR tree-optimization/107226
> on sparc-sun-solaris2.11 to check if it cures the bootstrap failure
> reported in PR tree-optimization/107232. While this restores bootstrap,
> several of the new tests FAIL:
>
> +FAIL: gcc.dg/vect/vect-bitfield-read-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-read-1.c scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-read-2.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-read-2.c scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-read-3.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 2 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-read-3.c scan-tree-dump-times vect "vectorized 2 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-read-4.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-read-4.c scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-read-6.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-write-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-write-1.c scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-write-2.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-write-2.c scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-write-3.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-write-3.c scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-write-5.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-bitfield-write-5.c scan-tree-dump-times vect "vectorized 1 loops" 1
>
> For vect-bitfield-read-1.c, the dump has
>
> gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: ==> examining pattern def statement: patt_31 = patt_30 >> 1;
> gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: ==> examining statement: patt_31 = patt_30 >> 1;
> gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: vect_is_simple_use: operand _ifc__27 & 4294967294, type of def: internal
> gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: vect_is_simple_use: vectype vector(2) unsigned int
> gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: vect_is_simple_use: operand 1, type of def: constant
> gcc.dg/vect/vect-bitfield-read-1.c:25:23: missed: op not supported by target.
> gcc.dg/vect/vect-bitfield-read-1.c:23:1: missed: not vectorized: relevant stmt not supported: patt_31 = patt_30 >> 1;
> gcc.dg/vect/vect-bitfield-read-1.c:25:23: missed: bad operation or unsupported loop bound.
> gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: ***** Analysis failed with vector mode V2SI
>
> Rainer
>
On Thu, 13 Oct 2022, Andre Vieira (lists) wrote:
> Hi Rainer,
>
> Thanks for reporting, I was actually expecting these! I thought about
> pre-empting them by using a positive filter on the tests for aarch64 and
> x86_64 as I knew those would pass, but I thought it would be better to let
> other targets report failures since then you get a testsuite that covers more
> targets than just what I'm able to check.
>
> Are there any sparc architectures that would support these or should I just
> xfail sparc*-*-* ?
>
> For instance: I also saw PR107240 for which one of the write tests fails on
> Power 7 BE. I'm suggesting adding an xfail for that one
for the failure below we seem to require vectorizing shifts for which I
think we have a vect_* target to check?
> Kind regards,
> Andre
>
> On 13/10/2022 12:39, Rainer Orth wrote:
> > Hi Andre,
> >
> >> The bitposition calculation for the bitfield lowering in loop if conversion
> >> was not
> >> taking DECL_FIELD_OFFSET into account, which meant that it would result in
> >> wrong bitpositions for bitfields that did not end up having representations
> >> starting at the beginning of the struct.
> >>
> >> Bootstrappend and regression tested on aarch64-none-linux-gnu and
> >> x86_64-pc-linux-gnu.
> > I tried this patch together with the one for PR tree-optimization/107226
> > on sparc-sun-solaris2.11 to check if it cures the bootstrap failure
> > reported in PR tree-optimization/107232. While this restores bootstrap,
> > several of the new tests FAIL:
> >
> > +FAIL: gcc.dg/vect/vect-bitfield-read-1.c -flto -ffat-lto-objects
> > scan-tree-dump-times vect "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-read-1.c scan-tree-dump-times vect
> > "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-read-2.c -flto -ffat-lto-objects
> > scan-tree-dump-times vect "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-read-2.c scan-tree-dump-times vect
> > "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-read-3.c -flto -ffat-lto-objects
> > scan-tree-dump-times vect "vectorized 2 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-read-3.c scan-tree-dump-times vect
> > "vectorized 2 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-read-4.c -flto -ffat-lto-objects
> > scan-tree-dump-times vect "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-read-4.c scan-tree-dump-times vect
> > "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-read-6.c -flto -ffat-lto-objects
> > scan-tree-dump-times vect "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-write-1.c -flto -ffat-lto-objects
> > scan-tree-dump-times vect "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-write-1.c scan-tree-dump-times vect
> > "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-write-2.c -flto -ffat-lto-objects
> > scan-tree-dump-times vect "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-write-2.c scan-tree-dump-times vect
> > "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-write-3.c -flto -ffat-lto-objects
> > scan-tree-dump-times vect "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-write-3.c scan-tree-dump-times vect
> > "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-write-5.c -flto -ffat-lto-objects
> > scan-tree-dump-times vect "vectorized 1 loops" 1
> > +FAIL: gcc.dg/vect/vect-bitfield-write-5.c scan-tree-dump-times vect
> > "vectorized 1 loops" 1
> >
> > For vect-bitfield-read-1.c, the dump has
> >
> > gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: ==> examining pattern def
> > statement: patt_31 = patt_30 >> 1;
> > gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: ==> examining statement:
> > patt_31 = patt_30 >> 1;
> > gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: vect_is_simple_use:
> > operand _ifc__27 & 4294967294, type of def: internal
> > gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: vect_is_simple_use:
> > vectype vector(2) unsigned int
> > gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: vect_is_simple_use:
> > operand 1, type of def: constant
> > gcc.dg/vect/vect-bitfield-read-1.c:25:23: missed: op not supported by
> > target.
> > gcc.dg/vect/vect-bitfield-read-1.c:23:1: missed: not vectorized: relevant
> > stmt not supported: patt_31 = patt_30 >> 1;
> > gcc.dg/vect/vect-bitfield-read-1.c:25:23: missed: bad operation or
> > unsupported loop bound.
> > gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: ***** Analysis failed with
> > vector mode V2SI
> >
> > Rainer
> >
>
On 13/10/2022 15:15, Richard Biener wrote:
> On Thu, 13 Oct 2022, Andre Vieira (lists) wrote:
>
>> Hi Rainer,
>>
>> Thanks for reporting, I was actually expecting these! I thought about
>> pre-empting them by using a positive filter on the tests for aarch64 and
>> x86_64 as I knew those would pass, but I thought it would be better to let
>> other targets report failures since then you get a testsuite that covers more
>> targets than just what I'm able to check.
>>
>> Are there any sparc architectures that would support these or should I just
>> xfail sparc*-*-* ?
>>
>> For instance: I also saw PR107240 for which one of the write tests fails on
>> Power 7 BE. I'm suggesting adding an xfail for that one
> for the failure below we seem to require vectorizing shifts for which I
> think we have a vect_* target to check?
'vect_shift' no sparc on the list of supported targets, so that should
do it, I'll add it when I add my fix for powerpc too.
>
>> Kind regards,
>> Andre
>>
>> On 13/10/2022 12:39, Rainer Orth wrote:
>>> Hi Andre,
>>>
>>>> The bitposition calculation for the bitfield lowering in loop if conversion
>>>> was not
>>>> taking DECL_FIELD_OFFSET into account, which meant that it would result in
>>>> wrong bitpositions for bitfields that did not end up having representations
>>>> starting at the beginning of the struct.
>>>>
>>>> Bootstrappend and regression tested on aarch64-none-linux-gnu and
>>>> x86_64-pc-linux-gnu.
>>> I tried this patch together with the one for PR tree-optimization/107226
>>> on sparc-sun-solaris2.11 to check if it cures the bootstrap failure
>>> reported in PR tree-optimization/107232. While this restores bootstrap,
>>> several of the new tests FAIL:
>>>
>>> +FAIL: gcc.dg/vect/vect-bitfield-read-1.c -flto -ffat-lto-objects
>>> scan-tree-dump-times vect "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-read-1.c scan-tree-dump-times vect
>>> "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-read-2.c -flto -ffat-lto-objects
>>> scan-tree-dump-times vect "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-read-2.c scan-tree-dump-times vect
>>> "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-read-3.c -flto -ffat-lto-objects
>>> scan-tree-dump-times vect "vectorized 2 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-read-3.c scan-tree-dump-times vect
>>> "vectorized 2 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-read-4.c -flto -ffat-lto-objects
>>> scan-tree-dump-times vect "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-read-4.c scan-tree-dump-times vect
>>> "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-read-6.c -flto -ffat-lto-objects
>>> scan-tree-dump-times vect "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-write-1.c -flto -ffat-lto-objects
>>> scan-tree-dump-times vect "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-write-1.c scan-tree-dump-times vect
>>> "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-write-2.c -flto -ffat-lto-objects
>>> scan-tree-dump-times vect "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-write-2.c scan-tree-dump-times vect
>>> "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-write-3.c -flto -ffat-lto-objects
>>> scan-tree-dump-times vect "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-write-3.c scan-tree-dump-times vect
>>> "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-write-5.c -flto -ffat-lto-objects
>>> scan-tree-dump-times vect "vectorized 1 loops" 1
>>> +FAIL: gcc.dg/vect/vect-bitfield-write-5.c scan-tree-dump-times vect
>>> "vectorized 1 loops" 1
>>>
>>> For vect-bitfield-read-1.c, the dump has
>>>
>>> gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: ==> examining pattern def
>>> statement: patt_31 = patt_30 >> 1;
>>> gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: ==> examining statement:
>>> patt_31 = patt_30 >> 1;
>>> gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: vect_is_simple_use:
>>> operand _ifc__27 & 4294967294, type of def: internal
>>> gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: vect_is_simple_use:
>>> vectype vector(2) unsigned int
>>> gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: vect_is_simple_use:
>>> operand 1, type of def: constant
>>> gcc.dg/vect/vect-bitfield-read-1.c:25:23: missed: op not supported by
>>> target.
>>> gcc.dg/vect/vect-bitfield-read-1.c:23:1: missed: not vectorized: relevant
>>> stmt not supported: patt_31 = patt_30 >> 1;
>>> gcc.dg/vect/vect-bitfield-read-1.c:25:23: missed: bad operation or
>>> unsupported loop bound.
>>> gcc.dg/vect/vect-bitfield-read-1.c:25:23: note: ***** Analysis failed with
>>> vector mode V2SI
>>>
>>> Rainer
>>>
new file mode 100644
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* PR tree-optimization/107229. */
+
+int a, c;
+struct {
+ long d;
+ int : 8;
+ int : 27;
+ int e : 21;
+} f;
+void g(int b) { a = a & 1; }
+int main() {
+ while (c)
+ g(f.e);
+ return 0;
+}
new file mode 100644
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* PR tree-optimization/107229. */
+
+int a, c;
+struct {
+ long f;
+ long g;
+ long d;
+ int : 8;
+ int : 27;
+ int e : 21;
+} f;
+void g(int b) { a = a & 1; }
+int main() {
+ while (c)
+ g(f.e);
+ return 0;
+}
new file mode 100644
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* PR tree-optimization/107229. */
+
+int a, c;
+struct {
+ long f;
+ long g;
+ long d;
+ int : 8;
+ int : 32;
+ int : 2;
+ int e : 21;
+} f;
+void g(int b) { a = a & 1; }
+int main() {
+ while (c)
+ g(f.e);
+ return 0;
+}
@@ -3298,10 +3298,20 @@ get_bitfield_rep (gassign *stmt, bool write, tree *bitpos,
*struct_expr = TREE_OPERAND (comp_ref, 0);
if (bitpos)
- *bitpos
- = fold_build2 (MINUS_EXPR, bitsizetype,
- DECL_FIELD_BIT_OFFSET (field_decl),
- DECL_FIELD_BIT_OFFSET (rep_decl));
+ {
+ tree bf_pos = fold_build2 (MULT_EXPR, bitsizetype,
+ DECL_FIELD_OFFSET (field_decl),
+ build_int_cst (bitsizetype, 8));
+ bf_pos = fold_build2 (PLUS_EXPR, bitsizetype, bf_pos,
+ DECL_FIELD_BIT_OFFSET (field_decl));
+ tree rep_pos = fold_build2 (MULT_EXPR, bitsizetype,
+ DECL_FIELD_OFFSET (rep_decl),
+ build_int_cst (bitsizetype, 8));
+ rep_pos = fold_build2 (PLUS_EXPR, bitsizetype, rep_pos,
+ DECL_FIELD_BIT_OFFSET (rep_decl));
+
+ *bitpos = fold_build2 (MINUS_EXPR, bitsizetype, bf_pos, rep_pos);
+ }
return rep_decl;