From: Qing Zhao <qing.zhao@oracle.com>
To: richard Biener <rguenther@suse.de>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: [GCC13][Patch][PR106457]improve array_at_struct_end_p for array objects (PR106457)
Date: Wed, 10 Aug 2022 21:39:38 +0000 [thread overview]
Message-ID: <D31D5674-04AD-48C7-8FD9-26BA374F8481@oracle.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]
Hi,
As mentioned in the bug report, I reopened this bug since the previous patch:
commit r13-1875-gff26f0ba68fe6e870f315d0601b596f889b89680
Author: Richard Biener <rguenther@suse.de>
Date: Thu Jul 28 10:07:32 2022 +0200
middle-end/106457 - improve array_at_struct_end_p for array objects
Array references to array objects are never at struct end.
Didn’t resolve this bug.
This is a new patch, and my current work on -fstrict-flex-array depends on this patch.
Please take a look at the patch and let me know whether it’s good for committing.
Thanks.
Qing.
======================================
[PATCH] middle-end/106457 - improve array_at_struct_end_p for array
objects (PR106457)
Array references are not handled correctly by current array_at_struct_end_p,
for the following array references:
Example 1: (from gcc/testsuite/gcc.dg/torture/pr50067-[1|2].c):
short a[32] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
... = (*((char(*)[32])&a[0]))[i+8]; // this array reference
Example 2: (from gcc/testsuite/gcc.target/aarch64/vadd_reduc-2.c):
int test (uint8_t *p, uint32_t t[1][1], int n) {
for (int i = 0; i < 4; i++, p++)
t[i][0] = ...; // this array reference
...
}
Example 3: (from gcc/testsuite/g++.dg/debug/debug5.C):
int a = 1;
int b = 1;
int e[a][b];
e[0][0] = 0; // this array reference
All the above array references are identified as TRUE by the current
array_at_struct_end_p, therefore treated as flexible array members.
Obviously, they are just simple array references, not an array refs
to the last field of a struture. The current array_at_struct_end_p handles
such array references incorrectly.
In order to handle array references correctly, we could recursively check
its first operand if it's a MEM_REF or COMPONENT_REF and stop as FALSE
when otherwise. This resolved all the issues for ARRAY_REF.
bootstrapped and regression tested on both X86 and Aarch64.
Multiple testing cases behave differently due to array_at_struct_end_p now
behave correctly (return FALSE now, then they are not flexible array member
anymore). Adjust these testing cases.
There is one regression for gcc/target/aarch64/vadd_reduc-2.c is left
unresolved since the loop transformation is changed due to the changed behavior
of array_at_struct_end_p, simple adjustment of the testing case doesnt work.
I will file a bug to record this regression.
gcc/ChangeLog:
PR middle-end/106457
* tree.cc (array_at_struct_end_p): Handle array objects recursively
through its first operand.
gcc/testsuite/ChangeLog:
PR middle-end/106457
* gcc.dg/torture/pr50067-1.c: Add -Wno-aggressive-loop-optimizations
to suppress warnings.
* gcc.dg/torture/pr50067-2.c: Likewise.
* gcc.target/aarch64/vadd_reduc-2.c: Likewise.
* gcc.target/i386/pr104059.c: Likewise.
The complete patch is at:
[-- Attachment #2: 0001-middle-end-106457-improve-array_at_struct_end_p-for-.patch --]
[-- Type: application/octet-stream, Size: 5665 bytes --]
From b09e4b56a4cfc11d1ea15226359643175f8466b0 Mon Sep 17 00:00:00 2001
From: Qing Zhao <qing.zhao@oracle.com>
Date: Tue, 9 Aug 2022 15:03:25 +0000
Subject: [PATCH] middle-end/106457 - improve array_at_struct_end_p for array
objects (PR106457)
Array references are not handled correctly by current array_at_struct_end_p,
for the following array references:
Example 1: (from gcc/testsuite/gcc.dg/torture/pr50067-[1|2].c):
short a[32] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
... = (*((char(*)[32])&a[0]))[i+8]; // this array reference
Example 2: (from gcc/testsuite/gcc.target/aarch64/vadd_reduc-2.c):
int test (uint8_t *p, uint32_t t[1][1], int n) {
for (int i = 0; i < 4; i++, p++)
t[i][0] = ...; // this array reference
...
}
Example 3: (from gcc/testsuite/g++.dg/debug/debug5.C):
int a = 1;
int b = 1;
int e[a][b];
e[0][0] = 0; // this array reference
All the above array references are identified as TRUE by the current
array_at_struct_end_p, therefore treated as flexible array members.
Obviously, they are just simple array references, not an array refs
to the last field of a struture. The current array_at_struct_end_p handles
such array references incorrectly.
In order to handle array references correctly, we could recursively check
its first operand if it's a MEM_REF or COMPONENT_REF and stop as FALSE
when otherwise. This resolved all the issues for ARRAY_REF.
bootstrapped and regression tested on both X86 and Aarch64.
Multiple testing cases behave differently due to array_at_struct_end_p now
behave correctly (return FALSE now, then they are not flexible array member
anymore). Adjust these testing cases.
There is one regression for gcc/target/aarch64/vadd_reduc-2.c is left
unresolved since the loop transformation is changed due to the changed behavior
of array_at_struct_end_p, simple adjustment of the testing case doesnt work.
I will file a bug to record this regression.
gcc/ChangeLog:
PR middle-end/106457
* tree.cc (array_at_struct_end_p): Handle array objects recursively
through its first operand.
gcc/testsuite/ChangeLog:
PR middle-end/106457
* gcc.dg/torture/pr50067-1.c: Add -Wno-aggressive-loop-optimizations
to suppress warnings.
* gcc.dg/torture/pr50067-2.c: Likewise.
* gcc.target/aarch64/vadd_reduc-2.c: Likewise.
* gcc.target/i386/pr104059.c: Likewise.
---
gcc/testsuite/gcc.dg/torture/pr50067-1.c | 1 +
gcc/testsuite/gcc.dg/torture/pr50067-2.c | 1 +
gcc/testsuite/gcc.target/aarch64/vadd_reduc-2.c | 2 +-
gcc/testsuite/gcc.target/i386/pr104059.c | 2 +-
gcc/tree.cc | 8 ++++----
5 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/torture/pr50067-1.c b/gcc/testsuite/gcc.dg/torture/pr50067-1.c
index 8201ebfdc91b..8b6c84d0a3c1 100644
--- a/gcc/testsuite/gcc.dg/torture/pr50067-1.c
+++ b/gcc/testsuite/gcc.dg/torture/pr50067-1.c
@@ -1,4 +1,5 @@
/* { dg-do run } */
+/* { dg-options "-Wno-aggressive-loop-optimizations" } */
/* Make sure data-dependence analysis does not compute a bogus
distance vector for the different sized accesses. */
diff --git a/gcc/testsuite/gcc.dg/torture/pr50067-2.c b/gcc/testsuite/gcc.dg/torture/pr50067-2.c
index f9728a766786..d130c23ef435 100644
--- a/gcc/testsuite/gcc.dg/torture/pr50067-2.c
+++ b/gcc/testsuite/gcc.dg/torture/pr50067-2.c
@@ -1,4 +1,5 @@
/* { dg-do run } */
+/* { dg-options "-Wno-aggressive-loop-optimizations" } */
/* Make sure data-dependence analysis does not compute a bogus
distance vector for the different sized accesses. */
diff --git a/gcc/testsuite/gcc.target/aarch64/vadd_reduc-2.c b/gcc/testsuite/gcc.target/aarch64/vadd_reduc-2.c
index 0ad96954ff7d..5f9e08d53ffa 100644
--- a/gcc/testsuite/gcc.target/aarch64/vadd_reduc-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/vadd_reduc-2.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-additional-options "-O3 -std=c99" } */
+/* { dg-additional-options "-O3 -std=c99 -Wno-aggressive-loop-optimizations" } */
/* { dg-final { check-function-bodies "**" "" "" } } */
#include <stdint.h>
diff --git a/gcc/testsuite/gcc.target/i386/pr104059.c b/gcc/testsuite/gcc.target/i386/pr104059.c
index 4815fa38d217..2ae87eac10b3 100644
--- a/gcc/testsuite/gcc.target/i386/pr104059.c
+++ b/gcc/testsuite/gcc.target/i386/pr104059.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-mavx2 -O2 -fdump-rtl-cprop_hardreg-details" } */
+/* { dg-options "-mavx2 -O2 -fdump-rtl-cprop_hardreg-details -Wno-aggressive-loop-optimizations" } */
/* { dg-final { scan-rtl-dump-not {replaced reg [0-9]* with [0-9]*} "cprop_hardreg" } } */
#include<stdint.h>
diff --git a/gcc/tree.cc b/gcc/tree.cc
index fed1434d141d..f34d7efb3de1 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -12692,6 +12692,10 @@ array_at_struct_end_p (tree ref)
{
atype = TREE_TYPE (TREE_OPERAND (ref, 0));
ref = TREE_OPERAND (ref, 0);
+ if (TREE_CODE (ref) == COMPONENT_REF || TREE_CODE (ref) == MEM_REF)
+ return array_at_struct_end_p (ref);
+ else
+ return false;
}
else if (TREE_CODE (ref) == COMPONENT_REF
&& TREE_CODE (TREE_TYPE (TREE_OPERAND (ref, 1))) == ARRAY_TYPE)
@@ -12778,10 +12782,6 @@ array_at_struct_end_p (tree ref)
&& DECL_SIZE_UNIT (ref)
&& TREE_CODE (DECL_SIZE_UNIT (ref)) == INTEGER_CST)
{
- /* If the object itself is the array it is not at struct end. */
- if (DECL_P (ref_to_array))
- return false;
-
/* Check whether the array domain covers all of the available
padding. */
poly_int64 offset;
--
2.27.0
next reply other threads:[~2022-08-10 21:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-10 21:39 Qing Zhao [this message]
2022-08-11 7:40 ` Richard Biener
2022-08-11 13:26 ` Qing Zhao
2022-08-12 6:46 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D31D5674-04AD-48C7-8FD9-26BA374F8481@oracle.com \
--to=qing.zhao@oracle.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rguenther@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).