public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] tree-sra: Avoid returns of references to SRA candidates
@ 2023-11-27 18:16 Martin Jambor
  2023-11-28  8:05 ` Richard Biener
  0 siblings, 1 reply; 11+ messages in thread
From: Martin Jambor @ 2023-11-27 18:16 UTC (permalink / raw)
  To: GCC Patches; +Cc: Richard Biener, Jan Hubicka

Hi,

The enhancement to address PR 109849 contained an importsnt thinko,
and that any reference that is passed to a function and does not
escape, must also not happen to be aliased by the return value of the
function.  This has quickly transpired as bugs PR 112711 and PR
112721.

Just as IPA-modref does a good enough job to allow us to rely on the
escaped set of variables, it sems to be doing well also on updating
EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
exactly the situation we need to avoid.  Of course, if a call
statement ignores any returned value, we also do not need to check the
flag.

Hopefully this does not pessimize things too much, I have verified
that the PR 109849 testcae remains quick and so should also the
benchmark it is derived from.

The patch has passed bootstrap and testing on x86_64-linux, OK for
master?

Thanks,

Martin


gcc/ChangeLog:

2023-11-27  Martin Jambor  <mjambor@suse.cz>

	PR tree-optimization/112711
	PR tree-optimization/112721
	* tree-sra.cc (build_access_from_call_arg): New parameter
	CAN_BE_RETURNED, disqualify any candidate passed by reference if it is
	true.  Adjust leading comment.
	(scan_function): Pass appropriate value to CAN_BE_RETURNED of
	build_access_from_call_arg.

gcc/testsuite/ChangeLog:

2023-11-27  Martin Jambor  <mjambor@suse.cz>

	PR tree-optimization/112711
	PR tree-optimization/112721
	* g++.dg/tree-ssa/pr112711.C: New test.
	* gcc.dg/tree-ssa/pr112721.c: Likewise.
---
 gcc/testsuite/g++.dg/tree-ssa/pr112711.C | 31 ++++++++++++++++++
 gcc/testsuite/gcc.dg/tree-ssa/pr112721.c | 26 +++++++++++++++
 gcc/tree-sra.cc                          | 40 ++++++++++++++++++------
 3 files changed, 88 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr112711.C
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr112721.c

diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr112711.C b/gcc/testsuite/g++.dg/tree-ssa/pr112711.C
new file mode 100644
index 00000000000..c04524b04a7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr112711.C
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-options "-O1" } */
+
+typedef          int i32;
+typedef unsigned int u32;
+
+static inline void write_i32(void *memory, i32 value) {
+  // swap i32 bytes as if it was u32:
+  u32 u_value = value;
+  value = __builtin_bswap32(u_value);
+
+  // llvm infers '1' alignment from destination type
+  __builtin_memcpy(__builtin_assume_aligned(memory, 1), &value, sizeof(value));
+}
+
+__attribute__((noipa))
+static void bug (void) {
+  #define assert_eq(lhs, rhs) if (lhs != rhs) __builtin_trap()
+
+  unsigned char data[5];
+  write_i32(data, -1362446643);
+  assert_eq(data[0], 0xAE);
+  assert_eq(data[1], 0xCA);
+  write_i32(data + 1, -1362446643);
+  assert_eq(data[1], 0xAE);
+}
+
+int main() {
+    bug();
+    return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr112721.c b/gcc/testsuite/gcc.dg/tree-ssa/pr112721.c
new file mode 100644
index 00000000000..adf62613266
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr112721.c
@@ -0,0 +1,26 @@
+/* { dg-do run } */
+/* { dg-options "-O1" } */
+
+unsigned * volatile gv;
+
+struct a {
+  int b;
+};
+int c, e;
+long d;
+unsigned * __attribute__((noinline))
+f(unsigned *g) {
+  for (; c;)
+    e = d;
+  return gv ? gv : g;
+}
+int main() {
+  int *h;
+  struct a i = {8};
+  int *j = &i.b;
+  h = (unsigned *) f(j);
+  *h = 0;
+  if (i.b != 0)
+    __builtin_abort ();
+  return 0;
+}
diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index 3a0d52675fe..6a759783990 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -1268,18 +1268,27 @@ abnormal_edge_after_stmt_p (gimple *stmt, enum out_edge_check *oe_check)
 }
 
 /* Scan expression EXPR which is an argument of a call and create access
-   structures for all accesses to candidates for scalarization.  Return true if
-   any access has been inserted.  STMT must be the statement from which the
-   expression is taken.  */
+   structures for all accesses to candidates for scalarization.  Return true
+   if any access has been inserted.  STMT must be the statement from which the
+   expression is taken.  CAN_BE_RETURNED must be true if call argument flags
+   do not rule out that the argument is directly returned.  OE_CHECK is used
+   to remember result of a test for abnormal outgoing edges after this
+   statement.  */
 
 static bool
-build_access_from_call_arg (tree expr, gimple *stmt,
+build_access_from_call_arg (tree expr, gimple *stmt, bool can_be_returned,
 			    enum out_edge_check *oe_check)
 {
   if (TREE_CODE (expr) == ADDR_EXPR)
     {
       tree base = get_base_address (TREE_OPERAND (expr, 0));
 
+      if (can_be_returned)
+	{
+	  disqualify_base_of_expr (base, "Address possibly returned, "
+				   "leading to an alis SRA may not know.");
+	  return false;
+	}
       if (abnormal_edge_after_stmt_p (stmt, oe_check))
 	{
 	  disqualify_base_of_expr (base, "May lead to need to add statements "
@@ -1508,12 +1517,25 @@ scan_function (void)
 	    case GIMPLE_CALL:
 	      {
 		enum out_edge_check oe_check = SRA_OUTGOING_EDGES_UNCHECKED;
-		for (i = 0; i < gimple_call_num_args (stmt); i++)
-		  ret |= build_access_from_call_arg (gimple_call_arg (stmt, i),
-						     stmt, &oe_check);
+		gcall *call = as_a <gcall *> (stmt);
+		for (i = 0; i < gimple_call_num_args (call); i++)
+		  {
+		    bool can_be_returned;
+		    if (gimple_call_lhs (call))
+		      {
+			int af = gimple_call_arg_flags (call, i);
+			can_be_returned = !(af & EAF_NOT_RETURNED_DIRECTLY);
+		      }
+		    else
+		      can_be_returned = false;
+		    ret |= build_access_from_call_arg (gimple_call_arg (call,
+									i),
+						       stmt, can_be_returned,
+						       &oe_check);
+		  }
 		if (gimple_call_chain(stmt))
-		  ret |= build_access_from_call_arg (gimple_call_chain(stmt),
-						     stmt, &oe_check);
+		  ret |= build_access_from_call_arg (gimple_call_chain(call),
+						     stmt, false,  &oe_check);
 	      }
 
 	      t = gimple_call_lhs (stmt);
-- 
2.43.0


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

* Re: [PATCH] tree-sra: Avoid returns of references to SRA candidates
  2023-11-27 18:16 [PATCH] tree-sra: Avoid returns of references to SRA candidates Martin Jambor
@ 2023-11-28  8:05 ` Richard Biener
  2023-11-28 16:16   ` Martin Jambor
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Biener @ 2023-11-28  8:05 UTC (permalink / raw)
  To: Martin Jambor; +Cc: GCC Patches, Jan Hubicka

On Mon, 27 Nov 2023, Martin Jambor wrote:

> Hi,
> 
> The enhancement to address PR 109849 contained an importsnt thinko,
> and that any reference that is passed to a function and does not
> escape, must also not happen to be aliased by the return value of the
> function.  This has quickly transpired as bugs PR 112711 and PR
> 112721.
> 
> Just as IPA-modref does a good enough job to allow us to rely on the
> escaped set of variables, it sems to be doing well also on updating
> EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
> exactly the situation we need to avoid.  Of course, if a call
> statement ignores any returned value, we also do not need to check the
> flag.

But what about EAF_NOT_RETURNED_INDIRECTLY?  Don't you need to
verify the parameter doesn't escape through the return at all?

> 
> Hopefully this does not pessimize things too much, I have verified
> that the PR 109849 testcae remains quick and so should also the
> benchmark it is derived from.
> 
> The patch has passed bootstrap and testing on x86_64-linux, OK for
> master?
> 
> Thanks,
> 
> Martin
> 
> 
> gcc/ChangeLog:
> 
> 2023-11-27  Martin Jambor  <mjambor@suse.cz>
> 
> 	PR tree-optimization/112711
> 	PR tree-optimization/112721
> 	* tree-sra.cc (build_access_from_call_arg): New parameter
> 	CAN_BE_RETURNED, disqualify any candidate passed by reference if it is
> 	true.  Adjust leading comment.
> 	(scan_function): Pass appropriate value to CAN_BE_RETURNED of
> 	build_access_from_call_arg.
> 
> gcc/testsuite/ChangeLog:
> 
> 2023-11-27  Martin Jambor  <mjambor@suse.cz>
> 
> 	PR tree-optimization/112711
> 	PR tree-optimization/112721
> 	* g++.dg/tree-ssa/pr112711.C: New test.
> 	* gcc.dg/tree-ssa/pr112721.c: Likewise.
> ---
>  gcc/testsuite/g++.dg/tree-ssa/pr112711.C | 31 ++++++++++++++++++
>  gcc/testsuite/gcc.dg/tree-ssa/pr112721.c | 26 +++++++++++++++
>  gcc/tree-sra.cc                          | 40 ++++++++++++++++++------
>  3 files changed, 88 insertions(+), 9 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr112711.C
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr112721.c
> 
> diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr112711.C b/gcc/testsuite/g++.dg/tree-ssa/pr112711.C
> new file mode 100644
> index 00000000000..c04524b04a7
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/tree-ssa/pr112711.C
> @@ -0,0 +1,31 @@
> +/* { dg-do run } */
> +/* { dg-options "-O1" } */
> +
> +typedef          int i32;
> +typedef unsigned int u32;
> +
> +static inline void write_i32(void *memory, i32 value) {
> +  // swap i32 bytes as if it was u32:
> +  u32 u_value = value;
> +  value = __builtin_bswap32(u_value);
> +
> +  // llvm infers '1' alignment from destination type
> +  __builtin_memcpy(__builtin_assume_aligned(memory, 1), &value, sizeof(value));
> +}
> +
> +__attribute__((noipa))
> +static void bug (void) {
> +  #define assert_eq(lhs, rhs) if (lhs != rhs) __builtin_trap()
> +
> +  unsigned char data[5];
> +  write_i32(data, -1362446643);
> +  assert_eq(data[0], 0xAE);
> +  assert_eq(data[1], 0xCA);
> +  write_i32(data + 1, -1362446643);
> +  assert_eq(data[1], 0xAE);
> +}
> +
> +int main() {
> +    bug();
> +    return 0;
> +}
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr112721.c b/gcc/testsuite/gcc.dg/tree-ssa/pr112721.c
> new file mode 100644
> index 00000000000..adf62613266
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr112721.c
> @@ -0,0 +1,26 @@
> +/* { dg-do run } */
> +/* { dg-options "-O1" } */
> +
> +unsigned * volatile gv;
> +
> +struct a {
> +  int b;
> +};
> +int c, e;
> +long d;
> +unsigned * __attribute__((noinline))
> +f(unsigned *g) {
> +  for (; c;)
> +    e = d;
> +  return gv ? gv : g;
> +}
> +int main() {
> +  int *h;
> +  struct a i = {8};
> +  int *j = &i.b;
> +  h = (unsigned *) f(j);
> +  *h = 0;
> +  if (i.b != 0)
> +    __builtin_abort ();
> +  return 0;
> +}
> diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
> index 3a0d52675fe..6a759783990 100644
> --- a/gcc/tree-sra.cc
> +++ b/gcc/tree-sra.cc
> @@ -1268,18 +1268,27 @@ abnormal_edge_after_stmt_p (gimple *stmt, enum out_edge_check *oe_check)
>  }
>  
>  /* Scan expression EXPR which is an argument of a call and create access
> -   structures for all accesses to candidates for scalarization.  Return true if
> -   any access has been inserted.  STMT must be the statement from which the
> -   expression is taken.  */
> +   structures for all accesses to candidates for scalarization.  Return true
> +   if any access has been inserted.  STMT must be the statement from which the
> +   expression is taken.  CAN_BE_RETURNED must be true if call argument flags
> +   do not rule out that the argument is directly returned.  OE_CHECK is used
> +   to remember result of a test for abnormal outgoing edges after this
> +   statement.  */
>  
>  static bool
> -build_access_from_call_arg (tree expr, gimple *stmt,
> +build_access_from_call_arg (tree expr, gimple *stmt, bool can_be_returned,
>  			    enum out_edge_check *oe_check)
>  {
>    if (TREE_CODE (expr) == ADDR_EXPR)
>      {
>        tree base = get_base_address (TREE_OPERAND (expr, 0));
>  
> +      if (can_be_returned)
> +	{
> +	  disqualify_base_of_expr (base, "Address possibly returned, "
> +				   "leading to an alis SRA may not know.");
> +	  return false;
> +	}
>        if (abnormal_edge_after_stmt_p (stmt, oe_check))
>  	{
>  	  disqualify_base_of_expr (base, "May lead to need to add statements "
> @@ -1508,12 +1517,25 @@ scan_function (void)
>  	    case GIMPLE_CALL:
>  	      {
>  		enum out_edge_check oe_check = SRA_OUTGOING_EDGES_UNCHECKED;
> -		for (i = 0; i < gimple_call_num_args (stmt); i++)
> -		  ret |= build_access_from_call_arg (gimple_call_arg (stmt, i),
> -						     stmt, &oe_check);
> +		gcall *call = as_a <gcall *> (stmt);
> +		for (i = 0; i < gimple_call_num_args (call); i++)
> +		  {
> +		    bool can_be_returned;
> +		    if (gimple_call_lhs (call))
> +		      {
> +			int af = gimple_call_arg_flags (call, i);
> +			can_be_returned = !(af & EAF_NOT_RETURNED_DIRECTLY);
> +		      }
> +		    else
> +		      can_be_returned = false;
> +		    ret |= build_access_from_call_arg (gimple_call_arg (call,
> +									i),
> +						       stmt, can_be_returned,
> +						       &oe_check);
> +		  }
>  		if (gimple_call_chain(stmt))
> -		  ret |= build_access_from_call_arg (gimple_call_chain(stmt),
> -						     stmt, &oe_check);
> +		  ret |= build_access_from_call_arg (gimple_call_chain(call),
> +						     stmt, false,  &oe_check);
>  	      }
>  
>  	      t = gimple_call_lhs (stmt);
> 

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

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

* Re: [PATCH] tree-sra: Avoid returns of references to SRA candidates
  2023-11-28  8:05 ` Richard Biener
