We haven't been using this for a looong time. It never even gets defined.
Removed and committed to branch.
Aldy
commit a8076b015cad17538e369c153f8c7cf888433840
Author: Aldy Hernandez
Date: Tue Jan 27 11:24:53 2015 -0800
* dwarf2out.c (file_table_last_lookup): Remove unset var
On 01/30/2015 11:01 AM, Aldy Hernandez wrote:
We haven't been using this for a looong time. It never even gets defined.
Removed and committed to branch.
Aldy
Ughh, I'm having git rebase issues. I was missing part of the patch.
Here's the rest.
Committed to branch.
Aldy
d
On 01/28/2015 10:51 AM, Jason Merrill wrote:
On 01/28/2015 01:29 PM, Aldy Hernandez wrote:
+ /* It is rather unfortunate that Cilk creates trees this late +
(during gimplification). However, until this gets fixed, +
specially handle emitting DWARF for this new function and +
immediately clean
On 01/30/2015 02:04 PM, Jason Merrill wrote:
On 01/30/2015 03:36 PM, Aldy Hernandez wrote:
/* It is possible to have both DECL_ABSTRACT_P and DECLARATION be
true if we
started to generate the abstract instance of an inline, decided
to output
its containing class, and proceeded to
On 01/31/2015 10:22 PM, Jason Merrill wrote:
On 01/30/2015 06:49 PM, Aldy Hernandez wrote:
+ FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
+if (DECL_ABSTRACT_ORIGIN (node->decl))
If we do this for all functions, not just those with
DECL_ABSTRACT_ORIGIN set...
+ /* FIXME: What does this
Howdy!
Such simple requests. Such a pain in the ass to implement :).
I know Richard will be tickled pink with the attached patch-- well, at
least with the general approach, as generically handling DECLs has been
his desire all along. I hope I got it right, as it was a royal pain to
get the
And what about namespace-scope variables? Maybe instead of checking for
TRANSLATION_UNIT_DECL context this should check non-function context.
Done.
+ /* This is the second iteration through the global symbols. Here we
+ pick up function statics that have been discovered by the call
+&& DECL_CONTEXT (snode->decl)
+&& TREE_CODE (DECL_CONTEXT (snode->decl)) != FUNCTION_DECL)
I think this should be !decl_function_context (snode->decl), in case
there's a class or BLOCK between the symbol and its enclosing function.
Done, also for the iteration through reachable func
Richard Biener writes:
> Looks good to me. I wonder if this will also help Aldyh...
Hmmm, I ran into something very similar. We solved it on the
debug-early branch by avoiding recursively setting DECL_ABSTRACT_P if
the parent was *not* DECL_ABSTRACT_P. Like this:
@@ -18274,7 +18312,8 @@ dwarf
OK with that change.
Sweet! Thanks for everything.
Though he's been silent, I bet Richi is secretly dancing :-).
On 02/10/2015 02:52 AM, Richard Biener wrote:
On Fri, Feb 6, 2015 at 5:42 PM, Aldy Hernandez wrote:
Of course I wonder why you need to separate handling of functions and variables
The variables need to be handled earlier, else the call to
analyze_functions() will remove some optimized
On 02/12/2015 11:27 AM, Jason Merrill wrote:
On 02/12/2015 01:04 PM, Aldy Hernandez wrote:
On 02/10/2015 02:52 AM, Richard Biener wrote:
On Fri, Feb 6, 2015 at 5:42 PM, Aldy Hernandez wrote:
Of course I wonder why you need to separate handling of functions and
variables
The variables
possibly permanently, unless we really care about it).
OK for mainline pending tests?
Aldy
commit c0814b101417a5639fe70b41526b4e2d7a56ee52
Author: Aldy Hernandez
Date: Thu Feb 19 07:35:59 2015 -0800
PR debug/46102
* c-pch.c (c_common_read_pch): Disable -feliminate-dwarf2
commit 119b6f5c628831706ac8fa26a906d80cf996bbe3
Author: Aldy Hernandez
Date: Wed Feb 18 13:31:41 2015 -0800
PR debug/58123
* gimplify.c (gimplify_expr): Prefer location of TRY_FINALLY_EXPR
over input_location.
testsuite/
* g++.dg/debug/dwarf2/deallocator.C: Adjust for c
On 02/19/2015 08:50 AM, Jakub Jelinek wrote:
On Thu, Feb 19, 2015 at 08:45:08AM -0800, Aldy Hernandez wrote:
[And this time, actually CCing the list :)].
Gentlemen!
Reading in the compiler state for pch (gt_pch_restore) obliterates the
DIE table, and consequently the DW_TAG_GNU_[BE]INCL* DIEs
line.
Phew... that's basically it.
Kind words greatly appreciated. Basically I'm looking for feedback and
positive reinforcement that this is all eventually useful :).
Aldy
p.s. Committed to branch.
commit 850d7f8460c1be9865ba4c45c6c56c346b4199e0
Author: Aldy Herna
On 10/28/14 07:40, Michael Matz wrote:
Hi,
On Mon, 27 Oct 2014, Aldy Hernandez wrote:
Here I use a new tree bit (BLOCK_DIE) to store the DIE<->block
relationship. This will have to be adapted and streamed for LTO.
You might consider using an on-the-side tree->hash map. Saves me
PING*2
On 5/15/19 12:36 PM, Aldy Hernandez wrote:
Sorry, I meant to PING this one.
Aldy
On Wed, May 8, 2019 at 5:08 PM Aldy Hernandez wrote:
On 5/8/19 2:30 AM, Richard Biener wrote:
On Tue, May 7, 2019 at 11:55 PM Jeff Law wrote:
On 5/7/19 3:45 AM, Richard Biener wrote:
On Tue, May 7
On 5/21/19 5:53 AM, Richard Biener wrote:
On Tue, May 21, 2019 at 4:13 AM Martin Sebor wrote:
On 5/20/19 3:16 AM, Richard Biener wrote:
On Mon, May 20, 2019 at 10:16 AM Marc Glisse wrote:
On Mon, 20 May 2019, Richard Biener wrote:
On Sun, May 19, 2019 at 6:16 PM Marc Glisse wrote:
I don't know if there's the -Walloca pass would benefit from merging
with any of the others or vice versa, but superficially it seems like
it might be worth thinking about integrating the -Walloc-larger-than
warnings into the -Walloca pass, if only to keep similar functionality
in the same plac
As per the API, and the original documentation to value_range,
VR_UNDEFINED and VR_VARYING should never have equivalences. However,
equiv_add is tacking on equivalences blindly, and there are various
regressions that happen if I fix this oversight.
void
value_range::equiv_add (const_tree var,
On 5/29/19 9:24 AM, Richard Biener wrote:
On Wed, May 29, 2019 at 2:18 PM Aldy Hernandez wrote:
As per the API, and the original documentation to value_range,
VR_UNDEFINED and VR_VARYING should never have equivalences. However,
equiv_add is tacking on equivalences blindly, and there are
On 5/29/19 12:12 PM, Jeff Law wrote:
On 5/29/19 9:58 AM, Aldy Hernandez wrote:
On 5/29/19 9:24 AM, Richard Biener wrote:
On Wed, May 29, 2019 at 2:18 PM Aldy Hernandez wrote:
As per the API, and the original documentation to value_range,
VR_UNDEFINED and VR_VARYING should never have
with these changes, as well as the pending intersect patch,
we've cleaned up the remaining value_range uses where we actually wanted
to use value_range_base. Or at least the remaining "value_range tem"
business.
OK?
Aldy
commit 55294d340a0727dbe985ee4bf3c1969a19bcbe6d
Author: Aldy
I've never been too happy with the too large due to cast warnings. For that
matter, it seems like a lot of the unbounded alloca warning variants were
artifacts of the way we couldn't get precise ranges after vrp asserts had
disappeared and we were trying to guess at what the actual range in the
ori
Thanks. I will adjust accordingly.
On Fri, May 31, 2019, 02:26 Martin Sebor wrote:
> On 5/30/19 12:58 AM, Aldy Hernandez wrote:
> > Hi.
> >
> > We have zero_p in the API, but we don't have non_zero_p. Instead we use
> > a non-API function range_is_nonnull. I&#x
Sure. No problem. Thanks for looking at this.
Aldy
On Fri, May 31, 2019, 17:48 Marc Glisse wrote:
> On Fri, 31 May 2019, Aldy Hernandez wrote:
>
> > I've never been too happy with the too large due to cast warnings. For
> that
> > matter, it seems like a lot of th
On 5/31/19 5:00 AM, Richard Biener wrote:
On Fri, May 31, 2019 at 2:27 AM Jeff Law wrote:
On 5/29/19 10:20 AM, Aldy Hernandez wrote:
On 5/29/19 12:12 PM, Jeff Law wrote:
On 5/29/19 9:58 AM, Aldy Hernandez wrote:
On 5/29/19 9:24 AM, Richard Biener wrote:
On Wed, May 29, 2019 at 2:18 PM
Meanwhile I have bootstrapped / tested the following which does the VARYING
thing.
Applied to trunk. I think we need to backport this since this is a latent
wrong-code issue. We can see to improve things on the trunk incrementally.
Folks, thanks so much for taking care of this.
After Richard
We already have value_range::singleton_p. No need for a separate
external function with the same functionality.
OK?
commit 42981b54247461fcaa43d14315efa6fd3abbf949
Author: Aldy Hernandez
Date: Tue Jun 4 18:42:33 2019 +0200
Remove value_range_constant_singleton in favor of value_range
s.
OK?
commit eac5cbfa507146166498e395d9347efdf46d3ef4
Author: Aldy Hernandez
Date: Tue Jun 4 09:11:22 2019 +0200
value_range_base::contains_p and may_contains_p.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index bee0a75a000..4f5c1798751 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,17
On 6/11/19 9:45 AM, Richard Biener wrote:
On Tue, Jun 11, 2019 at 12:40 PM Aldy Hernandez wrote:
This patch cleans up the various contains, may_contain, and
value_inside_range variants we have throughout, in favor of one--
contains_p. There should be no changes in functionality.
I have
On 6/11/19 12:17 PM, Martin Sebor wrote:
On 6/11/19 9:05 AM, Aldy Hernandez wrote:
On 6/11/19 9:45 AM, Richard Biener wrote:
On Tue, Jun 11, 2019 at 12:40 PM Aldy Hernandez
wrote:
This patch cleans up the various contains, may_contain, and
value_inside_range variants we have throughout
On 6/11/19 12:52 PM, Martin Sebor wrote:
On 6/11/19 10:26 AM, Aldy Hernandez wrote:
On 6/11/19 12:17 PM, Martin Sebor wrote:
On 6/11/19 9:05 AM, Aldy Hernandez wrote:
On 6/11/19 9:45 AM, Richard Biener wrote:
On Tue, Jun 11, 2019 at 12:40 PM Aldy Hernandez
wrote:
This patch cleans
On 6/12/19 5:33 AM, Richard Biener wrote:
On Wed, Jun 12, 2019 at 1:57 AM Martin Sebor wrote:
On 6/11/19 3:02 PM, Aldy Hernandez wrote:
On 6/11/19 12:52 PM, Martin Sebor wrote:
On 6/11/19 10:26 AM, Aldy Hernandez wrote:
On 6/11/19 12:17 PM, Martin Sebor wrote:
On 6/11/19 9:05 AM, Aldy
Hi Richard. Hi folks.
In order to unify the APIs for value_range and irange, we'd like to make
some minor changes to value_range. We believe most of these changes
could go in now, and would prefer so, to get broader testing and
minimize the plethora of changes we drag around on our branch.
on x86-64 Linux.
OK?
Aldy
commit dad943a48ff2fccc203bf11839b7e3016e44dfe1
Author: Aldy Hernandez
Date: Mon Jul 22 10:04:43 2019 +0200
Add type to VR_VARYING.
diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c
index 4c68af847e1..0184703a13c 100644
--- a/gcc/gimpl
.
Tested on x86-64 Linux.
OK (assuming ChangeLog entries)?
Aldy
commit ea908bdbfc8cdb4bb63e7d42630d01203edbac41
Author: Aldy Hernandez
Date: Mon Jul 15 18:09:27 2019 +0200
Enforce canonicalization in value_range.
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 594ee9adc17..de2f39d8487
On 8/12/19 7:46 PM, Jeff Law wrote:
On 8/12/19 12:43 PM, Aldy Hernandez wrote:
This is a fresh re-post of:
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg6.html
Andrew gave me some feedback a week ago, and I obviously don't remember
what it was because I was about to leave o
On 8/12/19 7:32 PM, Jeff Law wrote:
On 8/12/19 12:48 PM, Aldy Hernandez wrote:
This is a ping of:
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg8.html
I have addressed the comments Jeff mentioned there.
This patch goes before the VR_VARYING + types patch, but I can adapt
either one to
On 8/14/19 9:50 AM, Andrew MacLeod wrote:
On 8/13/19 8:39 PM, Aldy Hernandez wrote:
Yes, it was 2X.
I noticed that Richi made some changes to the lattice handling for
VARYING while the discussion was on-going. I missed these, and had
failed to adapt the patch for it. I would
On 8/14/19 1:37 PM, Jeff Law wrote:
On 8/13/19 6:39 PM, Aldy Hernandez wrote:
On 8/12/19 7:46 PM, Jeff Law wrote:
On 8/12/19 12:43 PM, Aldy Hernandez wrote:
This is a fresh re-post of:
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg6.html
Andrew gave me some feedback a week ago, and I
On 8/14/19 1:53 PM, Jeff Law wrote:
On 8/13/19 6:51 PM, Aldy Hernandez wrote:
Presumably this was better than moving the implementation earlier.
Actually, it was for ease of review. I made some changes to the
function, and I didn't want the reviewer to miss them because I had
move
On 8/15/19 7:23 AM, Richard Biener wrote:
On Thu, Aug 15, 2019 at 12:40 PM Aldy Hernandez wrote:
On 8/14/19 1:37 PM, Jeff Law wrote:
On 8/13/19 6:39 PM, Aldy Hernandez wrote:
On 8/12/19 7:46 PM, Jeff Law wrote:
On 8/12/19 12:43 PM, Aldy Hernandez wrote:
This is a fresh re-post of
On 8/15/19 7:23 AM, Richard Biener wrote:
On Thu, Aug 15, 2019 at 12:40 PM Aldy Hernandez wrote:
On 8/14/19 1:37 PM, Jeff Law wrote:
On 8/13/19 6:39 PM, Aldy Hernandez wrote:
On 8/12/19 7:46 PM, Jeff Law wrote:
On 8/12/19 12:43 PM, Aldy Hernandez wrote:
This is a fresh re-post of
On 8/15/19 12:06 PM, Aldy Hernandez wrote:
On 8/15/19 7:23 AM, Richard Biener wrote:
On Thu, Aug 15, 2019 at 12:40 PM Aldy Hernandez wrote:
On 8/14/19 1:37 PM, Jeff Law wrote:
On 8/13/19 6:39 PM, Aldy Hernandez wrote:
On 8/12/19 7:46 PM, Jeff Law wrote:
On 8/12/19 12:43 PM, Aldy
On 8/23/19 4:27 PM, Martin Sebor wrote:
On 8/15/19 10:06 AM, Aldy Hernandez wrote:
Hey Aldy,
After enabling EVRP for the strlen pass (as part of the sprintf
integration) I get a SEGV in the return statement in the function
below. Backing out this change gets rid of the ICE and lets my
On 9/13/18 3:33 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 09/12/2018 12:57 PM, Richard Sandiford wrote:
Aldy Hernandez writes:
diff --git a/gcc/wide-int-range.h b/gcc/wide-int-range.h
index 589fdea4df6..e9ee418e5b2 100644
--- a/gcc/wide-int-range.h
+++ b/gcc/wide-int-range.h
On 8/23/18 8:51 AM, Richard Biener wrote:
On Tue, Aug 21, 2018 at 7:35 PM Aldy Hernandez wrote:
On 08/21/2018 05:46 AM, Richard Biener wrote:
On Wed, Aug 15, 2018 at 3:33 AM Aldy Hernandez wrote:
Yeah, nice work. Few comments:
+ TYPE_OVERFLOW_UNDEFINED
On 10/17/18 6:52 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 9/13/18 3:33 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 09/12/2018 12:57 PM, Richard Sandiford wrote:
Aldy Hernandez writes:
diff --git a/gcc/wide-int-range.h b/gcc/wide-int-range.h
index 589fdea4df6
On 10/17/18 6:50 AM, Richard Biener wrote:
On Thu, Oct 11, 2018 at 8:25 PM Aldy Hernandez wrote:
On 10/11/18 5:47 AM, Richard Biener wrote:
On Thu, Oct 11, 2018 at 10:19 AM Aldy Hernandez wrote:
Hi Richard. Thanks for reviewing.
On 10/10/18 6:27 AM, Richard Biener wrote:
On Tue
On 10/18/18 8:11 AM, Richard Biener wrote:
On Thu, 18 Oct 2018, Richard Biener wrote:
At some point we decided to not simply intersect all ranges we get
via register_edge_assert_for. Instead we simply register them
in-order. That causes things like replacing [64, +INF] with ~[0, 0].
The
Is this fixed by Richard's patch to 87640? if so, perhaps this is a
duplicate of said PR.
On Sun, Oct 21, 2018 at 3:34 AM H.J. Lu wrote:
>
> On Wed, Oct 17, 2018 at 7:39 AM Aldy Hernandez wrote:
> >
> >
> >
> > On 10/17/18 6:50 AM, Richard Biener wrote:
&g
On 10/22/18 6:21 AM, Richard Biener wrote:
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-10-22 Richard Biener
PR tree-optimization/87640
* tree-vrp.c (set_value_range_with_overflow): Decompose
incomplete result.
(extract_rang
+ if (tem.kind () == old_vr->kind ()
+ && tem.min () == old_vr->min ()
+ && tem.max () == old_vr->max ())
+ continue;
I think it would be cleaner to use tem.ignore_equivs_equal_p (*old_vr).
The goal was to use == when the equivalence
Thanks!
On Tue, Oct 23, 2018, 13:37 Richard Biener wrote:
> On Tue, 23 Oct 2018, Richard Biener wrote:
>
> > On Tue, 23 Oct 2018, Aldy Hernandez wrote:
> >
> > >
> > > > + if (tem.kind () == old_vr->kind ()
> > > > + &&am
get/set_range_info() currently returns the extremes of a range. I have
implemented overloaded variants that return a proper range. In the
future we should use actual ranges throughout, and not depend on range
extremes, as depending on this behavior could causes us to lose precision.
I am als
As per $SUBJECT.
Depends on get_range_info() API changes I have just submitted.
OK for trunk?
commit 01b8d323f896692d2e999b607f4464861d9ccd8f
Author: Aldy Hernandez
Date: Thu Nov 8 12:56:41 2018 +0100
* vr-values.c (vr_values::get_value_range): Use value_range API
o_tree (TREE_TYPE (t), w)))
Ain't it grand?
OK for trunk, depending on get_range_info changes of course?
Aldy
commit 3a3fa7eb1baba60d17b4b7731972951173c5d615
Author: Aldy Hernandez
Date: Thu Nov 8 13:04:59 2018 +0100
* fold-const.c (expr_not_equal_to): Use value_range API.
diff -
This one's rather obvious and does not depend on any get_range_info API
change.
OK for trunk?
* gimple-ssa-evrp-analyze.c
(evrp_range_analyzer::record_ranges_from_incoming_edge): Use
value_range API instead of piecing together ranges.
diff --git a/gcc/gimple-
This is an obvious patch I will commit once testing completes.
Aldy
* tree-vrp.c (may_contain_p): Do not access m_min/m_max directly.
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 17b0b6c6037..7af676a416d 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -250,10 +250,10 @@ val
Stupid boring changes.
OK?
* tree-vrp.c (value_range::check): Do not access internals
directly.
(value_range::singleton_p): Same.
(value_range::type): Same.
(vrp_finalize): Use value_range API.
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp
I believe I've seen this idiom more than once. I know for sure I've
used it in our ssa-range branch :). I'll hunt for the other uses and
adjust accordingly.
OK?
* tree-vrp.h (value_range::domain_p): New.
* tree-vrp.c (value_range::domain_p): New.
* tree-ssa
[Richard, you're right. An overloaded debug() is better than
this->dump(). Anyone who thinks different is wrong. End of discussion.]
There's no reason to have multiple ways of dumping a value range. And
I'm not even talking about ipa-prop.* which decided that they should
implement their ow
On 11/8/18 8:59 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 12:52 PM Aldy Hernandez wrote:
get/set_range_info() currently returns the extremes of a range. I have
implemented overloaded variants that return a proper range. In the
future we should use actual ranges throughout, and not
On 11/8/18 9:21 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wrote:
All this nonsense:
- rtype = get_range_info (t, &min, &max);
- if (rtype == VR_RANGE)
- {
- if (wi::lt_p (max, w, TYPE_SIGN (TREE_TYPE (t
- ret
On 11/8/18 9:24 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
This one's rather obvious and does not depend on any get_range_info API
change.
OK for trunk?
Hmm, no - that's broken. IIRC m_equiv are shared bitmaps if you
do tem = *old_vr so you
On 11/8/18 9:31 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:42 PM Aldy Hernandez wrote:
Stupid boring changes.
OK?
Well, IMHO using m_min is making clear you are accessing a member
while using min () does not.
There is already prior art here. I believe I discussed this before
On 11/8/18 9:34 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wrote:
I believe I've seen this idiom more than once. I know for sure I've
used it in our ssa-range branch :). I'll hunt for the other uses and
adjust accordingly.
domain_p?! Isn
On 11/8/18 9:41 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:05 PM Aldy Hernandez wrote:
On 11/8/18 8:59 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 12:52 PM Aldy Hernandez wrote:
get/set_range_info() currently returns the extremes of a range. I have
implemented
On 11/8/18 9:43 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:27 PM Aldy Hernandez wrote:
On 11/8/18 9:21 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wrote:
All this nonsense:
- rtype = get_range_info (t, &min, &max);
- i
On 11/8/18 9:49 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
On 11/8/18 9:24 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
This one's rather obvious and does not depend on any get_range_info API
change.
OK for
On 11/8/18 9:56 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:54 PM Aldy Hernandez wrote:
On 11/8/18 9:49 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
On 11/8/18 9:24 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez
On 11/8/18 9:53 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez wrote:
On 11/8/18 9:34 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wrote:
I believe I've seen this idiom more than once. I know for sure I've
used it in our
On 11/8/18 10:24 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 4:05 PM Aldy Hernandez wrote:
On 11/8/18 9:53 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez wrote:
On 11/8/18 9:34 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez
On 11/8/18 9:55 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:50 PM Aldy Hernandez wrote:
On 11/8/18 9:43 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:27 PM Aldy Hernandez wrote:
On 11/8/18 9:21 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez
On 11/8/18 9:39 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 2:32 PM Aldy Hernandez wrote:
[Richard, you're right. An overloaded debug() is better than
this->dump(). Anyone who thinks different is wrong. End of discussion.]
There's no reason to have multiple ways of du
On 11/8/18 4:47 PM, Martin Sebor wrote:
On 11/08/2018 04:52 AM, Aldy Hernandez wrote:
get/set_range_info() currently returns the extremes of a range. I have
implemented overloaded variants that return a proper range. In the
future we should use actual ranges throughout, and not depend on
Patches welcome!
On Fri, Nov 9, 2018, 12:30 Richard Biener On Thu, Nov 8, 2018 at 4:27 PM Jeff Law wrote:
> >
> > On 11/8/18 8:14 AM, Richard Biener wrote:
> > > On Thu, Nov 8, 2018 at 4:00 PM Aldy Hernandez
> wrote:
> > >>
> > >>
> &
On 11/9/18 6:37 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 5:03 PM Aldy Hernandez wrote:
On 11/8/18 9:39 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 2:32 PM Aldy Hernandez wrote:
[Richard, you're right. An overloaded debug() is better than
this->dump(). Anyone wh
On 11/9/18 9:19 AM, Richard Biener wrote:
This adds value_range_base, a base class of class value_range
with all members but the m_equiv one.
First of all, thanks so much for doing this!
I have looked into the sole GC user, IPA propagation, and replaced
the value_range use there with value_
I have rebased my value_range dumping patch after your value_range_base
changes.
I know you are not a fan of the gimple-pretty-print.c chunk, but I still
think having one set of dumping code is preferable to catering to
possible GC corruption while debugging. If you're strongly opposed (as,
On 11/11/18 3:53 AM, Richard Biener wrote:
On Fri, 9 Nov 2018, Aldy Hernandez wrote:
On 11/9/18 9:19 AM, Richard Biener wrote:
This adds value_range_base, a base class of class value_range
with all members but the m_equiv one.
First of all, thanks so much for doing this!
I have
Ug ok.
On Mon, Nov 12, 2018, 12:10 Richard Biener On Mon, 12 Nov 2018, Aldy Hernandez wrote:
>
> >
> >
> > On 11/11/18 3:53 AM, Richard Biener wrote:
> > > On Fri, 9 Nov 2018, Aldy Hernandez wrote:
> > >
> > > > On 11/9/18 9:19 AM,
On 11/12/18 7:12 AM, Richard Biener wrote:
This mainly tries to rectify the workaround I put in place for ipa-cp.c
needing to build value_range instead of value_range_base for calling
extract_range_from_unary_expr.
To make this easier I moved more set_* functions to methods.
Then for some reas
The tricky part starts in the prologue for
if (vr0->undefined_p ())
{
vr0->deep_copy (vr1);
return;
}
but yes, we probably can factor out a bit more common code
here. I'll see to followup with more minor cleanups this
week (noticed a few details myself).
Like thi
On 11/13/18 3:07 AM, Richard Biener wrote:
On Tue, 13 Nov 2018, Aldy Hernandez wrote:
The tricky part starts in the prologue for
if (vr0->undefined_p ())
{
vr0->deep_copy (vr1);
return;
}
but yes, we probably can factor out a bit more common code
here.
On 11/13/18 8:58 AM, Richard Biener wrote:
On Tue, 13 Nov 2018, Aldy Hernandez wrote:
On 11/13/18 3:07 AM, Richard Biener wrote:
On Tue, 13 Nov 2018, Aldy Hernandez wrote:
The tricky part starts in the prologue for
if (vr0->undefined_p ())
{
vr0->deep_cop
On 11/13/18 3:12 AM, Richard Biener wrote:
On Mon, Nov 12, 2018 at 10:50 AM Aldy Hernandez wrote:
I have rebased my value_range dumping patch after your value_range_base
changes.
I know you are not a fan of the gimple-pretty-print.c chunk, but I still
think having one set of dumping code
With your cleanups, the main raison d'etre for my patch goes away, but
here is the promised removal of ignore_equivs_equal_p.
I think the == operator is a bit confusing, and equality intent should
be clearly specified. I am providing the following for the derived
class (with no hidden default
On 11/13/18 1:47 PM, Richard Biener wrote:
On November 13, 2018 5:40:59 PM GMT+01:00, Aldy Hernandez
wrote:
With your cleanups, the main raison d'etre for my patch goes away, but
here is the promised removal of ignore_equivs_equal_p.
I think the == operator is a bit confusing, and equ
On 6/24/19 9:24 AM, Richard Biener wrote:
On Fri, Jun 21, 2019 at 1:41 PM Aldy Hernandez wrote:
Hi Richard. Hi folks.
In order to unify the APIs for value_range and irange, we'd like to make
some minor changes to value_range. We believe most of these changes
could go in now, and
I'm happy to finally contribute the range-ops part of the ranger work.
This is the infrastructure for folding unary and binary ranges of
tree_codes into a resulting range. It is the ranger counterpart of
extract_range_from_*_expr in tree-vrp.c (not the similarly called
callers in vr-values.c).
doing, but I'll be happy to take the blame and address
anything that needs doing.
Tested on x86-64 Linux with --enable-languages=all.
Aldy
commit 24c3a6a2cb7424a9c022930cada3a5f3c84a388a
Author: Aldy Hernandez
Date: Fri Jun 28 11:00:10 2019 +0200
VR_UNDEFINED and VR_VARYING now ha
te of things to come. It
may not be an issue, but just something to keep in mind.
Tested on x86-64 Linux with --enable-languages=all.
Aldy
commit d220a3eeb77615b39260e532e34815a3810e8348
Author: Aldy Hernandez
Date: Fri Jun 28 11:15:03 2019 +0200
Enforce canonicalization in value_range.
ly for the constructors as our
internal implementation has no need for this field. The ranger accesses
things with the higher-level num_pairs(), lower/upper_bound(), etc.
Tested on x86-64 Linux with --enable-languages=all.
Aldy
commit e58c0f8b8a27fa91fe22f1f12d19f3d37cc729ae
Author: Aldy Herna
cc/range-op.cc
@@ -0,0 +1,2096 @@
+/* Code for range operators.
+ Copyright (C) 2017-2019 Free Software Foundation, Inc.
+ Contributed by Andrew MacLeod
+ and Aldy Hernandez .
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the
ed to conservatively add anything to the result.
Tested on x86-64 Linux with --enable-languages=all.
Aldy
commit 4f9aa7bd1066267eee92f622ff29d78534158e20
Author: Aldy Hernandez
Date: Fri Jun 28 11:34:19 2019 +0200
Do not try to further refine a VR_UNDEFINED result when intersecting
value_r
On 7/3/19 4:28 AM, Richard Biener wrote:
On Mon, Jul 1, 2019 at 10:52 AM Aldy Hernandez wrote:
As discussed before, this enforces types on undefined and varying, which
makes everything more regular, and removes some special casing
throughout range handling.
I don't like it too much
On 7/2/19 5:36 PM, Jeff Law wrote:
I don't see anything inherently concerning here. I do wonder if there's
any value in having a debugging function in the class that would iterate
over the ranges and check them for proper canonicalization, verify that
VR_{VARYING,UNDEFINED} objects do not have
501 - 600 of 2322 matches
Mail list logo
