From: Aldy Hernandez <aldyh@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Andrew MacLeod <amacleod@redhat.com>,
gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Avoid generating useless range info
Date: Wed, 14 Jun 2017 16:41:00 -0000 [thread overview]
Message-ID: <85de74ae-9680-1461-a289-42c915b5285a@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
Hi!
As discovered in my range class work, we seem to generate a significant
amount of useless range info out of VRP.
Is there any reason why we can't avoid generating any range info that
spans the entire domain, and yet contains nothing in the non-zero bitmask?
The attached patch passes bootstrap, and the one regression it causes is
because now the -Walloca-larger-than= pass is better able to determine
that there is no range information at all, and the testcase is
unbounded. So...win, win.
OK for trunk?
Aldy
[-- Attachment #2: curr --]
[-- Type: text/plain, Size: 1751 bytes --]
gcc/
* tree-vrp.c (vrp_finalize): Do not expose any useless range
information.
gcc/testsuite/
* gcc.dg/Walloca-14.c: Adapt test to recognize new complaint of
unbounded use.
diff --git a/gcc/testsuite/gcc.dg/Walloca-14.c b/gcc/testsuite/gcc.dg/Walloca-14.c
index 723dbe5..f3e3f57 100644
--- a/gcc/testsuite/gcc.dg/Walloca-14.c
+++ b/gcc/testsuite/gcc.dg/Walloca-14.c
@@ -9,5 +9,6 @@ g (int *p)
extern void f (void *);
void *q = __builtin_alloca (p); /* { dg-warning "passing argument 1" } */
+ /* { dg-warning "unbounded use of 'alloca'" "unbounded" { target *-*-* } 11 } */
f (q);
}
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 716a7c2..8442b1f 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -10708,8 +10708,24 @@ vrp_finalize (bool warn_array_bounds_p)
vr_value[i]->max) == 1)))
set_ptr_nonnull (name);
else if (!POINTER_TYPE_P (TREE_TYPE (name)))
- set_range_info (name, vr_value[i]->type, vr_value[i]->min,
- vr_value[i]->max);
+ {
+ range_info_def *ri = SSA_NAME_RANGE_INFO (name);
+ tree type = TREE_TYPE (name);
+ unsigned precision = TYPE_PRECISION (type);
+ /* If the range covers the entire domain and there is
+ nothing in the non-zero bits mask, there is no sense in
+ storing anything. */
+ if (vr_value[i]->min == TYPE_MIN_VALUE (type)
+ && vr_value[i]->max == TYPE_MAX_VALUE (type)
+ && vr_value[i]->type == VR_RANGE
+ && (!ri
+ || ri->get_nonzero_bits () == wi::shwi (-1, precision)))
+ SSA_NAME_RANGE_INFO (name) = NULL;
+ else
+ set_range_info (name, vr_value[i]->type, vr_value[i]->min,
+ vr_value[i]->max);
+ }
+}
}
substitute_and_fold (op_with_constant_singleton_value_range, vrp_fold_stmt);
next reply other threads:[~2017-06-14 16:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-14 16:41 Aldy Hernandez [this message]
2017-06-16 8:00 ` Richard Biener
2017-06-23 9:02 ` Aldy Hernandez
[not found] ` <CAGm3qMXOYa3Km6FGiji0j2txeZJfyiLTR7V6EDMTDEDQo0RWBA@mail.gmail.com>
2017-06-23 10:24 ` Richard Biener
2017-06-23 10:32 ` Jakub Jelinek
2017-06-23 11:01 ` Richard Biener
2017-06-27 10:26 ` Aldy Hernandez
2017-06-27 10:38 ` Jakub Jelinek
2017-06-28 7:56 ` Aldy Hernandez
2017-06-29 9:53 ` Richard Biener
2017-08-02 13:29 ` [testsuite, committed] Use relative line number in gcc.dg/Walloca-14.c Tom de Vries
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=85de74ae-9680-1461-a289-42c915b5285a@redhat.com \
--to=aldyh@redhat.com \
--cc=amacleod@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
/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).