@ 2023-11-28 16:16   ` Martin Jambor
  2023-11-28 16:33     ` Richard Biener
  0 siblings, 1 reply; 11+ messages in thread
From: Martin Jambor @ 2023-11-28 16:16 UTC (permalink / raw)
  To: Richard Biener; +Cc: GCC Patches, Jan Hubicka

On Tue, Nov 28 2023, Richard Biener wrote:
> On Mon, 27 Nov 2023, Martin Jambor wrote:
>
>> Hi,
>> 
>> The enhancement to address PR 109849 contained an importsnt thinko,
>> and that any reference that is passed to a function and does not
>> escape, must also not happen to be aliased by the return value of the
>> function.  This has quickly transpired as bugs PR 112711 and PR
>> 112721.
>> 
>> Just as IPA-modref does a good enough job to allow us to rely on the
>> escaped set of variables, it sems to be doing well also on updating
>> EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
>> exactly the situation we need to avoid.  Of course, if a call
>> statement ignores any returned value, we also do not need to check the
>> flag.
>
> But what about EAF_NOT_RETURNED_INDIRECTLY?  Don't you need to
> verify the parameter doesn't escape through the return at all?
>

I thought EAF_NOT_RETURNED_INDIRECTLY prohibits things like "return
param->next" but those are not a problem (whatever next points to cannot
be an SRA candidate and any ADDR_EXPR storing its address there would
trigger a disqualification or at least an assert).  But I guess I am
wrong, what is actually the exact meaning of the flag?

