On Thu, 27 Apr 2017, Richard Biener wrote:
> On April 27, 2017 4:06:48 PM GMT+02:00, "Bin.Cheng"
> wrote:
> >On Thu, Apr 27, 2017 at 2:49 PM, Richard Biener
> >wrote:
> >>
> >> The following makes intersecting [-INF, +10] and [a + -1, +INF]
> >> to [10, a + -1] possible with the chance that for
On April 27, 2017 4:06:48 PM GMT+02:00, "Bin.Cheng"
wrote:
>On Thu, Apr 27, 2017 at 2:49 PM, Richard Biener
>wrote:
>>
>> The following makes intersecting [-INF, +10] and [a + -1, +INF]
>> to [10, a + -1] possible with the chance that for a <= 10 the
>> resulting range will be empty (but not tri
On Thu, Apr 27, 2017 at 2:49 PM, Richard Biener wrote:
>
> The following makes intersecting [-INF, +10] and [a + -1, +INF]
> to [10, a + -1] possible with the chance that for a <= 10 the
> resulting range will be empty (but not trivially visible as so).
Hi,
I noticed operand_less_p is quite simple
The following makes intersecting [-INF, +10] and [a + -1, +INF]
to [10, a + -1] possible with the chance that for a <= 10 the
resulting range will be empty (but not trivially visible as so).
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
I'll add a testcase later.
Richard.
2017-04-27
On March 10, 2017 6:56:40 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>The following patch teaches VRP that IMAGPART_EXPR of
>ATOMIC_COMPARE_EXCHANGE ifn call is always 0 or 1. We cast it to bool
>afterwards, but this hint allows VRP to:
>--- pr79981.c.103t.vrp1_ 2017-03-10 15:39:29.0
Hi!
The following patch teaches VRP that IMAGPART_EXPR of
ATOMIC_COMPARE_EXCHANGE ifn call is always 0 or 1. We cast it to bool
afterwards, but this hint allows VRP to:
--- pr79981.c.103t.vrp1_2017-03-10 15:39:29.0 +0100
+++ pr79981.c.103t.vrp1 2017-03-10 15:48:15.051608067 +0100
I noticed we intersect ~[a_1, a_1] and [2, 2] to ~[a_1, a_1]. While
we don't generally want to choose an integral range a singleton integral
range is always preferable.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-09-30 Richard Biener
* tree-vrp.c (in
We currently fail to assert that this != NULL at the caller side
because we're chickening out on stmts that could throw. While
it would be trivial to fix the testcase with only bailing out
for internally throwing stmts the following properly handles those
as well by making sure to infer stuff onl
The patch for PR72851 exposes an issue with PHI handling in VRP that
is easily fixed if we allow iterating again if we are sure this is
the last iteration with the set of fixed executable edges. It also
makes sure we always print the lattice change, even if it is to VARYING.
Bootstrap / regtest
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2016-07-21 Richard Biener
PR tree-optimization/71947
* tree-vrp.c (extract_range_from_assert): Singleton symbolic
ranges have useful limit_vr information.
* gcc.dg/tree-ssa/vrp102
This improves VRP for cases of
x = (T) y;
if (y !=/== CST)
{
... use of X
to insert asserts for X similar to how we handle x = y +- CST.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-06-30 Richard Biener
* tree-vrp.c (register_edge_asser
This improves VRP of induction variables tested against zero
and handles overflow detection in a less awkward way. It does
that by, instead of dropping to +-INF on iteration, drop to
+INF-1 or -INF+1 and letting the next iteration figure that out.
Bootstrapped and tested on x86_64-unknown-linux-
On Thu, 7 Nov 2013, Jakub Jelinek wrote:
> On Thu, Nov 07, 2013 at 10:32:10AM +0100, Richard Biener wrote:
> > I'm looking for adjusting of live compute - either by adjusting the
> > algorithm or by special casing the latches. Like for example
> > with the following (untested, needs cleanup - the
On Thu, Nov 07, 2013 at 10:32:10AM +0100, Richard Biener wrote:
> I'm looking for adjusting of live compute - either by adjusting the
> algorithm or by special casing the latches. Like for example
> with the following (untested, needs cleanup - the PHI processing
> can be factored out from find_as
On Thu, 7 Nov 2013, Jakub Jelinek wrote:
> On Thu, Nov 07, 2013 at 09:48:46AM +0100, Richard Biener wrote:
> > > --- gcc/tree-vrp.c.jj 2013-11-06 08:48:01.0 +0100
> > > +++ gcc/tree-vrp.c2013-11-06 09:32:19.205104029 +0100
> > > @@ -92,6 +92,42 @@ static sbitmap *live;
> > > s
On Thu, Nov 07, 2013 at 09:48:46AM +0100, Richard Biener wrote:
> > --- gcc/tree-vrp.c.jj 2013-11-06 08:48:01.0 +0100
> > +++ gcc/tree-vrp.c 2013-11-06 09:32:19.205104029 +0100
> > @@ -92,6 +92,42 @@ static sbitmap *live;
> > static bool
> > live_on_edge (edge e, tree name)
> > {
On Wed, 6 Nov 2013, Jakub Jelinek wrote:
> On Tue, Nov 05, 2013 at 02:00:16PM -0800, Cong Hou wrote:
> > > I'm also curious -- did this code show up in a particular benchmark, if
> > > so,
> > > which one?
> >
> > I didn't find this problem from any benchmark, but from another
> > concern about
On 11/06/13 10:13, Jakub Jelinek wrote:
On Tue, Nov 05, 2013 at 02:00:16PM -0800, Cong Hou wrote:
I'm also curious -- did this code show up in a particular benchmark, if so,
which one?
I didn't find this problem from any benchmark, but from another
concern about loop upper bound estimation. Lo
On Tue, Nov 05, 2013 at 02:00:16PM -0800, Cong Hou wrote:
> > I'm also curious -- did this code show up in a particular benchmark, if so,
> > which one?
>
> I didn't find this problem from any benchmark, but from another
> concern about loop upper bound estimation. Look at the following code:
>
>
On Tue, Apr 9, 2013 at 3:54 AM, Jeff Law wrote:
>
> This incorporates the concrete suggestions from Steven & Richi -- it doesn't
> do any refactoring of the VRP code. There's still stuff I'm looking at that
> might directly lead to some refactoring. In the mean time I'm submitting
> the obvious
On 04/08/2013 07:54 PM, Jeff Law wrote:
This incorporates the concrete suggestions from Steven & Richi -- it
doesn't do any refactoring of the VRP code. There's still stuff I'm
looking at that might directly lead to some refactoring. In the mean
time I'm submitting the obvious small improvemen
This incorporates the concrete suggestions from Steven & Richi -- it
doesn't do any refactoring of the VRP code. There's still stuff I'm
looking at that might directly lead to some refactoring. In the mean
time I'm submitting the obvious small improvements.
Bootstrapped and regression test
On Mon, Apr 8, 2013 at 3:27 PM, Jeff Law wrote:
> On 04/08/2013 03:45 AM, Richard Biener wrote:
>
>>> @@ -8584,6 +8584,43 @@ simplify_cond_using_ranges (gimple stmt)
>>> }
>>> }
>>>
>>> + /* If we have a comparison of a SSA_NAME boolean against
>>> + a constant (which obviously
On 04/08/2013 03:45 AM, Richard Biener wrote:
@@ -8584,6 +8584,43 @@ simplify_cond_using_ranges (gimple stmt)
}
}
+ /* If we have a comparison of a SSA_NAME boolean against
+ a constant (which obviously must be [0..1]). See if the
+ SSA_NAME was set by a type conversion
On Sat, Apr 6, 2013 at 2:48 PM, Jeff Law wrote:
>
> Given something like this:
>
> :
> _23 = changed_17 ^ 1;
> _12 = (_Bool) _23;
> if (_12 != 0)
> goto ;
> else
> goto ;
>
> Assume _23 and changed_17 have integer types wider than a boolean, but VRP
> has determined they have a ra
On 04/06/2013 07:08 AM, Steven Bosscher wrote:
+ if (!SSA_NAME_OCCURS_IN_ABNORMAL_PHI (innerop))
+ {
+ value_range_t *vr = get_value_range (innerop);
+
I don't think the SSA_NAME_OCCURS_IN_ABNORMAL_PHI test is necessary,
get_value_range() will simply return a !VR_RANGE.
It'
On Sat, Apr 6, 2013 at 2:48 PM, Jeff Law wrote:
>
> Given something like this:
...and the other one from earlier today. Nice finds! :-)
> + /* If we have a comparison of a SSA_NAME boolean against
> + a constant (which obviously must be [0..1]). See if the
"...be [0..1]), see if ..."
> +
Given something like this:
:
_23 = changed_17 ^ 1;
_12 = (_Bool) _23;
if (_12 != 0)
goto ;
else
goto ;
Assume _23 and changed_17 have integer types wider than a boolean, but
VRP has determined they have a range [0..1].
We should be turning that into:
:
_23 = changed_17 ^
28 matches
Mail list logo
