public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* ifcvt: Fix bitpos calculation in bitfield lowering [PR107229]
@ 2022-10-12 17:29 Andre Vieira (lists)
  2022-10-13  8:14 ` Richard Biener
  2022-10-13 11:39 ` Rainer Orth
  0 siblings, 2 replies; 8+ messages in thread
From: Andre Vieira (lists) @ 2022-10-12 17:29 UTC (permalink / raw)
  To: gcc-patches; +Cc: Richard Sandiford, Richard Biener

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

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.

[-- Attachment #2: PR107229.patch --]
[-- Type: text/plain, Size: 2672 bytes --]

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..33160ddef80cbd75c2a927fb50bddd792bbf5dd4 100644
--- a/gcc/tree-if-conv.cc
+++ b/gcc/tree-if-conv.cc
@@ -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;
 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ifcvt: Fix bitpos calculation in bitfield lowering [PR107229]
  2022-10-12 17:29 ifcvt: Fix bitpos calculation in bitfield lowering [PR107229] Andre Vieira (lists)
@ 2022-10-13  8:14 ` Richard Biener
  2022-10-13 10:15   ` Andre Vieira (lists)
  2022-10-13 11:39 ` Rainer Orth
  1 sibling, 1 reply; 8+ messages in thread
From: Richard Biener @ 2022-10-13  8:14 UTC (permalink / raw)
  To: Andre Vieira (lists); +Cc: gcc-patches, Richard Sandiford

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ifcvt: Fix bitpos calculation in bitfield lowering [PR107229]
  2022-10-13  8:14 ` Richard Biener
@ 2022-10-13 10:15   ` Andre Vieira (lists)
  2022-10-13 10:18     ` Richard Biener
  0 siblings, 1 reply; 8+ messages in thread
From: Andre Vieira (lists) @ 2022-10-13 10:15 UTC (permalink / raw)
  To: Richard Biener; +Cc: gcc-patches, Richard Sandiford

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

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.

[-- Attachment #2: PR107229-2.patch --]
[-- Type: text/plain, Size: 3681 bytes --]

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;
 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ifcvt: Fix bitpos calculation in bitfield lowering [PR107229]
  2022-10-13 10:15   ` Andre Vieira (lists)
@ 2022-10-13 10:18     ` Richard Biener
  0 siblings, 0 replies; 8+ messages in thread
From: Richard Biener @ 2022-10-13 10:18 UTC (permalink / raw)
  To: Andre Vieira (lists); +Cc: gcc-patches, Richard Sandiford

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.
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ifcvt: Fix bitpos calculation in bitfield lowering [PR107229]
  2022-10-12 17:29 ifcvt: Fix bitpos calculation in bitfield lowering [PR107229] Andre Vieira (lists)
  2022-10-13  8:14 ` Richard Biener
@ 2022-10-13 11:39 ` Rainer Orth
  2022-10-13 13:55   ` Andre Vieira (lists)
  1 sibling, 1 reply; 8+ messages in thread
From: Rainer Orth @ 2022-10-13 11:39 UTC (permalink / raw)
  To: Andre Vieira (lists) via Gcc-patches
  Cc: Andre Vieira (lists), Richard Sandiford, Richard Biener

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

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ifcvt: Fix bitpos calculation in bitfield lowering [PR107229]
  2022-10-13 11:39 ` Rainer Orth
@ 2022-10-13 13:55   ` Andre Vieira (lists)
  2022-10-13 14:15     ` Richard Biener
  0 siblings, 1 reply; 8+ messages in thread
From: Andre Vieira (lists) @ 2022-10-13 13:55 UTC (permalink / raw)
  To: Rainer Orth, Andre Vieira (lists) via Gcc-patches
  Cc: Richard Sandiford, Richard Biener

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
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ifcvt: Fix bitpos calculation in bitfield lowering [PR107229]
  2022-10-13 13:55   ` Andre Vieira (lists)
@ 2022-10-13 14:15     ` Richard Biener
  2022-10-13 14:42       ` Andre Vieira (lists)
  0 siblings, 1 reply; 8+ messages in thread
From: Richard Biener @ 2022-10-13 14:15 UTC (permalink / raw)
  To: Andre Vieira (lists)
  Cc: Rainer Orth, Andre Vieira (lists) via Gcc-patches, Richard Sandiford

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
> >
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ifcvt: Fix bitpos calculation in bitfield lowering [PR107229]
  2022-10-13 14:15     ` Richard Biener
@ 2022-10-13 14:42       ` Andre Vieira (lists)
  0 siblings, 0 replies; 8+ messages in thread
From: Andre Vieira (lists) @ 2022-10-13 14:42 UTC (permalink / raw)
  To: Richard Biener
  Cc: Rainer Orth, Andre Vieira (lists) via Gcc-patches, Richard Sandiford


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
>>>

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-10-13 14:43 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-12 17:29 ifcvt: Fix bitpos calculation in bitfield lowering [PR107229] Andre Vieira (lists)
2022-10-13  8:14 ` Richard Biener
2022-10-13 10:15   ` Andre Vieira (lists)
2022-10-13 10:18     ` Richard Biener
2022-10-13 11:39 ` Rainer Orth
2022-10-13 13:55   ` Andre Vieira (lists)
2022-10-13 14:15     ` Richard Biener
2022-10-13 14:42       ` Andre Vieira (lists)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).