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