This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix extract_range_from_cond (PRtree-optimization/19060)
- From: Jeffrey A Law <law at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Diego Novillo <dnovillo at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 05 Jan 2005 11:49:45 -0700
- Subject: Re: [PATCH] Fix extract_range_from_cond (PRtree-optimization/19060)
- Organization: Red Hat, Inc
- References: <20050104174650.GA10340@devserv.devel.redhat.com>
- Reply-to: law at redhat dot com
On Tue, 2005-01-04 at 12:46 -0500, Jakub Jelinek wrote:
> If extract_range_from_cond sees x < min or x > max condition, it will
> create a range min .. max_with_TREE_OVERFLOW (or min_with_TREE_OVERFLOW .. max).
> The following patch fixes it.
> Ok if regression testing passes?
No. I think this can introduce regressions because of...
> BTW: simplify_cond_and_lookup_avail_expr completely ignores the inverted
> value of the second extract_range_from_cond. I haven't so far managed to
> write a testcase that would prove that it is wrong, but I certainly don't
> understand how that can be right.
It works right now because we never record any ranges which need to be
inverted. Thus we "know" that the inverted flag will never be set by
the second call to extract_range_cond (for the same reason we can ignore
the return value from the second call to extract_range_cond). It
wouldn't hurt to put in a couple asserts.
ie, the first extract_range_cond call can have an arbitrary COND,
including NE (which requires the inverted flag). The second call
to extract_range_cond extracts ranges from stored conditions. We
only store conditions which do not require the inverted flag
Your change as it stands means we could need the inverted bit on
stored ranges and thus I believe could introduce regressions.
We're probably best off doing two things:
1. Fixing fold so that it handles x < TYPE_MIN_VALUE (TREE_TYPE (x))
(I thought it did that already, so we need to figure out why it
2. For GT TYPE_MAX_VALUE, don't record anything. Simliarly for
3. Document this code better (still in my TODO queue).