Thanks,

Martin

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

* Re: [PATCH] tree-sra: Avoid returns of references to SRA candidates
  2023-11-28 16:16   ` Martin Jambor
@ 2023-11-28 16:33     ` Richard Biener
  2023-11-28 16:59       ` Jan Hubicka
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Biener @ 2023-11-28 16:33 UTC (permalink / raw)
  To: Martin Jambor; +Cc: GCC Patches, Jan Hubicka

On Tue, 28 Nov 2023, Martin Jambor wrote:

> On Tue, Nov 28 2023, Richard Biener wrote:
> > On Mon, 27 Nov 2023, Martin Jambor wrote:
> >
> >> Hi,
> >> 
> >> The enhancement to address PR 109849 contained an importsnt thinko,
> >> and that any reference that is passed to a function and does not
> >> escape, must also not happen to be aliased by the return value of the
> >> function.  This has quickly transpired as bugs PR 112711 and PR
> >> 112721.
> >> 
> >> Just as IPA-modref does a good enough job to allow us to rely on the
> >> escaped set of variables, it sems to be doing well also on updating
> >> EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
> >> exactly the situation we need to avoid.  Of course, if a call
> >> statement ignores any returned value, we also do not need to check the
> >> flag.
> >
> > But what about EAF_NOT_RETURNED_INDIRECTLY?  Don't you need to
> > verify the parameter doesn't escape through the return at all?
> >
> 
> I thought EAF_NOT_RETURNED_INDIRECTLY prohibits things like "return
> param->next" but those are not a problem (whatever next points to cannot
> be an SRA candidate and any ADDR_EXPR storing its address there would
> trigger a disqualification or at least an assert).  But I guess I am
> wrong, what is actually the exact meaning of the flag?

I thought it's return (x.ptr = param, &x);

so the parameter is reachable from the return value.

But let's Honza answer...

Richard.

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

* Re: [PATCH] tree-sra: Avoid returns of references to SRA candidates
  2023-11-28 16:33     ` Richard Biener
