On 4/18/23 12:32, Jakub Jelinek wrote:
On Tue, Apr 18, 2023 at 11:33:05AM +0200, Jakub Jelinek wrote:
On Tue, Apr 18, 2023 at 11:06:38AM +0200, Aldy Hernandez via Gcc-patches wrote:
This patch provides inchash support for vrange. It is along the lines
of the streaming support I just posted
+namespace inchash
+{
+
+void
+add_vrange (const vrange , inchash::hash ,
+unsigned int)
+{
+ if (v.undefined_p ())
+{
+ hstate.add_int (VR_UNDEFINED);
+ return;
+}
+ // Types are ignored throughout to inhibit two ranges being equal
+ // but having different hash
This patch provides inchash support for vrange. It is along the lines
of the streaming support I just posted and will be used for IPA
hashing of ranges.
Thoughts?
gcc/ChangeLog:
* inchash.cc (hash::add_real_value): New.
* inchash.h (class hash): Add add_real_value.
*
I think it's time for the ranger folk to start owning range streaming
instead of passes (IPA, etc) doing their own thing. I have plans for
overhauling the IPA code later this cycle to support generic ranges,
and I'd like to start cleaning up the streaming and hashing interface.
This patch adds
[Andrew, we talked about this a few months ago. Just making sure we're
on the same page so I can push it. Also, a heads-up for Jakub.]
The == operator for ranges signifies that two ranges contain the same
thing, not that they are ultimately equal. So [2,4] == [2,4], even
though one may be a 2
Sorry, forgot to ask...
Tested on x86-64 Linux.
OK for trunk?
On 4/18/23 07:59, Aldy Hernandez wrote:
In upcoming patches I will contribute code to stream out frange's as
well as vrange's. This patch abstracts out the REAL_VALUE_TYPE
streaming into their own functions, so that they may
In upcoming patches I will contribute code to stream out frange's as
well as vrange's. This patch abstracts out the REAL_VALUE_TYPE
streaming into their own functions, so that they may be used elsewhere.
gcc/ChangeLog:
* data-streamer.cc (bp_pack_real_value): New.
This is for upcoming work in this area.
gcc/ChangeLog:
* value-range.h (Value_Range::Value_Range): New.
(Value_Range::contains_p): New.
---
gcc/value-range.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index
The discriminator in vrange cannot change after construction,
similarly the number of allocated ranges in an irange. It's best to
make them constant to avoid invalid changes.
gcc/ChangeLog:
* value-range.h (class vrange): Make m_discriminator const.
(class irange): Make
On 4/17/23 20:47, Andrew Pinski wrote:
On Mon, Apr 17, 2023 at 11:44 AM Aldy Hernandez via Gcc-patches
wrote:
I'm about to add one more use of the same snippet of code, for a total
of 4 identical calculations in the code base.
This seems safe enough even before the release, since
A warning pass should not be exporting global ranges it finds along
the way, because that will alter the behavior of future passes.
The reason the present behavior was there was because of some long ago
forgotten regression in another pass. This regression is no longer
there, and if there's ever
I'm about to add one more use of the same snippet of code, for a total
of 4 identical calculations in the code base.
This seems safe enough even before the release, since this file hardly
changes and I'm pretty much the only one who's touched it this year.
OK for trunk?
gcc/ChangeLog:
On 4/11/23 10:21, Jakub Jelinek wrote:
Hi!
This patch was what I've tried first before the currently committed
PR109386 fix. Still, I think it is the right thing until we have proper
full set of VREL_* relations for NANs (though it would be really nice
if op1_op2_relation could be passed
OK.
On Mon, Apr 3, 2023, 21:54 Jakub Jelinek wrote:
> Hi!
>
> I've missed one of my recent range-op-float.cc changes (likely the
> r13-6967 one) caused
> FAIL: libphobos.phobos/std/math/algebraic.d execution test
> FAIL: libphobos.phobos_shared/std/math/algebraic.d execution test
> regressions,
On 4/1/23 09:39, Jakub Jelinek wrote:
On Fri, Mar 31, 2023 at 01:28:35PM +0200, Aldy Hernandez wrote:
Ok for trunk if this passes bootstrap/regtest?
LGTM
Unfortunately I ran into 4 tests where we run into the known bug
where if ranger finds out a range of some floating point operation
On 3/31/23 10:16, Jakub Jelinek wrote:
Hi!
The cdce pass among other things replaces calls like sqrt with code
like
if (condition(s))
ret = .IFN_SQRT (x);
else
ret = sqrt (x);
so that in the common case when we know the argument doesn't trigger
any range/domain errors we use
On 3/31/23 12:57, Jakub Jelinek wrote:
On Fri, Mar 31, 2023 at 12:45:10PM +0200, Jakub Jelinek via Gcc-patches wrote:
- there is a missing case (not handled in this patch) where both operands
are known to be zeros, but not singleton zeros
This patch adds those cases.
Ok for
On 3/31/23 12:45, Jakub Jelinek wrote:
On Fri, Mar 31, 2023 at 09:57:54AM +0200, Jakub Jelinek via Gcc-patches wrote:
and so if maybe_isnan, they always return [0, 1]. Now, thinking about it,
this is unnecessary pessimization, for the case where the ... block
returns range_false (type) we
On 3/31/23 09:57, Jakub Jelinek wrote:
Hi!
When looking into PR91645, I've noticed we handle UN{LT,LE,GT,GE,EQ}_EXPR
comparisons incorrectly.
All those are unordered or ..., we correctly return [1, 1] if one or
both operands are known NANs, and correctly ask the non-UN prefixed
op to
On 3/28/23 10:50, Aldy Hernandez wrote:
On 3/28/23 09:54, Jakub Jelinek wrote:
Hi!
On Wed, Mar 22, 2023 at 07:32:44AM +0100, Aldy Hernandez wrote:
* value-range.cc (frange::set): Add nan_state argument.
* value-range.h (class nan_state): New.
(frange::get_nan_state): New
On 3/28/23 09:54, Jakub Jelinek wrote:
Hi!
On Wed, Mar 22, 2023 at 07:32:44AM +0100, Aldy Hernandez wrote:
* value-range.cc (frange::set): Add nan_state argument.
* value-range.h (class nan_state): New.
(frange::get_nan_state): New.
The following patch makes use
On 3/28/23 10:16, Jakub Jelinek wrote:
Hi!
As discussed in the PR, flushing denormals to zero on every frange::set
might be harmful for e.g. x < 0.0 comparisons, because we then on both
sides use ranges that include zero [-Inf, -0.0] on the true side, and
[-0.0, +Inf] NAN on the false side,
On 3/23/23 15:20, Jakub Jelinek wrote:
On Thu, Mar 23, 2023 at 03:05:45PM +0100, Aldy Hernandez wrote:
On 3/23/23 14:32, Jakub Jelinek wrote:
Hi!
I've noticed a comment typo in tree-vrp.cc and decided to quickly
skim aspell -c on the ranger sources (with quick I on everything that
looked
On 3/23/23 14:32, Jakub Jelinek wrote:
Hi!
I've noticed a comment typo in tree-vrp.cc and decided to quickly
skim aspell -c on the ranger sources (with quick I on everything that
looked ok or roughly ok).
But not being a native English speaker, I could get stuff wrong.
The most questionable
On 3/21/23 14:56, Jakub Jelinek wrote:
On Tue, Mar 21, 2023 at 02:49:49PM +0100, Aldy Hernandez wrote:
So, this?
frange::set (tree type,
const REAL_VALUE_TYPE ,
const REAL_VALUE_TYPE ,
const nan_state &,
value_range_kind kind = VR_RANGE)
If so, I'll s
On 3/21/23 14:39, Jakub Jelinek wrote:
On Tue, Mar 21, 2023 at 02:28:31PM +0100, Aldy Hernandez wrote:
/* Temporarily disable -ffinite-math-only, so that frange::set doesn't
reduce the range back to real_min_representable (type) as lower bound
or real_max_representable (type
On 3/10/23 09:53, Richard Biener wrote:
On Fri, 10 Mar 2023, Jakub Jelinek wrote:
Coming back to this...
/* Temporarily disable -ffinite-math-only, so that frange::set doesn't
reduce the range back to real_min_representable (type) as lower bound
or real_max_representable (type)
On Mon, Mar 20, 2023 at 5:14 PM Jakub Jelinek wrote:
>
> On Mon, Mar 13, 2023 at 09:41:47AM +0100, Aldy Hernandez wrote:
> > On 3/13/23 09:06, Jakub Jelinek wrote:
> > > On Mon, Mar 13, 2023 at 08:59:15AM +0100, Aldy Hernandez wrote:
> > > > > Yes, sure - I j
On 3/13/23 09:06, Jakub Jelinek wrote:
On Mon, Mar 13, 2023 at 08:59:15AM +0100, Aldy Hernandez wrote:
Yes, sure - I just noticed that we're forced to use high-level API for
something that's quite low-level and should be internal (a range
"breaking" internal consistency check
On 3/13/23 08:50, Richard Biener wrote:
On Mon, 13 Mar 2023, Aldy Hernandez wrote:
On 3/10/23 11:29, Jakub Jelinek wrote:
On Fri, Mar 10, 2023 at 08:53:37AM +, Richard Biener wrote:
Meh - I wonder if we can avoid all this by making float_widen_lhs_range
friend of frange and simply
On 3/10/23 11:29, Jakub Jelinek wrote:
On Fri, Mar 10, 2023 at 08:53:37AM +, Richard Biener wrote:
Meh - I wonder if we can avoid all this by making float_widen_lhs_range
friend of frange and simply access m_min/m_max directly and use the
copy-CTOR to copy bounds and nan state ... after
As Andrew has been advising on this one, I'd prefer for him to review
it. However, he's on vacation this week. FYI...
Aldy
On Mon, Mar 6, 2023 at 12:22 PM Tamar Christina wrote:
>
> Ping.
>
> And updated the patch to reject cases that we don't expect or can handle
> cleanly for now.
>
>
Similar to my num_pairs comment. If we're fixing missed optimizations,
then yes. Otherwise I'd prefer to remove it soon.
That being said, you are the release manager and if you feel strongly
about this I would defer to you.
Aldy
On 2/28/23 14:47, Richard Biener via Gcc-patches wrote:
I would prefer not touching this as it was intended, and about to be
removed. However, if we have actual regressions or missed optimizations
because of the current behavior I could be convinced otherwise.
Aldy
On 2/28/23 14:47, Richard Biener via Gcc-patches wrote:
irange::num_pairs has odd
On 2/28/23 14:47, Richard Biener via Gcc-patches wrote:
simplify_using_ranges::two_valued_val_range_p has odd code to
verify that an anti-range is two-valued which relies on
num_pairs () returning two for anti-ranges despite there's only
one pair and relying on lower/upper_bound treating that
On 3/1/23 11:12, Richard Biener wrote:
On Wed, 1 Mar 2023, Aldy Hernandez wrote:
On 2/28/23 10:41, Richard Biener wrote:
On Mon, 27 Feb 2023, Aldy Hernandez wrote:
On 2/27/23 14:58, Richard Biener wrote:
After fixing PR107561 the following avoids looking at VR_ANTI_RANGE
ranges
OK.
Thanks.
On Tue, Feb 28, 2023 at 2:48 PM Richard Biener via Gcc-patches
wrote:
>
> The following avoids the need to special-case storage requirement
> and copying for irange_storage_slot by making sure we canonicalize
> such ranges to int_range<2>.
>
> * tree-ssanames.cc
Ughh, you're touching everything I'm nuking next release ;-).
But yes, that's an oversight.
OK.
On Tue, Feb 28, 2023 at 2:48 PM Richard Biener via Gcc-patches
wrote:
>
> when vrange_printer::visit gets a VR_ANTI_RANGE it should print it
> as such, not just print the first element as range.
On 2/28/23 10:41, Richard Biener wrote:
On Mon, 27 Feb 2023, Aldy Hernandez wrote:
On 2/27/23 14:58, Richard Biener wrote:
After fixing PR107561 the following avoids looking at VR_ANTI_RANGE
ranges where it doesn't seem obvious the code does the correct
thing here (lower_bound
On 2/27/23 14:58, Richard Biener wrote:
After fixing PR107561 the following avoids looking at VR_ANTI_RANGE
ranges where it doesn't seem obvious the code does the correct
thing here (lower_bound and upper_bound do not work as expected).
I do realize there's some confusion here, and some of
Woah. Sad to see you leave!
It's always been a pleasure to work with you.
Thanks for all the great work, and good luck on your next endeavors.
Aldy
On Thu, Feb 16, 2023 at 4:55 PM Martin Liška wrote:
>
> Hello GCC community.
>
> After spending last decade (including my diploma thesis even
On 2/16/23 08:55, Richard Biener wrote:
On Wed, Feb 15, 2023 at 6:07 PM Andrew MacLeod via Gcc-patches
wrote:
This patch implements the suggestion that we have an alternative
ssa-cache which does not zero memory, and instead uses a bitmap to track
whether a value is currently set or not.
On 2/16/23 08:57, Richard Biener wrote:
On Wed, Feb 15, 2023 at 11:31 PM Andrew MacLeod via Gcc wrote:
On 2/15/23 14:50, Andrew Pinski wrote:
Hi,
While fixing PR 108354, I came across that
ssa_name_has_boolean_range calls get_range_query with cfun as the
argument but sometimes while
Up to the release managers, but I have no objections.
Aldy
On 2/7/23 17:50, Hans-Peter Nilsson wrote:
(sort-of-ping:) Aldy, I missed CC:ing you on the similar
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611206.html
would you mind having a look?
Tested native x86_64-pc-linux-gnu
LGTM
On 2/3/23 19:59, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, we ICE because lhs is singleton [0, 0]
or [1, 1] but op2 (or in other cases op1) is undefined and op?.*_bound ()
ICEs on those because there are no pairs for UNDEFINED.
The following patch makes us set r to varying or
This patch gracefully handles undefined operand ranges for the floating
point op[12]_range operators. This is very low risk, as we would have
ICEd otherwise.
We don't have a testcase that ICEs for floating point ranges, but it's
only a matter of time. Besides, this dovetails nicely with the
The problem here is we are trying to compare two ranges with different
precisions and the == operator in wide_int is complaining.
Interestingly, the problem is not the nonzero bits, but the fact that
the entire ranges have different precisions. The reason we don't ICE
when comparing the
On 1/19/23 09:41, Jakub Jelinek wrote:
+ range_query *q = get_range_query (cfun);
+ if (q == get_global_range_query ())
+ q = enable_ranger (cfun);
Oh, neat. Clever. I hadn't thought about that.
+ if (!q->range_of_expr (r, rotcnt, check_range_stmt))
+
On 1/17/23 12:33, Jakub Jelinek wrote:
On Tue, Jan 17, 2023 at 12:22:42PM +0100, Aldy Hernandez wrote:
On 1/17/23 12:19, Jakub Jelinek wrote:
On Tue, Jan 17, 2023 at 12:14:14PM +0100, Aldy Hernandez wrote:
A question would be if it would be worth to activate it in this spot lazily
On 1/17/23 12:19, Jakub Jelinek wrote:
On Tue, Jan 17, 2023 at 12:14:14PM +0100, Aldy Hernandez wrote:
A question would be if it would be worth to activate it in this spot lazily
if it isn't active yet (and destruct at the end of the pass).
That's what it was designed for :). If you're
On 1/17/23 12:09, Jakub Jelinek wrote:
On Tue, Jan 17, 2023 at 11:59:53AM +0100, Aldy Hernandez wrote:
On 1/17/23 10:47, Jakub Jelinek wrote:
Aldy/Andrew, is the ranger query ok or should I use something different
when check_range_stmt is non-NULL and I know on which statement to ask
On 1/17/23 10:47, Jakub Jelinek wrote:
Aldy/Andrew, is the ranger query ok or should I use something different
when check_range_stmt is non-NULL and I know on which statement to ask?
+ int_range_max r;
+ if (!get_global_range_query ()->range_of_expr (r, rotcnt,
+
On 1/16/23 08:19, Richard Biener wrote:
On Fri, Jan 13, 2023 at 11:07 PM Andrew MacLeod wrote:
On 1/13/23 16:54, Jakub Jelinek wrote:
On Fri, Jan 13, 2023 at 04:23:20PM -0500, Andrew MacLeod via Gcc-patches wrote:
fold_range() already invokes wi_fold_in_parts to try to get more refined
On 1/15/23 13:18, Jakub Jelinek wrote:
On Sun, Jan 15, 2023 at 11:32:27AM +0100, Aldy Hernandez wrote:
As discussed in the PR, for trapping math, do not fold overflowing
operations into +-INF as doing so could elide a trap.
There is a minor adjustment to known_isinf() where
As discussed in the PR, for trapping math, do not fold overflowing
operations into +-INF as doing so could elide a trap.
There is a minor adjustment to known_isinf() where it was mistakenly
returning true for an [infinity U NAN], whereas it should only return
true when the range is exclusively
As discussed in the PR, for trapping math, do not fold overflowing
operations into +-INF as doing so could elide a trap.
There is a minor adjustment to known_isinf() where it was mistakenly
returning true for an [infinity U NAN], whereas it should only return
true when the range is exclusively
On PTO until Monday but thinking out loud here
Shouldn't we put this code in set_nonzero_bits instead, and leave maybe*
alone? That way any possible setters may benefit from your change?
Also, havent looked (AFK) but does this change work with the global range
getter
OK.
On Wed, Jan 4, 2023, 10:13 Jakub Jelinek wrote:
> Hi!
>
> maybe_set_nonzero_bits calls set_nonzero_bits which asserts that
> var doesn't have pointer type. While we could punt for those
> cases, I think we can handle at least some easy cases.
> Earlier in maybe_set_nonzero_bits we've
LGTM
On Thu, Dec 22, 2022, 22:44 Jakub Jelinek wrote:
> On Thu, Dec 22, 2022 at 08:46:33PM +0100, Aldy Hernandez wrote:
> > I haven't looked at your problem above, but have you tried using
> > int_range_max (or even int_range<2>) instead of value_range above?
> >
&g
On Thu, Dec 22, 2022 at 1:54 PM Jakub Jelinek wrote:
>
> On Thu, Dec 22, 2022 at 01:09:21PM +0100, Aldy Hernandez wrote:
> > INTEGER_CST singleton and
> > > union that into the SSA_NAMEs range and then do set_range_info
> > > with the altered range I guess.
> >
On Thu, Dec 22, 2022, 12:33 Richard Biener wrote:
> On Thu, 22 Dec 2022, Jakub Jelinek wrote:
>
> > Hi!
> >
> > The following place in value_replacement is after proving that
> > x == cst1 ? cst2 : x
> > phi result is only used in a comparison with constant which doesn't
> > care if it compares
On Thu, Dec 22, 2022 at 11:30 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following place in value_replacement is after proving that
> x == cst1 ? cst2 : x
> phi result is only used in a comparison with constant which doesn't
> care if it compares cst1 or cst2 and replaces it with x.
> The testcase
OK, thanks.
Aldy
On 12/7/22 17:05, Jakub Jelinek wrote:
On Wed, Dec 07, 2022 at 04:38:14PM +0100, Aldy Hernandez wrote:
So, perhaps a combination of that, change frange_nextafter to do the above
and change frange_arithmetic for the initial inexact rounding only to
do it by hand using
OK, thanks.
Aldy
On 12/7/22 16:49, Jakub Jelinek wrote:
On Wed, Dec 07, 2022 at 04:26:14PM +0100, Aldy Hernandez wrote:
This chunk...
...is quite similar to this one. Could you abstract this?
It differs in various small details, plus comment content.
Anyway, here it is reworked
On 12/7/22 16:31, Jakub Jelinek wrote:
On Wed, Dec 07, 2022 at 04:21:09PM +0100, Aldy Hernandez wrote:
On 12/7/22 13:10, Jakub Jelinek wrote:
+ switch (code)
+ {
+ case PLUS_EXPR:
+ case MINUS_EXPR:
+ // ibm-ldouble
On 12/7/22 09:29, Jakub Jelinek wrote:
Hi!
The addition of PLUS/MINUS/MULT/RDIV_EXPR frange handlers causes
miscompilation of some of the libm routines, resulting in lots of
glibc test failures. A part of them is purely PR107608 fold-overflow-1.c
etc. issues, say when the code does
On 12/7/22 13:10, Jakub Jelinek wrote:
Hi!
As mentioned in PR107967, ibm-ldouble-format documents that
+- has 1ulp accuracy, * 2ulps and / 3ulps.
So, even if the result is exact, we need to widen the range a little bit.
The following patch does that. I just wonder what it means for reverse
On 12/5/22 12:59, Jakub Jelinek wrote:
On Mon, Dec 05, 2022 at 10:54:41AM +0100, Aldy Hernandez wrote:
Do you mind if I try that incrementally and only if it doesn't make the
code too large/too unreadable?
Sure. And don't feel obligated to implement it either. range-ops is a
never ending
On 12/5/22 10:37, Jakub Jelinek wrote:
On Mon, Dec 05, 2022 at 10:20:53AM +0100, Aldy Hernandez wrote:
For the division, [-0., 0.] / VARYING is computed (IMHO correctly)
as [-0., 0.] +-NAN, because 0 / anything but 0 or NAN is still
0 and 0 / 0 is NAN and ditto 0 / NAN. And then we just
On 11/29/22 10:43, Jakub Jelinek wrote:
Hi!
While for the normal cases it seems to be correct to implement
reverse multiplication (op1_range/op2_range) through division
with float_binary_op_range_finish, reverse division (op1_range)
through multiplication with float_binary_op_range_finish or
OK pending tests?
gcc/ChangeLog:
* tree-vrp.cc (overflow_comparison_p_1): Remove follow_assert_exprs.
(overflow_comparison_p): Remove use_equiv_p.
* tree-vrp.h (overflow_comparison_p): Same.
* vr-values.cc (vrp_evaluate_conditional_warnv_with_ops): Remove
With no equivalences, the use_equiv_p argument in various methods in
simplify_using_ranges is always false. This means we can remove all
calls to compare_names, along with the function.
OK pending tests?
gcc/ChangeLog:
* vr-values.cc (simplify_using_ranges::compare_names): Remove.
This removes all uses of ASSERT_EXPR except the internal one in ipa-*.
OK pending tests?
gcc/ChangeLog:
* doc/gimple.texi: Remove ASSERT_EXPR references.
* fold-const.cc (tree_expr_nonzero_warnv_p): Same.
(fold_binary_loc): Same.
(tree_expr_nonnegative_warnv_p):
On 11/22/22 09:25, Richard Biener wrote:
On Tue, Nov 22, 2022 at 9:24 AM Richard Biener
wrote:
On Mon, Nov 21, 2022 at 5:49 PM Jeff Law wrote:
On 11/21/22 09:35, Aldy Hernandez via Gcc-patches wrote:
I've been playing around with removing the legacy VRP code for the
next release
if no propagation was done.
Just a thought. I don't have strong opinions here.
Aldy
On Fri, Nov 18, 2022, 12:20 Aldy Hernandez wrote:
>
>
> On 11/18/22 11:44, Jakub Jelinek wrote:
> > On Fri, Nov 18, 2022 at 11:37:42AM +0100, Aldy Hernandez wrote:
> >>> Practically str
On 11/18/22 11:44, Jakub Jelinek wrote:
On Fri, Nov 18, 2022 at 11:37:42AM +0100, Aldy Hernandez wrote:
Practically strictly
preserving IEEE exceptions is only important for a very small audience, and
for that even INEXACT will matter (but we still have -ftrapping-math
by default
On 11/18/22 09:39, Richard Biener wrote:
On Thu, Nov 17, 2022 at 8:38 PM Jakub Jelinek via Gcc-patches
wrote:
On Thu, Nov 17, 2022 at 06:59:45PM +, Joseph Myers wrote:
On Thu, 17 Nov 2022, Aldy Hernandez via Gcc-patches wrote:
So... is the optimization wrong? Are we not allowed
The threader is creating a scenario where we are trying to solve:
[NEGATIVES] = abs(x)
While solving this we have an intermediate value of UNDEFINED because
we have no positive numbers. But then we try to union the negative
pair to the final result by querying the bounds. Since neither
removes the sqrt which could trap:
Eliminating unnecessary statements:
Deleting : x_185 = __builtin_sqrtf (-1.0e+0);
Is DCE allowed to remove that sqrtf call?
Thanks.
Aldy
On Thu, Nov 17, 2022 at 5:48 PM Aldy Hernandez wrote:
>
>
>
> On 11/17/22 17:40, Aldy Hernandez wrote:
>
On 11/17/22 17:40, Aldy Hernandez wrote:
To go along with whatever magic we're gonna tack along to the
range-ops sqrt implementation, here is another revision addressing the
VARYING issue you pointed out.
A few things...
Instead of going through trees, I decided to call do_mpfr_arg1
other 3 rounding modes, the former would be used
> without -frounding-math, max over all 4 rounding modes for -frounding-math
> as gcc will compute using mpfr always in round to nearest.
>
> Jakub
From 759bcd4b4b6f70fcec045b24fb6874aaca989549 Mon Sep 17 00:00:00 2001
F
On 11/16/22 17:04, Richard Biener wrote:
On Tue, Nov 15, 2022 at 11:46 AM Aldy Hernandez wrote:
On 11/15/22 08:15, Richard Biener wrote:
On Mon, Nov 14, 2022 at 8:05 PM Aldy Hernandez wrote:
On 11/14/22 10:12, Richard Biener wrote:
On Sat, Nov 12, 2022 at 7:30 PM Aldy Hernandez
I know it's past the end of stage1, but I'm afraid we'll drag this
around forever in the GCC12 branch, and it's an easy readbility fix.
p.s. Or if you prefer:
if (!lb_nan && !ub_nan && !maybe_nan && )
r.clear_nan ();
OK for trunk?
gcc/ChangeLog:
* range-op-float.cc
On Mon, Nov 14, 2022 at 10:12 AM Richard Biener
wrote:
>
> On Sat, Nov 12, 2022 at 7:30 PM Aldy Hernandez wrote:
> >
> > It irks me that a PR named "we should track ranges for floating-point
> > hasn't been closed in this release. This is an attempt to do just
&
On 11/15/22 08:15, Richard Biener wrote:
On Mon, Nov 14, 2022 at 8:05 PM Aldy Hernandez wrote:
On 11/14/22 10:12, Richard Biener wrote:
On Sat, Nov 12, 2022 at 7:30 PM Aldy Hernandez wrote:
It irks me that a PR named "we should track ranges for floating-point
hasn't been c
On 11/14/22 10:12, Richard Biener wrote:
On Sat, Nov 12, 2022 at 7:30 PM Aldy Hernandez wrote:
It irks me that a PR named "we should track ranges for floating-point
hasn't been closed in this release. This is an attempt to do just
that.
As mentioned in the PR, even though we track r
Huh...no argument from me.
Thanks.
Aldy
On Mon, Nov 14, 2022, 15:35 Jakub Jelinek wrote:
> On Mon, Nov 14, 2022 at 07:30:18AM -0700, Jeff Law via Gcc-patches wrote:
> > To Jakub's concern. I thought sqrt was treated like +-/* WRT accuracy
> > requirements by IEEE. ie, for any input there is
On Sun, Nov 13, 2022 at 9:39 PM Jakub Jelinek wrote:
>
> On Sun, Nov 13, 2022 at 09:05:53PM +0100, Aldy Hernandez wrote:
> > It seems SQRT is relatively straightforward, and it's something Jakub
> > wanted for this release.
> >
> > Jakub, what do you think?
> &g
It seems SQRT is relatively straightforward, and it's something Jakub
wanted for this release.
Jakub, what do you think?
p.s. Too tired to think about op1_range.
gcc/ChangeLog:
* gimple-range-op.cc (class cfn_sqrt): New.
(gimple_range_op_handler::maybe_builtin_call): Add cases
I suppose most of the calls to tree_expr_nonnegative_p that apply to
floats in match.pd and tree-ssa-math-opts.cc are guarded by
!HONOR_NANS || tree_expr_nonnegative_p. Still feels kinda delicate...
Aldy
On Sun, Nov 13, 2022 at 4:56 PM Aldy Hernandez wrote:
>
> Based on discussions in th
Based on discussions in the last few weeks, aren't most of the cases in
tree_call_nonnegative_warnv_p() wrong when honoring NANS?
For example:
CASE_CFN_ACOS:
CASE_CFN_ACOS_FN:
CASE_CFN_ACOSH:
CASE_CFN_ACOSH_FN:
...
...
/* Always true. */
return true;
But are we
It irks me that a PR named "we should track ranges for floating-point
hasn't been closed in this release. This is an attempt to do just
that.
As mentioned in the PR, even though we track ranges for floats, it has
been suggested that avoiding recursing through SSA defs in
This patch moves a test that is meant to only work for signed zeros
into range_tests_signed_zeros.
I am not aware of any architectures where this is failing, but it is
annoying to see selftests failing when -fno-signed-zeros is used.
gcc/ChangeLog:
* value-range.cc
On Sat, Nov 12, 2022 at 9:54 AM Jakub Jelinek wrote:
>
> On Fri, Nov 11, 2022 at 08:25:15PM +0100, Aldy Hernandez wrote:
> > Passes tests for all languages. Passes lapack tests.
> >
> > So ready to be installed unless you have any issues. Oh... I should
> &g
Passes tests for all languages. Passes lapack tests.
So ready to be installed unless you have any issues. Oh... I should
write some tests..
Aldy
On Fri, Nov 11, 2022, 19:11 Aldy Hernandez wrote:
> Currently we represent < and > with a closed interval. So < 3.0 is
> repre
Currently we represent < and > with a closed interval. So < 3.0 is
represented as [-INF, +3.0]. This means 3.0 is included in the range,
and though not ideal, is conservatively correct. Jakub has found a
couple cases where properly representing < and > would help
optimizations and tests, and
On 11/11/22 11:01, Jakub Jelinek wrote:
On Fri, Nov 11, 2022 at 09:52:53AM +0100, Jakub Jelinek via Gcc-patches wrote:
Ok, here is the patch rewritten in the foperator_div style, with special
cases handled first and then the ordinary cases without problematic cases.
I guess if/once we have a
On 11/11/22 12:50, Jakub Jelinek wrote:
On Wed, Nov 09, 2022 at 04:43:56PM +0100, Aldy Hernandez wrote:
On Wed, Nov 9, 2022 at 3:58 PM Jakub Jelinek wrote:
On Wed, Nov 09, 2022 at 10:02:46AM +0100, Aldy Hernandez wrote:
We can implement the op[12]_range entries for plus and minus
Remove some specialized fold_range methods that were merely setting
maybe nonzero masks, as these are now subsumed by the generic version.
gcc/ChangeLog:
* range-op.cc (operator_mult::fold_range): Remove.
(operator_div::fold_range): Remove.
(operator_bitwise_and): Remove.
All the work for keeping the maybe nonzero masks up to date is being
done by the bit-CCP code now. Any bitmask inherent in the range that
range-ops may have calculated has no extra information, so the
intersection is unnecessary.
gcc/ChangeLog:
* range-op.cc (update_known_bitmask):
301 - 400 of 2591 matches
Mail list logo
