public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: gcc@gcc.gnu.org, rguenther@suse.de
Subject: Definition of EAF_NOESCAPE and fnspec strings
Date: Sun, 8 Nov 2020 13:47:11 +0100	[thread overview]
Message-ID: <20201108124711.GD65107@kam.mff.cuni.cz> (raw)

Hi,
I implemented simple propagation of EAF arguments for ipa-modref (that is not
hard to do).  My main aim was to detect cases where THIS parameter does not
escape but is used to read/write pointed to memory.  This is meant to
avoid poor code produced when we i.e. offline destructors on cold path.

Unfortunately detecting EAF_NOESCAPE for such parameters breaks.  This is already
visible on memcpy if we let it to be be handled via its fnspec
attribute. If I disable special handling in structalias:

diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index a4832b75436..2b614913b57 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -4389,7 +4389,6 @@ find_func_aliases_for_builtin_call (struct function *fn, gcall *t)
       case BUILT_IN_STRCPY:
       case BUILT_IN_STRNCPY:
       case BUILT_IN_BCOPY:
-      case BUILT_IN_MEMCPY:
       case BUILT_IN_MEMMOVE:
       case BUILT_IN_MEMPCPY:
       case BUILT_IN_STPCPY:

In the following testcase we miss the fact that memcpy may merge i4p PTA
set to i3p.

extern void exit (int);
extern void abort (void);
int size = 8;

int main (void)
{
  int i3 = -1, i4 = 55;
  int *i3p = &i3;
  int *i4p = &i4;

  memcpy(&i3p, &i4p, size);
  if (i3p != i4p)
    abort ();
  exit (0);
}

This seems to be documented for some degree:

	  /* Add *tem = nonlocal, do not add *tem = callused as
	     EAF_NOESCAPE parameters do not escape to other parameters
	     and all other uses appear in NONLOCAL as well.  */

But it also means that some of our FNSPECs are wrong now.  I wonder if we can
split this porperty to two different flags like EAF_NOEASCAPE and
EAF_INDIRECT_NOESCAPE?

Auto-detecting EAF_INDIRECT_NOESCAPE seems bit harder at least assuming
that any read can actually load few bits of pointer possibly written
there beause if simple member functions accesses values pointer by THIS
and return them we lose a track if the returned value is an escape point
I would say.

The difference in constraints are:

--- good/a.c.035t.ealias	2020-11-08 13:34:04.397499515 +0100
+++ a.c.035t.ealias	2020-11-08 13:39:15.483438469 +0100
@@ -106,7 +106,15 @@
 size = NONLOCAL
 size.0_1 = size
 _2 = size.0_1
-i3p = i4p
+callarg(18) = &i3p
+callarg(18) = callarg(18) + UNKNOWN
+CALLUSED(16) = callarg(18)
+CALLCLOBBERED(17) = callarg(18)
+*callarg(18) = NONLOCAL
+callarg(19) = &i4p
+callarg(19) = callarg(19) + UNKNOWN
+CALLUSED(16) = callarg(19)
+ESCAPED = _2
 i3p.1_3 = i3p
 i4p.2_4 = i4p
 ESCAPED = &NULL

...

 Call clobber information
 
-ESCAPED, points-to NULL, points-to vars: { }
+ESCAPED, points-to non-local, points-to NULL, points-to vars: { }
 
 Flow-insensitive points-to information
 
-i3p.1_3, points-to NULL, points-to vars: { D.1947 D.1948 }
+i3p.1_3, points-to non-local, points-to escaped, points-to NULL, points-to vars: { D.1947 }
 i4p.2_4, points-to NULL, points-to vars: { D.1948 }
 
 main ()

Honza

             reply	other threads:[~2020-11-08 12:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-08 12:47 Jan Hubicka [this message]
2020-11-09  7:31 ` Richard Biener
2020-11-09 10:29   ` Jan Hubicka
2020-11-09 12:38     ` Richard Biener
2020-11-09 13:16       ` Detect EAF flags in ipa-modref Jan Hubicka
2020-11-09 23:14         ` Jan Hubicka
2020-11-10  9:17           ` Jan Hubicka
2020-11-10 10:25           ` Jan Hubicka
2020-11-10 10:55             ` Jan Hubicka
2020-11-10 11:04           ` Richard Biener
2020-11-10 12:54             ` Jan Hubicka
2020-11-10 14:31               ` Jan Hubicka
2020-11-13  8:06                 ` Richard Biener
2020-11-15 13:25                   ` H.J. Lu
2020-11-15 14:13                     ` Jan Hubicka
2020-11-15 10:41                 ` Andreas Schwab
2020-11-15 11:12                   ` Jan Hubicka
2020-11-15 11:25                     ` Rainer Orth
2020-11-15 12:33                       ` Jan Hubicka
2020-11-15 12:43                         ` Rainer Orth
2020-11-15 13:03                           ` Jan Hubicka
2020-11-15 16:03                             ` Rainer Orth
2020-11-15 16:15                             ` Andreas Schwab
2020-11-15 18:07                               ` Jan Hubicka
2020-11-16  7:48                                 ` Richard Biener
2020-11-16  9:26                                 ` Andreas Schwab
2020-11-16 10:59                                   ` Jan Hubicka
2020-11-16 12:36                                     ` Richard Biener
2020-11-16 12:44                                       ` Jan Hubicka
2020-11-16 19:33                                         ` Martin Liška
2020-11-16 19:46                                           ` Jan Hubicka
2020-11-11 10:09               ` 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=20201108124711.GD65107@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc@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).