@ 2023-11-28 16:59       ` Jan Hubicka
  2023-11-28 17:30         ` Richard Biener
  2023-11-29 12:04         ` Martin Jambor
  0 siblings, 2 replies; 11+ messages in thread
From: Jan Hubicka @ 2023-11-28 16:59 UTC (permalink / raw)
  To: Richard Biener; +Cc: Martin Jambor, GCC Patches

> On Tue, 28 Nov 2023, Martin Jambor wrote:
> 
> > On Tue, Nov 28 2023, Richard Biener wrote:
> > > On Mon, 27 Nov 2023, Martin Jambor wrote:
> > >
> > >> Hi,
> > >> 
> > >> The enhancement to address PR 109849 contained an importsnt thinko,
> > >> and that any reference that is passed to a function and does not
> > >> escape, must also not happen to be aliased by the return value of the
> > >> function.  This has quickly transpired as bugs PR 112711 and PR
> > >> 112721.
> > >> 
> > >> Just as IPA-modref does a good enough job to allow us to rely on the
> > >> escaped set of variables, it sems to be doing well also on updating
> > >> EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
> > >> exactly the situation we need to avoid.  Of course, if a call
> > >> statement ignores any returned value, we also do not need to check the
> > >> flag.
> > >
> > > But what about EAF_NOT_RETURNED_INDIRECTLY?  Don't you need to
> > > verify the parameter doesn't escape through the return at all?
> > >
> > 
> > I thought EAF_NOT_RETURNED_INDIRECTLY prohibits things like "return
> > param->next" but those are not a problem (whatever next points to cannot
> > be an SRA candidate and any ADDR_EXPR storing its address there would
> > trigger a disqualification or at least an assert).  But I guess I am
> > wrong, what is actually the exact meaning of the flag?
> 
> I thought it's return (x.ptr = param, &x);
> 
> so the parameter is reachable from the return value.
> 
> But let's Honza answer...
It is same difference as direct/indirect escape. so it check whether
values pointed to by arg can be possibly returned.  Indeed maybe we
should think of better name - the other interpretation did not even
occur to me, but it makes sense.

Honza
> 
> Richard.

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

* Re: [PATCH] tree-sra: Avoid returns of references to SRA candidates
  2023-11-28 16:59       ` Jan Hubicka
@ 2023-11-28 17:30         ` Richard Biener
  2023-11-28 17:38           ` Jan Hubicka
  2023-11-29 12:04         ` Martin Jambor
  1 sibling, 1 reply; 11+ messages in thread
From: Richard Biener @ 2023-11-28 17:30 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: Martin Jambor, GCC Patches



> Am 28.11.2023 um 17:59 schrieb Jan Hubicka <hubicka@ucw.cz>:
> 
> 
>> 
>>> On Tue, 28 Nov 2023, Martin Jambor wrote:
>>> 
>>> On Tue, Nov 28 2023, Richard Biener wrote:
>>>> On Mon, 27 Nov 2023, Martin Jambor wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> The enhancement to address PR 109849 contained an importsnt thinko,
>>>>> and that any reference that is passed to a function and does not
>>>>> escape, must also not happen to be aliased by the return value of the
>>>>> function.  This has quickly transpired as bugs PR 112711 and PR
>>>>> 112721.
>>>>> 
>>>>> Just as IPA-modref does a good enough job to allow us to rely on the
>>>>> escaped set of variables, it sems to be doing well also on updating
>>>>> EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
>>>>> exactly the situation we need to avoid.  Of course, if a call
>>>>> statement ignores any returned value, we also do not need to check the
>>>>> flag.
>>>> 
>>>> But what about EAF_NOT_RETURNED_INDIRECTLY?  Don't you need to
>>>> verify the parameter doesn't escape through the return at all?
>>>> 
>>> 
>>> I thought EAF_NOT_RETURNED_INDIRECTLY prohibits things like "return
>>> param->next" but those are not a problem (whatever next points to cannot
>>> be an SRA candidate and any ADDR_EXPR storing its address there would
>>> trigger a disqualification or at least an assert).  But I guess I am
>>> wrong, what is actually the exact meaning of the flag?
>> 
>> I thought it's return (x.ptr = param, &x);
>> 
>> so the parameter is reachable from the return value.
>> 
>> But let's Honza answer...
> It is same difference as direct/indirect escape. so it check whether
> values pointed to by arg can be possibly returned.  Indeed maybe we
> should think of better name - the other interpretation did not even
> occur to me, but it makes sense.

So does the directly returned flag cover my interpretation of indirect or is there a hole?

Richard 

> Honza
>> 
>> Richard.

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

* Re: [PATCH] tree-sra: Avoid returns of references to SRA candidates
  2023-11-28 17:30         ` Richard Biener
