> Yeah, that sounds good to me.
Here's what I have at last commited after testing on x86-64/Linux.
2014-09-29 Eric Botcazou
* tree-vrp.c (get_single_symbol): New function.
(build_symbolic_expr): Likewise.
(symbolic_range_based_on_p): New predicate.
(extract_ra
On Fri, Jun 20, 2014 at 11:33 AM, Eric Botcazou wrote:
> [I'm at last back to this...]
>
>> > With [1, -x + INF] as the resulting range? But it can be bogus if x is
>> > itself equal to +INF (unlike the input range [x + 1, +INF] which is
>> > always correct)
>>
>> Hmm, indeed.
>>
>> > so this doe
[I'm at last back to this...]
> > With [1, -x + INF] as the resulting range? But it can be bogus if x is
> > itself equal to +INF (unlike the input range [x + 1, +INF] which is
> > always correct)
>
> Hmm, indeed.
>
> > so this doesn't look valid to me. I don't see how we can get away
> > witho
On Fri, Jun 6, 2014 at 12:52 PM, Eric Botcazou wrote:
>> So when computing a range for z in
>>
>> z = y - x;
>>
>> with x = [-INF, y - 1] and y = [x + 1, +INF] (deduced from !(x >= y)) we
>> fail to do sth sensible with [y, y] - [-INF, y - 1] or [x + 1, +INF] - [x,
>> x] but we do sth with [x + 1
> So when computing a range for z in
>
> z = y - x;
>
> with x = [-INF, y - 1] and y = [x + 1, +INF] (deduced from !(x >= y)) we
> fail to do sth sensible with [y, y] - [-INF, y - 1] or [x + 1, +INF] - [x,
> x] but we do sth with [x + 1, +INF] - [-INF, x]? That seems odd to me.
>
> With the pa
On Tue, Jun 3, 2014 at 10:11 AM, Eric Botcazou wrote:
>> Looks mostly ok. Any reason why you are not re-creating
>> MINUS_EXPR in build_symbolic_expr? That is, build
>> inv - t (for non-pointers, of course)?
>
> It's more uniform and compare_values expects an INTEGER_CST on the RHS,
> although t
> Looks mostly ok. Any reason why you are not re-creating
> MINUS_EXPR in build_symbolic_expr? That is, build
> inv - t (for non-pointers, of course)?
It's more uniform and compare_values expects an INTEGER_CST on the RHS,
although the patch was lacking a small tweak to the function:
@@ -1205,
On Mon, Jun 2, 2014 at 12:36 PM, Richard Biener
wrote:
> On Fri, May 30, 2014 at 10:48 AM, Eric Botcazou wrote:
>>> I'd say we still handle "basic" symbolic range ops in
>>> extract_range_from_binary_1
>>> but in extract_range_from_binary_expr for a symbolic op0 we try to simplify
>>> it with bot
On Fri, May 30, 2014 at 10:48 AM, Eric Botcazou wrote:
>> I'd say we still handle "basic" symbolic range ops in
>> extract_range_from_binary_1
>> but in extract_range_from_binary_expr for a symbolic op0 we try to simplify
>> it with both [op1, op1] and with the value-range of op1 until we get a
>>
> I'd say we still handle "basic" symbolic range ops in
> extract_range_from_binary_1
> but in extract_range_from_binary_expr for a symbolic op0 we try to simplify
> it with both [op1, op1] and with the value-range of op1 until we get a
> non-varying range as result. Not sure if it's worth restric
On May 27, 2014 6:12:58 PM CEST, Eric Botcazou wrote:
>> I'm asking to merge them (move them to fold_comparison).
>
>Done (in the end the patch removes more lines than it adds :-).
That's what I like!
>Tested on x86_64-suse-linux with no regressions.
OK.
Thanks,
Richard.
>
>2014-05-27 Eric B
> I'm asking to merge them (move them to fold_comparison).
Done (in the end the patch removes more lines than it adds :-).
Tested on x86_64-suse-linux with no regressions.
2014-05-27 Eric Botcazou
* fold-const.c (fold_comparison): Clean up and extend X +- C1 CMP C2
to X CMP
On Tue, May 27, 2014 at 11:59 AM, Eric Botcazou wrote:
>> I'm asking to merge them (move them to fold_comparison).
>
> OK, I'll repost a first patch doing only the fold-const.c massaging.
>
>> Yeah, it would be nice to see some support. The most interesting cases
>> will be symbolic-singleton +-
> I'm asking to merge them (move them to fold_comparison).
OK, I'll repost a first patch doing only the fold-const.c massaging.
> Yeah, it would be nice to see some support. The most interesting cases
> will be symbolic-singleton +- CST where the offset shrinks a constant offset
> in a symbolic
On Tue, May 27, 2014 at 11:25 AM, Eric Botcazou wrote:
>> + tree new_const
>> + = fold_build2_loc (loc, reverse_op, TREE_TYPE (arg1), const2,
>> const1);
>>
>>/* If the constant operation overflowed this can be
>> simplified as a comparison against INT_MAX/INT_MIN. */
> + tree new_const
> + = fold_build2_loc (loc, reverse_op, TREE_TYPE (arg1), const2,
> const1);
>
>/* If the constant operation overflowed this can be
> simplified as a comparison against INT_MAX/INT_MIN. */
> - if (TREE_CODE (lhs) == INTEGER_CST
> - && TR
On Mon, May 26, 2014 at 12:22 PM, Eric Botcazou wrote:
> Hi,
>
> the motivation of this work is to get rid of the range check on Z in:
>
> function F (X : Integer; Y : Integer ) return Positive is
>Z : Integer;
> begin
>if X >= Y then
> return 1;
>end if;
>Z := Y - X;
>re
Hi,
the motivation of this work is to get rid of the range check on Z in:
function F (X : Integer; Y : Integer ) return Positive is
Z : Integer;
begin
if X >= Y then
return 1;
end if;
Z := Y - X;
return Z;
end;
An equivalent C testcase is:
extern void abort (void);
int foo
18 matches
Mail list logo
