On 9/3/20 3:43 AM, Richard Biener wrote:
On Thu, Sep 3, 2020 at 9:21 AM Aldy Hernandez wrote:
On 8/31/20 2:55 PM, Richard Biener wrote:
On Mon, Aug 31, 2020 at 11:10 AM Aldy Hernandez wrote:
On 8/31/20 10:33 AM, Richard Biener wrote:
On Mon, Aug 31, 2020 at 10:20 AM Aldy Hernandez
On 9/15/20 11:57 AM, Aldy Hernandez wrote:
This fixes an ICE when trying to copy a legacy value_range containing
a symbolic to a multi-range:
min = make_ssa_name (type);
max = build_int_cst (type, 55);
value_range vv (min, max);
int_range<2> vr = vv;
This doesn't affect
When I broke r11-3684 temporarily yesterday, it was fixed in the next
commit.
But it does mean that for anyone bisecting a problem, theres a broken
commit.
Is there a blessed way to fix that? or does it stay broken forever?
All I need to do is change a single line in gimple-range.h...
or do
On 10/6/20 2:59 PM, Andrew MacLeod via Gcc-patches wrote:
On 10/6/20 2:41 PM, Andreas Schwab wrote:
On Okt 06 2020, Andrew MacLeod via Gcc-patches wrote:
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 7031a823138..02a952bf81f 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
On 10/7/20 2:10 AM, Richard Biener wrote:
On Tue, Oct 6, 2020 at 7:06 PM Andrew MacLeod via Gcc-patches
wrote:
I have now checked in the hybrid EVRP pass.
We have resolved all the issue we are aware of with a full Fedora build,
but if any more issues arise, please let us know. (And Im sure
On 10/7/20 11:19 AM, Aldy Hernandez wrote:
On 10/7/20 8:10 AM, Richard Biener wrote:
> On Tue, Oct 6, 2020 at 7:06 PM Andrew MacLeod via Gcc-patches
> wrote:
>>
>> I have now checked in the hybrid EVRP pass.
>>
>> We have resolved all the issue we are awar
On 10/2/20 9:26 AM, Martin Liška wrote:
Yes, you simply get all sorts of conditions that hold when a
condition is
true, not just those based on the SSA name you put in. But it occured
to me that the use-case is somewhat different - for switch-conversion
you want to know whether the test
On 10/5/20 4:16 PM, Martin Sebor wrote:
On 10/5/20 8:50 AM, Aldy Hernandez via Gcc-patches wrote:
[Martin, as the original author of this pass, do you have any concerns?]
@@ -1270,7 +1271,21 @@ get_size_range (tree exp, tree range[2], bool
allow_zero /* = false */)
enum
On 10/5/20 11:51 AM, Aldy Hernandez wrote:
More changes from the ranger branch that been tested and retested,
including a full Fedora build.
These are cleanups so that multi-range union/intersect doesn't have to
deal with legacy code. Instead, these should be done in legacy mode.
OK
On 10/6/20 6:22 AM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 06, 2020 at 11:20:52AM +0200, Aldy Hernandez wrote:
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 94b48e55e77..7031a823138 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -670,7 +670,7 @@
On 10/6/20 8:09 AM, Martin Liška wrote:
On 10/2/20 4:19 PM, Andrew MacLeod wrote:
On 10/2/20 9:26 AM, Martin Liška wrote:
Yes, you simply get all sorts of conditions that hold when a
condition is
true, not just those based on the SSA name you put in. But it occured
to me that the use-case is
On 10/6/20 9:09 AM, Martin Liška wrote:
On 10/6/20 2:56 PM, Andrew MacLeod wrote:
Ah, by just using the outgoing_range class, all you are getting is
static edges. so a TRUE edge is always a [1,1] and a false edge is [0,0]
I provided that class so you could get the constant edges on switches.
On 10/6/20 8:55 AM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 08:47:53AM -0400, Andrew MacLeod wrote:
I think the proper alignment will be guaranteed if irange and tree[] are
obstack_alloc'd separately. They don't need to be adjacent, do they?
They do not, it just seemed wasteful to do 2
On 10/6/20 6:40 AM, Andreas Schwab wrote:
On Okt 06 2020, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 10:47:34AM +0200, Andreas Schwab wrote:
On Okt 06 2020, Jakub Jelinek via Gcc-patches wrote:
I mean, we could just use:
size_t nbytes = sizeof (irange) + sizeof (tree) * 2 * num_pairs;
On 10/6/20 10:30 AM, Martin Sebor wrote:
On 10/6/20 3:45 AM, Aldy Hernandez wrote:
- builtin_memref dstref (dst, dstsize);
- builtin_memref srcref (src, srcsize);
+ builtin_memref dstref (query, call, dst, dstsize);
+ builtin_memref srcref (query, call, src, srcsize);
/* Create a
I have checked in the ranger classes/files. They are being built but
not being invoked until the other passes are checked in.
there are 8 new files:
gimple-range-cache.{h,cc} : Various caches used by the ranger.
gimple-range-edge.{h,cc} : Outgoing edge range calculations,
particularly
In the hybrid folder, range_of_stmt and range_on_edge invoke the same
routines in both evrp_folder and ranger_folder and compare results.
In implementing hybrid folder, I inherited it from evrp_folder since
EVRP has a few pre-and post statement things to do.
when the hybdrid folder calls
We were asserting that the shifts should not be negative, instead, just
return false indicating we can't tell anything about operand1 from the
result.
Bootstrapped on x86_64-pc-linux-gnu, no regressions, pushed.
Andrew
2020-10-16 Andrew Macleod
PR tree-optimization/97462
gcc/
*
AS Jakub observed in an earlier testcase (97325), when EVRP dumps the
known SSA_RANGES, it isn't expecting names to be deleted that it could
not delete, so it wasn't checking.
With the hybrid model, ranger sometimes deletes things that EVRP
calculated a range for, and the resulting dump was
In order to match evrp behaviour, adjust POINTER_PLUS_EXPR processing to
handle a zero constant plus something to return the something.
ie
[0, 0] + CONST will now return [CONST, CONST] instead of the
previous behaviour of [1, +INF].
Bootstrapped on x86_64-pc-linux-gnu, no regressions,
On 10/19/20 6:36 AM, Aldy Hernandez wrote:
The test is trying to shift by 129, but the underlying type is 128 bits.
This causes low_bits to wrap around to -1 and things go bad really
quick.
Attached is my proposed solution.
Andrew, do you have a preference on how to fix this?
If we know we
On 10/19/20 5:38 AM, Aldy Hernandez wrote:
If the shift amount in operator_lshift::op1_range was zero, an invalid range
of [1, 0] was being created.
Should we do the same thing with rshift::op1_range? ie, return the
LHS if the shift is 0 instead of trying to figure it out
Pushed.
On 10/6/20 1:32 PM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 06, 2020 at 10:42:12AM -0600, Martin Sebor wrote:
The manual documents the [0] extension and mentions but discourages
using [1]. Nothing is said about other sizes and the warnings such
as -Warray-bounds have been increasingly
On 10/5/20 8:09 AM, Jakub Jelinek wrote:
On Fri, Oct 02, 2020 at 12:59:54PM -0400, Andrew MacLeod via Gcc-patches wrote:
The ranger is needed to map those values to the switch variable, and also
apply any previous ranges or derived values (ie, if you ask for the range of
'y' in case 2
On 10/6/20 2:41 PM, Andreas Schwab wrote:
On Okt 06 2020, Andrew MacLeod via Gcc-patches wrote:
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 7031a823138..02a952bf81f 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -668,13 +668,12 @@ irange_allocator::allocate (unsigned
On 10/6/20 12:56 PM, Tobias Burnus wrote:
Build fails here now with: gimple-range.h:168:59: error:
‘EVRP_MODE_DEBUG’ was not declared in this scope
Tobias
On 10/6/20 6:49 PM, Andrew MacLeod via Gcc-patches wrote:
I have checked in the ranger classes/files. They are being built
On 10/6/20 1:10 PM, Tobias Burnus wrote:
On 10/6/20 6:56 PM, Tobias Burnus wrote:
Build fails here now with: gimple-range.h:168:59: error:
‘EVRP_MODE_DEBUG’ was not declared in this scope
And now builds – as the "Hybrid EVRP and testcases" was pushed as well,
a bit more than a quarter of an
On 10/6/20 1:48 PM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 01:41:54PM -0400, Andrew MacLeod wrote:
On 10/6/20 1:32 PM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 06, 2020 at 10:42:12AM -0600, Martin Sebor wrote:
The manual documents the [0] extension and mentions but discourages
On 10/6/20 2:18 PM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 02:09:42PM -0400, Andrew MacLeod wrote:
+ size_t nbytes = sizeof (tree) * 2 * num_pairs;
+
+ // Allocate the irnge and required memory for the vector
+ void *r = (irange *) obstack_alloc (_obstack, sizeof (irange));
Then
I have now checked in the hybrid EVRP pass.
We have resolved all the issue we are aware of with a full Fedora build,
but if any more issues arise, please let us know. (And Im sure you will :-)
I made some minor tweaks. the option to the new -fevrp-mode flag are now:
legacy :
On 10/6/20 1:58 PM, Andrew MacLeod via Gcc-patches wrote:
On 10/6/20 1:48 PM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 01:41:54PM -0400, Andrew MacLeod wrote:
On 10/6/20 1:32 PM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 06, 2020 at 10:42:12AM -0600, Martin Sebor wrote:
The manual
On 10/6/20 3:27 PM, Martin Sebor wrote:
On 10/5/20 8:18 PM, Andrew MacLeod wrote:
On 10/5/20 4:16 PM, Martin Sebor wrote:
Long term, I would expect we might have some sort of general
access... probably thru cfun. so any pass/routines would just ask
for
RANGE_INFO
On 10/5/20 11:19 AM, Aldy Hernandez wrote:
This patch imports three fixes from the ranger branch:
1. Fold division by zero into varying instead of undefined.
This provides compatibility with existing stuff on trunk.
2. Solver changes for lshift and rshift.
This should not affect anything on
On 10/5/20 11:28 AM, David Malcolm via Gcc-patches wrote:
On Mon, 2020-10-05 at 11:51 +0200, Aldy Hernandez via Gcc-patches
wrote:
The walloca pass is a mess. It has all sorts of heuristics to
divine
problematic ranges fed into alloca, none of them very good, and all
of
them unreadable. The
On 10/12/20 8:39 AM, Martin Liška wrote:
On 10/6/20 4:12 PM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 03:48:38PM +0200, Martin Liška wrote:
On 10/6/20 9:47 AM, Richard Biener wrote:
But is it really extensible with the current implementation? I
doubt so.
I must agree with the
On 10/13/20 2:10 AM, Richard Biener wrote:
On Mon, Oct 12, 2020 at 6:57 PM Aldy Hernandez via Gcc-patches
wrote:
Division by zero should return VARYING, otherwise we propagate undefine all
over the
ranger and cause bad things to happen :)
So we never should propagate UNDEFINED?
I added a
This fixes the second test case in pr 97360.
There are a few places in the ranger where we sanity check the types of
the ranges. We were using types_compatible_p() but thats not really
acccurate as gimple allows types which are useless_type_conversion_p()
in only one direction, whereas
On 8/18/20 12:38 PM, Aldy Hernandez wrote:
And here's the patch without the sanity check.
Aldy
That diff was difficult to read.. I had to apply the patch to really
follow it :-P
Anyway, yeah, this looks better. effectively, you have
1) left the input range "vr" range merging in
On 8/24/20 5:53 PM, Jeff Law wrote:
On Wed, 2020-08-05 at 17:41 +0200, Aldy Hernandez wrote:
On 8/5/20 5:09 PM, Martin Jambor wrote:
On Fri, Jul 31 2020, Aldy Hernandez via Gcc-patches wrote:
[...]
* ipa-cp changes from vec to std::vec.
We are using std::vec to ensure constructors are
On 8/14/20 12:05 PM, Aldy Hernandez wrote:
I made some minor changes to the function comments.
gcc/ChangeLog:
* vr-values.c (check_for_binary_op_overflow): Change type of store
to range_query.
(vr_values::adjust_range_with_scev): Abstract most of the code...
On 8/17/20 6:04 AM, Aldy Hernandez wrote:
On 8/14/20 7:16 PM, Andrew MacLeod wrote:
On 8/14/20 12:05 PM, Aldy Hernandez wrote:
I made some minor changes to the function comments.
gcc/ChangeLog:
* vr-values.c (check_for_binary_op_overflow): Change type of store
to range_query.
On 9/24/20 5:51 PM, Martin Sebor via Gcc-patches wrote:
On 9/18/20 12:38 PM, Aldy Hernandez via Gcc-patches wrote:
3. Conversion of sprintf/strlen pass to class.
This is a nonfunctional change to the sprintf/strlen passes. That is,
no effort was made to change the passes to multi-ranges.
On 9/23/20 7:53 PM, Martin Sebor via Gcc-patches wrote:
On 9/18/20 12:38 PM, Aldy Hernandez via Gcc-patches wrote:
As part of the ranger work, we have been trying to clean up and
generalize interfaces whenever possible. This not only helps in
reducing the maintenance burden going forward, but
On 9/25/20 1:41 PM, Andrew MacLeod via Gcc-patches wrote:
On 9/23/20 7:53 PM, Martin Sebor via Gcc-patches wrote:
On 9/18/20 12:38 PM, Aldy Hernandez via Gcc-patches wrote:
As part of the ranger work, we have been trying to clean up and
generalize interfaces whenever possible. This not only
On 10/1/20 5:05 AM, Aldy Hernandez via Gcc-patches wrote:
Thanks for doing all this! There isn't anything I don't understand
in the sprintf changes so no questions from me (well, almost none).
Just some comments:
Thanks for your comments on the sprintf/strlen API conversion.
The current call
On 10/1/20 5:30 PM, David Edelsohn wrote:
* config/rs6000/rs6000-call.c: Include value-range.h.
* config/rs6000/rs6000.c: Likewise.
This is okay for trunk, thanks! (It is trivial and obvious as well, so
please just commit things like this without prior approval.)
This patch is not the correct
On 9/17/20 12:08 PM, Martin Sebor via Gcc-patches wrote:
On 9/16/20 9:23 PM, Jeff Law wrote:
On 9/15/20 1:47 PM, Martin Sebor wrote:
Overflowing the size of a dynamic allocation (e.g., malloc or VLA)
can lead to a subsequent buffer overflow corrupting the heap or
stack. The attached patch
On 9/18/20 1:07 PM, Martin Sebor wrote:
On 9/18/20 8:10 AM, Aldy Hernandez via Gcc-patches wrote:
On 9/18/20 2:28 PM, David Malcolm wrote:
On Fri, 2020-09-18 at 07:49 +0200, Aldy Hernandez wrote:
On 9/18/20 3:43 AM, David Malcolm wrote:
On Thu, 2020-09-17 at 12:36 +0200, Aldy Hernandez
On 9/18/20 4:35 PM, Martin Sebor wrote:
On 9/18/20 11:36 AM, Andrew MacLeod wrote:
On
it works exactly like one would expect a simple allocator to work..
as long as the allcoator is "live", its allocations are live. once
it is destructed, all the memory it manages is freed.. It purpose
On 9/28/20 11:27 AM, Martin Sebor wrote:
On 9/25/20 11:41 AM, Andrew MacLeod wrote:
Since you have replied to this thread, whats your opinion whether
there should be an extra API entry point for range/value_after_stmt
or whether that should be rolled into the range_of_stmt routine, and
On 9/18/20 1:03 PM, Aldy Hernandez wrote:
On 9/18/20 6:42 PM, Andrew MacLeod wrote:
On 9/18/20 8:28 AM, David Malcolm wrote:I think of a "pool allocator"
as something that makes a small
number of
large allocation under the covers, and then uses that to serve
large
numbers of fixed sized small
This is the true core of the ranger.
The GORI (Generates Outgoing Range Information) engine contains all the
smarts to utilize the functionality provided via range-ops in order to
calculate outgoing ranges on an edge, based on the control flow at the exit.
It functions *only* at the basic
Where to start?
This is the culmination of numerous years work on the ranger for
generating accurate on-demand ranges in GCC.
There are 2 patch sets as a part of this submission
1) The ranger & Enhancements to EVRP
3) Other passes converted to Ranger
There is still some missing
These are the various caches used by the ranger.
- non-null-ref : Tracks non-null pointer dereferences in blocks so we
can properly calculate non-null pointer ranges
- on entry cache : Block ranges tracks the calucalted values sof
ssa-names on entry to each basic block.
- global cache:
This is the ranger component that pulls all the others bits together.
Its API is basically the range_query we've already pushed into the
compiler. The main ones a client are likely to use are
bool range_of_stmt (irange , gimple *, tree name = NULL)
bool range_of_expr (irange , tree name,
This file produces constant edge ranges. It provides a class which can
be instantiated and will return the range on any edge.
This was originally suppose to be trivial, but switches mucked that up :-)
There are 2 basic expressions that can result ina constant range on an
edge:
Note there is
This patch set contains the various components that make up a ranger.
Ranger files are prefixed by "gimple-range".
gimple-range-cache.{h,cc} : Various caches used by the ranger.
gimple-range-edge.{h,cc} : Outgoing edge range calculations,
particularly switch edge ranges.
The patch switches to a hybrid EVRP pass which utilizes both the Ranger
and the classic EVRP pass.
it introduces a new undocumented option:
-fevrp-mode= which can be one of the following options
evrp-only : This is classic EVRP mode, identical to whats in trunk now.
rvrp-only : This
On 9/19/20 4:32 PM, Martin Sebor wrote:
On 9/18/20 3:09 PM, Andrew MacLeod wrote:
O
What I meant by proxy is a substitute class each of whose objects
stands in for a single instance of int_range where N is
a runtime value. There's no class like that.
[Just to be clear, I don't meant for
On 9/16/20 12:25 PM, Aldy Hernandez wrote:
>> // Swap min/max if they are out of order. Return TRUE if further
> these seems OK, but can't there be anti-ranges with symbolics too? ie
> ~[a_12, a_12]
> The code for that just does:
>
> else if (src.kind () == VR_ANTI_RANGE)
> set
On 9/18/20 8:28 AM, David Malcolm wrote:I think of a "pool allocator" as
something that makes a small
number of
large allocation under the covers, and then uses that to serve
large
numbers of fixed sized small allocations and deallocations with
O(1)
using a free list.
Ah, I didn't know pool had
On 9/19/20 4:32 PM, Martin Sebor wrote:
On 9/18/20 3:09 PM, Andrew MacLeod wrote:
On 9/18/20 4:35 PM, Martin Sebor wrote:
Do you really need 6 or 10 subranges to find out the answer to the
questions you are looking for? most of the time, 2 or 3 pairs
carries all the information anyone needs
Pick up the correct type for the RHS of a_2 =
bootstrapped on x86_64-pc-linux-gnu, no regressions, pushed.
Andrew
commit 966fdb2e12c0347aa3f9efaf5f4e1cd8237fa024
Author: Andrew MacLeod
Date: Wed Oct 21 20:11:16 2020 -0400
Handle a_2= properly in range calculations.
when
Full comments in the PR, but basically substitute and fold was expecting
to see a constant returned for any range which globally evaluates to a
constant.
This allowed it to replace all uses of an ssa name as they were encountered.
The ranger model can return UNDEFINED for the range of names in
On 10/19/20 6:03 AM, Aldy Hernandez wrote:
Forwarded Message
Subject: [PATCH] Refactor range handling of builtins in vr_values and
ranger.
Date: Fri, 9 Oct 2020 14:32:05 +0200
From: Aldy Hernandez
To: GCC patches , Jakub Jelinek
CC: Andrew MacLeod , Aldy Hernandez
On 10/19/20 1:16 PM, Aldy Hernandez wrote:
Rebased on current trunk.
FWIW, we finally get rid of the Walloca-6.c XFAIL. This has been a long time
in coming:
-/* { dg-xfail-if "Currently broken but Andrew's work should fix this" { *-*-*
} } */
:-)
OK?
You are the original author of this
On 10/20/20 12:43 PM, Aldy Hernandez wrote:
As promised.
Now that we know the vr_values and ranger versions are in sync, it
is safe to remove the vr_values version and just call the ranger one.
I am holding off on pushing this for a week or two, or until Fedora gets
rebuilt with the current
On 10/19/20 1:23 PM, Aldy Hernandez wrote:
Rebased on current trunk.
There is one adjustment to a C++ test which now gives a false positive.
After talking with Martin Sebor, we've concluded this is expected. There
is no way to communicate that libstdc++ allocated objects are always
less than
In the core of gori_compute::logical_combine we are suppose to combine
the calculated true and false ranges on each side of the operation.
when encountering
[0,0] = c_3 | c_4
we know we only need to consider the FALSE values of the range carried
by c_3 and c_4, but it can be EITHER of
There are a couple of little things I've been meaning to get to.
1) The API routines return TRUE when a range has been computed, and
false when one cannot be. The range itself was uninitialized when false
was returned, and this was a bit awkward by times.
Now, when false is returned, the
On 10/28/20 5:43 AM, Richard Sandiford via Gcc-patches wrote:
This PR shows another problem with calculating value ranges for
POLY_INT_CSTs. We have:
ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]>
where the VQ coefficient is unsigned but is effectively acting
as a negative number.
On 10/27/20 7:23 AM, Christophe Lyon wrote:
Hi,
On Mon, 26 Oct 2020 at 22:51, Andrew MacLeod via Gcc-patches
wrote:
In the core of gori_compute::logical_combine we are suppose to combine
the calculated true and false ranges on each side of the operation.
when encountering
[0,0] = c_3
On 10/27/20 10:44 AM, H.J. Lu wrote:
On Tue, Oct 27, 2020 at 7:18 AM Andrew MacLeod via Gcc-patches
wrote:
On 10/27/20 7:23 AM, Christophe Lyon wrote:
Hi,
On Mon, 26 Oct 2020 at 22:51, Andrew MacLeod via Gcc-patches
wrote:
In the core of gori_compute::logical_combine we are suppose
On 10/25/20 8:37 PM, Maciej W. Rozycki wrote:
On Tue, 6 Oct 2020, Andrew MacLeod via Gcc-patches wrote:
Build fails here now with: gimple-range.h:168:59: error:
‘EVRP_MODE_DEBUG’ was not declared in this scope
And now builds – as the "Hybrid EVRP and testcases" was pushed as well,
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
On 8/6/20 9:30 PM, Martin Sebor wrote:
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
+ // Remove the unknown parts of a multi-range.
+ // This will transform [5,10][20,MAX] into
On 8/10/20 2:46 PM, Martin Sebor wrote:
On 8/10/20 11:50 AM, Andrew MacLeod wrote:
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
On 8/6/20 9:30 PM, Martin Sebor wrote:
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
+ //
On 8/10/20 2:46 PM, Martin Sebor wrote:
On 8/10/20 11:50 AM, Andrew MacLeod wrote:
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
int_range is the type which allows for up to X subranges.
calculations will be merged to fit within X
On 8/5/20 12:54 PM, Richard Biener via Gcc-patches wrote:
On August 5, 2020 5:09:19 PM GMT+02:00, Martin Jambor wrote:
On Fri, Jul 31 2020, Aldy Hernandez via Gcc-patches wrote:
[...]
* ipa-cp changes from vec to std::vec.
We are using std::vec to ensure constructors are run, which they
On 8/11/20 7:53 AM, Aldy Hernandez via Gcc-patches wrote:
-- Forwarded message -
From: Aldy Hernandez
Date: Tue, Aug 4, 2020, 13:55
Subject: [PATCH 1/2] Add statement context to get_value_range.
To:
Cc: , Aldy Hernandez
This is in line with the statement context that we have
On 1/9/21 3:33 PM, Alexandre Oliva wrote:
On Jan 7, 2021, Richard Biener wrote:
On Wed, Jan 6, 2021 at 12:34 PM Alexandre Oliva wrote:
On Jan 4, 2021, Richard Biener wrote:
Thus, please remove uses of BREAK_FROM_IMM_USE_STMT
together with this patch.
And RETURN_FROM_IMM_USE_STMT, I
On 11/26/20 3:52 AM, Jakub Jelinek wrote:
Hi!
For signed integers with undefined overflow we already optimize x * y / y
into x, but for signed integers with -fwrapv or unsigned integers we don't.
The following patch allows optimizing that into just x if value ranges
prove that x * y will never
On 11/21/20 12:07 AM, Jeff Law wrote:
On 11/9/20 9:00 AM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554000.html
Jeff, I don't expect to have the cycles to reimplement this patch
using the Ranger APIs before stage 1 closes. I'm open to giving
it a try
On 11/24/20 12:42 PM, Andrew MacLeod wrote:
On 11/23/20 4:38 PM, Martin Sebor wrote:
On 11/21/20 6:26 AM, Andrew MacLeod wrote:
On 11/21/20 12:07 AM, Jeff Law wrote:
On 11/9/20 9:00 AM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554000.html
Jeff, I
On 11/23/20 4:38 PM, Martin Sebor wrote:
On 11/21/20 6:26 AM, Andrew MacLeod wrote:
On 11/21/20 12:07 AM, Jeff Law wrote:
On 11/9/20 9:00 AM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554000.html
Jeff, I don't expect to have the cycles to reimplement
operator_cast::op1_range() does some masking and calculations when a
higher precision value is cast to a lower precision one.
ie, it fills in the ranges for the upper bits and trys to produce more
usable results for the wind-back process. Part of that calculation
involved using PLUS_EXPR to
With very large CFG's ranger on entry cache is not particularly efficient.
One thing I never got to was recognizing that if an ssa-name is never
used in an outgoing edge calculation, then its range never changes.. the
global range is sufficient and we do not need to propagate the on-entry
On 12/17/20 1:37 PM, sunil.k.pandey wrote:
On Linux/x86_64,
c25b504636fec7bf8f181a84af83a52757ba7e89 is the first bad commit
commit c25b504636fec7bf8f181a84af83a52757ba7e89
Author: Andrew MacLeod
Date: Thu Dec 17 09:24:11 2020 -0500
Fix trap in pointer conversion in op1_range.
caused
On 11/9/20 4:38 PM, Eric Botcazou wrote:
Hi,
this is a regression present on mainline in the form of wrong code generated
for the attached Ada testcase at -O -ftree-vrp. It's again an issue with the
8-bit booleans in Ada and, as a matter of fact, it's exactly the same issue as
the one I fixed
On 11/5/20 2:29 PM, Martin Sebor wrote:
On 10/1/20 11:25 AM, Martin Sebor wrote:
I have applied the patch and ran some tests. There are quite
a few failures (see the list below). I have only looked at
a couple. The one in in gcc.dg/tree-ssa/builtin-sprintf-warn-3.c
boils down to the
Doh.
The original fix for PR97657 was incorrect. It papered over a problem
by reducing opportunities it could find. Given
if (c_2 || c_3)
If the FALSE edge is taken, this is ! (c_2 || c_3) which is equivalent
to !c_2 && !c_3.. so performing the intersection as combine_logical was
On 11/10/20 5:41 AM, Aldy Hernandez wrote:
[Andrew, this doesn't fix a PR per se. It's just something I stumbled
upon in my other -fstrict-enums fixes. It passes tests. What do you
think? Should we push it?]
Imagine an enum in an -fstrict-enums world:
enum foo { zero, one, two,
On 11/12/20 3:53 PM, Richard Biener wrote:
On November 12, 2020 9:43:52 PM GMT+01:00, Andrew MacLeod via Gcc-patches
wrote:
So I spent some time tracking down a ranger issue, and in the end, it
boiled down to the range-op handler not being picked up properly.
The handler is picked up
So I spent some time tracking down a ranger issue, and in the end, it
boiled down to the range-op handler not being picked up properly.
The handler is picked up by:
if ((gimple_code (s) == GIMPLE_ASSIGN) || (gimple_code (s) ==
GIMPLE_COND))
return range_op_handler (gimple_expr_code
On 11/12/20 4:12 PM, Andrew MacLeod via Gcc-patches wrote:
On 11/12/20 3:53 PM, Richard Biener wrote: ...
But it means that gimple_expr_code() isn't returning the correct result
for GIMPLE_SINGLE_RHS
It depends. A SSA name isn't an expression code either. As said, the
generic
On 11/13/20 4:05 AM, Richard Biener wrote:
On Thu, Nov 12, 2020 at 10:12 PM Andrew MacLeod <mailto:amacl...@redhat.com>> wrote:
On 11/12/20 3:53 PM, Richard Biener wrote:
> On November 12, 2020 9:43:52 PM GMT+01:00, Andrew MacLeod via
Gcc-patches mailto:gcc-patches
When shifting outside the valid range of [0, precision-1], we can choose
to process just the valid ones since the rest is undefined.
This allows us to produce results for x << [0,2][+INF, +INF] by
discarding the invalid ranges and processing just [0,2].
THis is particularly important when
On 11/19/20 5:41 PM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, the previous PR91029 patch was testing
op2 >= 0 which is unnecessary, even negative op2 values will work the same,
furthermore, from if a % b > 0 we can deduce a > 0 rather than just a >= 0
(0 % b would be 0), and it actually
On 11/19/20 10:56 PM, sunil.k.pandey wrote:
On Linux/x86_64,
d0d8b5d83614d8f0d0e40c0520d4f40ffa01f8d9 is the first bad commit
commit d0d8b5d83614d8f0d0e40c0520d4f40ffa01f8d9
Author: Andrew MacLeod
Date: Thu Nov 19 17:41:30 2020 -0500
Process only valid shift ranges.
caused
FAIL:
On 11/18/20 3:35 AM, Aldy Hernandez wrote:
On 11/17/20 11:01 PM, Andrew MacLeod wrote:
PR 91029 observes when
a % b > 0 && b >= 0,
then a has an implied range of a >=0. likewise
Shouldn't that be && b > 0? b == 0 is undefined.
If you were folding, sure, but I think its OK for
PR 83072 mentions that we have lost the ability to recognize that when
we see
c |= 1;
c cannot be zero. We can at least put it back for multi-ranges. Added
a new testcase to make sure EVRP is tracking it.
bootstrapped on x86_64-pc-linux-gnu, no regressions. pushed.
Andrew
commit
1 - 100 of 687 matches
Mail list logo