@ 2023-11-28 17:38           ` Jan Hubicka
  2023-11-28 18:35             ` Richard Biener
  0 siblings, 1 reply; 11+ messages in thread
From: Jan Hubicka @ 2023-11-28 17:38 UTC (permalink / raw)
  To: Richard Biener; +Cc: Martin Jambor, GCC Patches

> 
> 
> > Am 28.11.2023 um 17:59 schrieb Jan Hubicka <hubicka@ucw.cz>:
> > 
> > 
> >> 
> >>> On Tue, 28 Nov 2023, Martin Jambor wrote:
> >>> 
> >>> On Tue, Nov 28 2023, Richard Biener wrote:
> >>>> On Mon, 27 Nov 2023, Martin Jambor wrote:
> >>>> 
> >>>>> Hi,
> >>>>> 
> >>>>> The enhancement to address PR 109849 contained an importsnt thinko,
> >>>>> and that any reference that is passed to a function and does not
> >>>>> escape, must also not happen to be aliased by the return value of the
> >>>>> function.  This has quickly transpired as bugs PR 112711 and PR
> >>>>> 112721.
> >>>>> 
> >>>>> Just as IPA-modref does a good enough job to allow us to rely on the
> >>>>> escaped set of variables, it sems to be doing well also on updating
> >>>>> EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
> >>>>> exactly the situation we need to avoid.  Of course, if a call
> >>>>> statement ignores any returned value, we also do not need to check the
> >>>>> flag.
> >>>> 
> >>>> But what about EAF_NOT_RETURNED_INDIRECTLY?  Don't you need to
> >>>> verify the parameter doesn't escape through the return at all?
> >>>> 
> >>> 
> >>> I thought EAF_NOT_RETURNED_INDIRECTLY prohibits things like "return
> >>> param->next" but those are not a problem (whatever next points to cannot
> >>> be an SRA candidate and any ADDR_EXPR storing its address there would
> >>> trigger a disqualification or at least an assert).  But I guess I am
> >>> wrong, what is actually the exact meaning of the flag?
> >> 
> >> I thought it's return (x.ptr = param, &x);
> >> 
> >> so the parameter is reachable from the return value.
> >> 
> >> But let's Honza answer...
> > It is same difference as direct/indirect escape. so it check whether
> > values pointed to by arg can be possibly returned.  Indeed maybe we
> > should think of better name - the other interpretation did not even
> > occur to me, but it makes sense.
> 
> So does the directly returned flag cover my interpretation of indirect or is there a hole?

Stores goes through:

          /* Handle *lhs = name.  */
          if (assign && gimple_assign_rhs1 (assign) == name)
            {                             
              if (dump_file)             
                fprintf (dump_file, "%*s  ssa name saved to memory\n",
                         m_depth * 4, "");
              m_lattice[index].merge (0);
            }

So we give up on any flags.  So far modref does not try to track values
in memory at all. I suppose PTA info does not help me here, since the
memory values is stored to may not escape but later it may be read and
copied into something that does escape?

Honza
> 
> Richard 
> 
> > Honza
> >> 
> >> Richard.

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

* Re: [PATCH] tree-sra: Avoid returns of references to SRA candidates
  2023-11-28 17:38           ` Jan Hubicka
@ 2023-11-28 18:35             ` Richard Biener
  0 siblings, 0 replies; 11+ messages in thread
From: Richard Biener @ 2023-11-28 18:35 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: Martin Jambor, GCC Patches



