This is the mail archive of the
mailing list for the GCC project.
Re: [range-ops] patch 05/04: bonus round!
- From: Jeff Law <law at redhat dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Andrew MacLeod <amacleod at redhat dot com>
- Date: Wed, 3 Jul 2019 17:12:40 -0600
- Subject: Re: [range-ops] patch 05/04: bonus round!
- References: <firstname.lastname@example.org>
On 7/1/19 4:24 AM, Aldy Hernandez wrote:
> This is completely unrelated to range-ops itself, but may yield better
> results in value_range intersections. It's just something I found while
> working on VRP, and have been dragging around on our branch.
> If we know the intersection of two ranges is the empty set, there is no
> need to conservatively add anything to the result.
> Tested on x86-64 Linux with --enable-languages=all.
> commit 4f9aa7bd1066267eee92f622ff29d78534158e20
> Author: Aldy Hernandez <email@example.com>
> Date: Fri Jun 28 11:34:19 2019 +0200
> Do not try to further refine a VR_UNDEFINED result when intersecting
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 01fb97cedb2..b0d78ee6871 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,9 @@
> +2019-07-01 Aldy Hernandez <firstname.lastname@example.org>
> + * tree-vrp.c (intersect_ranges): If we know the intersection is
> + empty, there is no need to conservatively add anything else to
> + the set.
Do we have a test where this improves the code or at least the computed