> Am 28.11.2023 um 18:38 schrieb Jan Hubicka <hubicka@ucw.cz>:
> 
> 
>> 
>> 
>> 
>>>> Am 28.11.2023 um 17:59 schrieb Jan Hubicka <hubicka@ucw.cz>:
>>> 
>>> 
>>>> 
>>>>> On Tue, 28 Nov 2023, Martin Jambor wrote:
>>>>> 
>>>>> On Tue, Nov 28 2023, Richard Biener wrote:
>>>>>> On Mon, 27 Nov 2023, Martin Jambor wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> The enhancement to address PR 109849 contained an importsnt thinko,
>>>>>>> and that any reference that is passed to a function and does not
>>>>>>> escape, must also not happen to be aliased by the return value of the
>>>>>>> function.  This has quickly transpired as bugs PR 112711 and PR
>>>>>>> 112721.
>>>>>>> 
>>>>>>> Just as IPA-modref does a good enough job to allow us to rely on the
>>>>>>> escaped set of variables, it sems to be doing well also on updating
>>>>>>> EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
>>>>>>> exactly the situation we need to avoid.  Of course, if a call
>>>>>>> statement ignores any returned value, we also do not need to check the
>>>>>>> flag.
>>>>>> 
>>>>>> But what about EAF_NOT_RETURNED_INDIRECTLY?  Don't you need to
>>>>>> verify the parameter doesn't escape through the return at all?
>>>>>> 
>>>>> 
>>>>> I thought EAF_NOT_RETURNED_INDIRECTLY prohibits things like "return
>>>>> param->next" but those are not a problem (whatever next points to cannot
>>>>> be an SRA candidate and any ADDR_EXPR storing its address there would
>>>>> trigger a disqualification or at least an assert).  But I guess I am
>>>>> wrong, what is actually the exact meaning of the flag?
>>>> 
>>>> I thought it's return (x.ptr = param, &x);
>>>> 
>>>> so the parameter is reachable from the return value.
>>>> 
>>>> But let's Honza answer...
>>> It is same difference as direct/indirect escape. so it check whether
>>> values pointed to by arg can be possibly returned.  Indeed maybe we
>>> should think of better name - the other interpretation did not even
>>> occur to me, but it makes sense.
>> 
>> So does the directly returned flag cover my interpretation of indirect or is there a hole?
> 
> Stores goes through:
> 
>          /* Handle *lhs = name.  */
>          if (assign && gimple_assign_rhs1 (assign) == name)
>            {                             
>              if (dump_file)             
>                fprintf (dump_file, "%*s  ssa name saved to memory\n",
>                         m_depth * 4, "");
>              m_lattice[index].merge (0);
>            }
> 
> So we give up on any flags.  So far modref does not try to track values
> in memory at all. I suppose PTA info does not help me here, since the
> memory values is stored to may not escape but later it may be read and
> copied into something that does escape?

Yeah, we currently don’t track (reliably) what parameters point to and whether that escapes.  Or rather, you can’t query this info.

Richard 

> Honza
>> 
>> Richard
>> 
>>> Honza
>>>> 
>>>> Richard.

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

* Re: [PATCH] tree-sra: Avoid returns of references to SRA candidates
  2023-11-28 16:59       ` Jan Hubicka
  2023-11-28 17:30         ` Richard Biener
@ 2023-11-29 12:04         ` Martin Jambor
  2023-11-29 12:18           ` Jan Hubicka
  1 sibling, 1 reply; 11+ messages in thread
From: Martin Jambor @ 2023-11-29 12:04 UTC (permalink / raw)
  To: Jan Hubicka, Richard Biener; +Cc: GCC Patches

Hi,

On Tue, Nov 28 2023, Jan Hubicka wrote:
>> On Tue, 28 Nov 2023, Martin Jambor wrote:
>> 
>> > On Tue, Nov 28 2023, Richard Biener wrote:
>> > > On Mon, 27 Nov 2023, Martin Jambor wrote:
>> > >
>> > >> Hi,
>> > >> 
>> > >> The enhancement to address PR 109849 contained an importsnt thinko,
>> > >> and that any reference that is passed to a function and does not
>> > >> escape, must also not happen to be aliased by the return value of the
>> > >> function.  This has quickly transpired as bugs PR 112711 and PR
>> > >> 112721.
>> > >> 
>> > >> Just as IPA-modref does a good enough job to allow us to rely on the
>> > >> escaped set of variables, it sems to be doing well also on updating
>> > >> EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
>> > >> exactly the situation we need to avoid.  Of course, if a call
>> > >> statement ignores any returned value, we also do not need to check the
>> > >> flag.
>> > >
>> > > But what about EAF_NOT_RETURNED_INDIRECTLY?  Don't you need to
>> > > verify the parameter doesn't escape through the return at all?
>> > >
>> > 
>> > I thought EAF_NOT_RETURNED_INDIRECTLY prohibits things like "return
>> > param->next" but those are not a problem (whatever next points to cannot
>> > be an SRA candidate and any ADDR_EXPR storing its address there would
>> > trigger a disqualification or at least an assert).  But I guess I am
>> > wrong, what is actually the exact meaning of the flag?
>> 
>> I thought it's return (x.ptr = param, &x);
>> 
>> so the parameter is reachable from the return value.
>> 
>> But let's Honza answer...
> It is same difference as direct/indirect escape. so it check whether
> values pointed to by arg can be possibly returned.  Indeed maybe we
> should think of better name - the other interpretation did not even
> occur to me, but it makes sense.
>

Is my patch OK then?

(Apart from making one of the testcases x86_64-only, as Andrew pointed
out, which I wanted to do but the line somehow got lost.  Making the
testcase more general is fairly low on my contested TODO list and the
testing depends on a specific instruction trapping.)

Thanks,

Martin


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

* Re: [PATCH] tree-sra: Avoid returns of references to SRA candidates
  2023-11-29 12:04         ` Martin Jambor
@ 2023-11-29 12:18           ` Jan Hubicka
  0 siblings, 0 replies; 11+ messages in thread
From: Jan Hubicka @ 2023-11-29 12:18 UTC (permalink / raw)
  To: Martin Jambor; +Cc: Richard Biener, GCC Patches

> Hi,
> 
> On Tue, Nov 28 2023, Jan Hubicka wrote:
> >> On Tue, 28 Nov 2023, Martin Jambor wrote:
> >> 
> >> > On Tue, Nov 28 2023, Richard Biener wrote:
> >> > > On Mon, 27 Nov 2023, Martin Jambor wrote:
> >> > >
> >> > >> Hi,
> >> > >> 
> >> > >> The enhancement to address PR 109849 contained an importsnt thinko,
> >> > >> and that any reference that is passed to a function and does not
> >> > >> escape, must also not happen to be aliased by the return value of the
> >> > >> function.  This has quickly transpired as bugs PR 112711 and PR
> >> > >> 112721.
> >> > >> 
> >> > >> Just as IPA-modref does a good enough job to allow us to rely on the
> >> > >> escaped set of variables, it sems to be doing well also on updating
> >> > >> EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
> >> > >> exactly the situation we need to avoid.  Of course, if a call
> >> > >> statement ignores any returned value, we also do not need to check the
> >> > >> flag.
> >> > >
> >> > > But what about EAF_NOT_RETURNED_INDIRECTLY?  Don't you need to
> >> > > verify the parameter doesn't escape through the return at all?
> >> > >
> >> > 
> >> > I thought EAF_NOT_RETURNED_INDIRECTLY prohibits things like "return
> >> > param->next" but those are not a problem (whatever next points to cannot
> >> > be an SRA candidate and any ADDR_EXPR storing its address there would
> >> > trigger a disqualification or at least an assert).  But I guess I am
> >> > wrong, what is actually the exact meaning of the flag?
> >> 
> >> I thought it's return (x.ptr = param, &x);
> >> 
> >> so the parameter is reachable from the return value.
> >> 
> >> But let's Honza answer...
> > It is same difference as direct/indirect escape. so it check whether
> > values pointed to by arg can be possibly returned.  Indeed maybe we
> > should think of better name - the other interpretation did not even
> > occur to me, but it makes sense.
> >
> 
> Is my patch OK then?

Yes, given that we do not attempt to track any EAF flags for things
ever stored to memory, I believe this is safe

Honza
> 
> (Apart from making one of the testcases x86_64-only, as Andrew pointed
> out, which I wanted to do but the line somehow got lost.  Making the
> testcase more general is fairly low on my contested TODO list and the
> testing depends on a specific instruction trapping.)
> 
> Thanks,
> 
> Martin
> 

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

* Re: [PATCH] tree-sra: Avoid returns of references to SRA candidates
       [not found] <6564dd10.050a0220.70a2b.e9d6SMTPIN_ADDED_BROKEN@mx.google.com>
@ 2023-11-27 18:20 ` Andrew Pinski
  0 siblings, 0 replies; 11+ messages in thread
From: Andrew Pinski @ 2023-11-27 18:20 UTC (permalink / raw)
  To: Martin Jambor; +Cc: GCC Patches, Richard Biener, Jan Hubicka

On Mon, Nov 27, 2023 at 10:16 AM Martin Jambor <mjambor@suse.cz> wrote:
>
> Hi,
>
> The enhancement to address PR 109849 contained an importsnt thinko,
> and that any reference that is passed to a function and does not
> escape, must also not happen to be aliased by the return value of the
> function.  This has quickly transpired as bugs PR 112711 and PR
> 112721.
>
> Just as IPA-modref does a good enough job to allow us to rely on the
> escaped set of variables, it sems to be doing well also on updating
> EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
> exactly the situation we need to avoid.  Of course, if a call
> statement ignores any returned value, we also do not need to check the
> flag.
>
> Hopefully this does not pessimize things too much, I have verified
> that the PR 109849 testcae remains quick and so should also the
> benchmark it is derived from.
>
> The patch has passed bootstrap and testing on x86_64-linux, OK for
> master?
>
> Thanks,
>
> Martin
>
>
> gcc/ChangeLog:
>
> 2023-11-27  Martin Jambor  <mjambor@suse.cz>
>
>         PR tree-optimization/112711
>         PR tree-optimization/112721
>         * tree-sra.cc (build_access_from_call_arg): New parameter
>         CAN_BE_RETURNED, disqualify any candidate passed by reference if it is
>         true.  Adjust leading comment.
>         (scan_function): Pass appropriate value to CAN_BE_RETURNED of
>         build_access_from_call_arg.
>
> gcc/testsuite/ChangeLog:
>
> 2023-11-27  Martin Jambor  <mjambor@suse.cz>
>
>         PR tree-optimization/112711
>         PR tree-optimization/112721
>         * g++.dg/tree-ssa/pr112711.C: New test.
>         * gcc.dg/tree-ssa/pr112721.c: Likewise.
> ---
>  gcc/testsuite/g++.dg/tree-ssa/pr112711.C | 31 ++++++++++++++++++
>  gcc/testsuite/gcc.dg/tree-ssa/pr112721.c | 26 +++++++++++++++
>  gcc/tree-sra.cc                          | 40 ++++++++++++++++++------
>  3 files changed, 88 insertions(+), 9 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr112711.C
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr112721.c
>
> diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr112711.C b/gcc/testsuite/g++.dg/tree-ssa/pr112711.C
> new file mode 100644
> index 00000000000..c04524b04a7
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/tree-ssa/pr112711.C
> @@ -0,0 +1,31 @@
> +/* { dg-do run } */
> +/* { dg-options "-O1" } */
> +
> +typedef          int i32;
> +typedef unsigned int u32;
> +
> +static inline void write_i32(void *memory, i32 value) {
> +  // swap i32 bytes as if it was u32:
> +  u32 u_value = value;
> +  value = __builtin_bswap32(u_value);
> +
> +  // llvm infers '1' alignment from destination type
> +  __builtin_memcpy(__builtin_assume_aligned(memory, 1), &value, sizeof(value));
> +}
> +
> +__attribute__((noipa))
> +static void bug (void) {
> +  #define assert_eq(lhs, rhs) if (lhs != rhs) __builtin_trap()
> +
> +  unsigned char data[5];
> +  write_i32(data, -1362446643);
> +  assert_eq(data[0], 0xAE);
> +  assert_eq(data[1], 0xCA);
> +  write_i32(data + 1, -1362446643);
> +  assert_eq(data[1], 0xAE);
> +}

Only a comment on this testcase, it is only valid for little-endian
and 32bit int targets.
You can modify it to fix it for both though.

Thanks,
Andrew

> +
> +int main() {
> +    bug();
> +    return 0;
> +}
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr112721.c b/gcc/testsuite/gcc.dg/tree-ssa/pr112721.c
> new file mode 100644
> index 00000000000..adf62613266
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr112721.c
> @@ -0,0 +1,26 @@
> +/* { dg-do run } */
> +/* { dg-options "-O1" } */
> +
> +unsigned * volatile gv;
> +
> +struct a {
> +  int b;
> +};
> +int c, e;
> +long d;
> +unsigned * __attribute__((noinline))
> +f(unsigned *g) {
> +  for (; c;)
> +    e = d;
> +  return gv ? gv : g;
> +}
> +int main() {
> +  int *h;
> +  struct a i = {8};
> +  int *j = &i.b;
> +  h = (unsigned *) f(j);
> +  *h = 0;
> +  if (i.b != 0)
> +    __builtin_abort ();
> +  return 0;
> +}
> diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
> index 3a0d52675fe..6a759783990 100644
> --- a/gcc/tree-sra.cc
> +++ b/gcc/tree-sra.cc
> @@ -1268,18 +1268,27 @@ abnormal_edge_after_stmt_p (gimple *stmt, enum out_edge_check *oe_check)
>  }
>
>  /* Scan expression EXPR which is an argument of a call and create access
> -   structures for all accesses to candidates for scalarization.  Return true if
> -   any access has been inserted.  STMT must be the statement from which the
> -   expression is taken.  */
> +   structures for all accesses to candidates for scalarization.  Return true
> +   if any access has been inserted.  STMT must be the statement from which the
> +   expression is taken.  CAN_BE_RETURNED must be true if call argument flags
> +   do not rule out that the argument is directly returned.  OE_CHECK is used
> +   to remember result of a test for abnormal outgoing edges after this
> +   statement.  */
>
>  static bool
> -build_access_from_call_arg (tree expr, gimple *stmt,
> +build_access_from_call_arg (tree expr, gimple *stmt, bool can_be_returned,
>                             enum out_edge_check *oe_check)
>  {
>    if (TREE_CODE (expr) == ADDR_EXPR)
>      {
>        tree base = get_base_address (TREE_OPERAND (expr, 0));
>
> +      if (can_be_returned)
> +       {
> +         disqualify_base_of_expr (base, "Address possibly returned, "
> +                                  "leading to an alis SRA may not know.");
> +         return false;
> +       }
>        if (abnormal_edge_after_stmt_p (stmt, oe_check))
>         {
>           disqualify_base_of_expr (base, "May lead to need to add statements "
> @@ -1508,12 +1517,25 @@ scan_function (void)
>             case GIMPLE_CALL:
>               {
>                 enum out_edge_check oe_check = SRA_OUTGOING_EDGES_UNCHECKED;
> -               for (i = 0; i < gimple_call_num_args (stmt); i++)
> -                 ret |= build_access_from_call_arg (gimple_call_arg (stmt, i),
> -                                                    stmt, &oe_check);
> +               gcall *call = as_a <gcall *> (stmt);
> +               for (i = 0; i < gimple_call_num_args (call); i++)
> +                 {
> +                   bool can_be_returned;
> +                   if (gimple_call_lhs (call))
> +                     {
> +                       int af = gimple_call_arg_flags (call, i);
> +                       can_be_returned = !(af & EAF_NOT_RETURNED_DIRECTLY);
> +                     }
> +                   else
> +                     can_be_returned = false;
> +                   ret |= build_access_from_call_arg (gimple_call_arg (call,
> +                                                                       i),
> +                                                      stmt, can_be_returned,
> +                                                      &oe_check);
> +                 }
>                 if (gimple_call_chain(stmt))
> -                 ret |= build_access_from_call_arg (gimple_call_chain(stmt),
> -                                                    stmt, &oe_check);
> +                 ret |= build_access_from_call_arg (gimple_call_chain(call),
> +                                                    stmt, false,  &oe_check);
>               }
>
>               t = gimple_call_lhs (stmt);
> --
> 2.43.0
>

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

end of thread, other threads:[~2023-11-29 12:18 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-27 18:16 [PATCH] tree-sra: Avoid returns of references to SRA candidates Martin Jambor
2023-11-28  8:05 ` Richard Biener
2023-11-28 16:16   ` Martin Jambor
2023-11-28 16:33     ` Richard Biener
2023-11-28 16:59       ` Jan Hubicka
2023-11-28 17:30         ` Richard Biener
2023-11-28 17:38           ` Jan Hubicka
2023-11-28 18:35             ` Richard Biener
2023-11-29 12:04         ` Martin Jambor
2023-11-29 12:18           ` Jan Hubicka
     [not found] <6564dd10.050a0220.70a2b.e9d6SMTPIN_ADDED_BROKEN@mx.google.com>
2023-11-27 18:20 ` Andrew Pinski

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