On 8/19/21 2:00 PM, David Malcolm wrote:
On Thu, 2021-08-19 at 11:30 -0600, Martin Sebor via Gcc-patches wrote:
Hey Aldy & Andrew,
I introduced a leak by calling enable_ranger() without pairing it
with one to disable_ranger() on the same function (PR 101984).
I didn't realize (or look to see) t
On 8/19/21 7:09 PM, Martin Sebor via Gcc-patches wrote:
The attached patch changes the new access warning pass to use
the per-function ranger instance. To do that it makes a number
of the global static functions members of the pass (that involved
moving one to a later point in the file, increasi
This patch adds transitive relations to the oracle.
When a relation is registered with the oracle, it searches back thru the
dominator tree for other relations which may provide a transitive
relation and registers those. It also considers any active equivalences
during the search. With this,
On 8/25/21 11:20 AM, Martin Sebor wrote:
Ping: Andrew, did I answer your questions? Do you (or anyone else)
have any other comments on the latest patch below?
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577865.html
I wasn't attempting to block it, its outside my review purview..
I
On 8/25/21 1:25 PM, Martin Sebor wrote:
I noticed that the output of -fdump-tree-walloca (and probably all
passes that call gimple_ranger::export_global_ranges()) includes
the following two lines for all functions, even when there's
nothing else of relevance after them:
Exported global range tab
On 8/25/21 3:15 PM, Martin Sebor wrote:
On 8/25/21 11:46 AM, Andrew MacLeod wrote:
On 8/25/21 1:25 PM, Martin Sebor wrote:
I noticed that the output of -fdump-tree-walloca (and probably all
passes that call gimple_ranger::export_global_ranges()) includes
the following two lines for all function
On 8/25/21 7:49 PM, Martin Sebor wrote:
On 8/25/21 1:34 PM, Andrew MacLeod wrote:
FWIW, I see duplicate output in the EVRP1 dump that looks just like
it could be the output under Non-varying global ranges. I wonder if
it's the result of the block in ranger_cache::fill_block_cache guarded
by
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 anythin
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 (src.m
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 dia
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/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 via
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
i
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 th
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 a
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. Ho
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 p
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
an
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 a
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 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 _exactl
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 functiona
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.
gimple-range-gor
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 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 blo
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: Stores
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 &r, gimple *, tree name = NULL)
bool range_of_expr (irange &r, tree name, g
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 r
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
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 tru
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 me
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 pending
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 value_range_kind
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 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 @@ irange_allocator::
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 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 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 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 descri
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
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 : cl
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
but not
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 ho
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/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
us
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 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 (&m_obstack, sizeof (irange));
Then eit
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 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 (cfun)->range_of_exp
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
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
Yeah, currently the internal cache isnt really wired into the
fold_using_range as its is suppose to be a consistent internal state.
so its not currently expecting to work in a situation here what it
thinks is global state might change.
I figured I better go back and watch your entire VN prese
On 9/21/22 06:13, Richard Biener wrote:
On Mon, 19 Sep 2022, Andrew MacLeod wrote:
It looks like you created a fur_source to manually adjust PHIs within the
fold_stmt query to ignore edges that are not marked executable.
Yes, and use the current values from the VN lattice when looking at
st
Builtin functions have been handled until now as special cases in
gimple-range-fold.cc. This set of patches makes the changes required to
create a range_operator for those functions. This allows them to behave
like a normal unary/binary operation through out the ranger ecosystem.
In particula
When the original patch was applied, I missed a spot which could
also be rewritten to use gimple_range_ssa_names.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 3cba5cd6e019182dbff756f621af048d55cdda98 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Wed, 31 Au
Range_op_handler currently stores a tree code and a type. It defers
checking to see if there is a valid handler until asked.
This change checks at constructor time and store a pointer to the
handler if there is one.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
Fr
Range-ops is meant to be IL independent. Some gimple processing has
be placed in range-ops, and some is located in gori. Split it all into
a file and isolate it in a new class gimple_range_op_handler.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 51ce06385bf2
Unary operations pass the type of operand 1 into op1_range. If that
range is undefined, the routine blindly picks the type of operand
2,which in the case of a unary op, does not exist and traps.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
AndrewFrom a7a6649f4e7c459a95dee
Unary operations require op2 to be the range of the type of the LHS.
This is so the type for the LHS can be properly set. There are is a
missing prototype for this combination.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From be2a25adbdc76a770f7470cc9f47892f7a413
The fold_range routine in range-ops returns FALSE if the operation
fails. There are a few places which assume the operation was
successful. Fix those.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 2f92f685da2ef9e82ee6262519919180df8f2dd9 Mon Sep 17 00:00:00
Check for builtins that can be a range-op entry and Convert
CFN_BUILT_IN_CONSTANT_P as first POC.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From b40b3035879cf695b72010858b9705a344292bdb Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 16:53:3
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From eb82b9f68eb8d0cc65a1a022154c8e729860ea59 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Wed, 21 Sep 2022 09:29:40 -0400
Subject: [PATCH 08/17] Convert CFN_BUILT_IN_SIGNBIT to range-ops.
* gimple-range-fold.cc
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 2f5da730f159de238500c82b0c6ef6c9ab91b1c2 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 17:14:30 -0400
Subject: [PATCH 09/17] Convert CFN_BUILT_IN_TOUPPER and TOLOWER to range-ops.
* gimple-rang
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
AndrewFrom 5f730c650184d4c8bfad513a9e0e593f87a5bf0c Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:07:14 -0400
Subject: [PATCH 10/17] Convert CFN_BUILT_FFS and CFN_POPCOUNT to range-ops.
* gimple-range-
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From ae1669a98656cca594fcd2fef6bd2cd7308a361f Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:12:25 -0400
Subject: [PATCH 11/17] Convert CFN_CLZ builtins to range-ops.
* gimple-range-fold.cc (rang
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 55738d8d96bb4f39a72cf5e3739d35b39fc2146a Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:19:30 -0400
Subject: [PATCH 12/17] Convert CFN_CTZ builtins to range-ops.
* gimple-range-fold.cc (range
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From b6f670ff706e35dc51a62db4206cb241dcac4963 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:48:05 -0400
Subject: [PATCH 14/17] Convert CFN_BUILT_IN_UBSAN_CHECK_* to range-ops.
* gimple-range-fol
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
AndrewFrom f7e62b09300b6935bceaffb4c42f6edab80f52dc Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:21:04 -0400
Subject: [PATCH 13/17] Convert CFN_BUILT_IN_CLRSB to range-ops.
* gimple-range-fold.cc (ran
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From c750e675cb77f283ff991682db7740bc5f6d4cf4 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 19:05:03 -0400
Subject: [PATCH 15/17] Convert CFN_BUILT_IN_STRLEN to range-ops.
* gimple-range-fold.cc (ra
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
AndrewFrom e7f035f66aa25e0537a0e3a76d43c71fe9531724 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 19:19:30 -0400
Subject: [PATCH 16/17] Convert CFN_BUILT_IN_GOACC_DIM_* to range-ops.
* gimple-range-fold.cc
Also, as the last builtin remaining, also remove the builtin
infrastructure routines from fold_using_range.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 5608e410914ebb7c8cc9fa50afc8ada3b22cbf2c Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep
There was a patch posted to remove the undefined behaviour from this
testcase, but it appears to never have been applied.
Pushed.
Andrew
From 73e41228fc8f7f2b6e6a631192533abb2110ba2b Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 27 Sep 2022 18:42:33 -0400
Subject: [PATCH 1/6] Remove
If the LHS is undefined, GORI should not proceed further. There are a
few places where this happens, and a few potential traps. Most haven't
been an issue up until now, but forthcoming changes tend to cause them
to trigger more often.
Bootstrapped on x86_64-pc-linux-gnu with no regressions.
Class value_relation was private within the value-relation.cc file.
This class simply represents a relation between 2 ssa-names, and can
perform various operations on them. The oracle uses it under the
covers to maintains its tables.
It can be used in other places as well, so lets just exp
This patch allows GORI to recognize and pass relations along the
calculation chain. This will allow relations between the LHS and the
operand being calculated to be utilized in op1_range and op2_range.
compute_operand_range will look to see if the current statement creates
a relation between
This allows GORI to recognize when a relation passed in applies to the 2
operands of the current statement. Check to see if further range
refinement is possible before proceeding.
There are 2 primary ways this can happen.
1) The relation record indicates there is a relation between the LHS
If a relation is available, calculate overflow and normal ranges. Then
apply as appropriate.
This patch implements operator_plus::op1/op2_range and
operator_minus::op1_range to utilize any relation passed into properly
reflect the range.
If the relation between the LHS and the operand being
I audited all the op1/op2 range for undefined values, but missed that an
intervening calculation can also cause an undefined range in the middle
of operator_plus::op1_range, and that is the passed to
adjust_op1_for_overflow. That routine also needs to check for
undefined before asking for the
On 10/4/22 08:13, Aldy Hernandez via Gcc-patches wrote:
On Tue, Oct 4, 2022, 13:28 Aldy Hernandez wrote:
On Tue, Oct 4, 2022 at 9:55 AM Richard Biener
wrote:
Am 04.10.2022 um 09:36 schrieb Aldy Hernandez via Gcc-patches <
gcc-patches@gcc.gnu.org>:
The reason the nonzero mask was kept i
On 10/4/22 11:14, Aldy Hernandez wrote:
On Tue, Oct 4, 2022 at 4:34 PM Richard Biener
wrote:
Am 04.10.2022 um 16:30 schrieb Aldy Hernandez :
On Tue, Oct 4, 2022 at 3:27 PM Andrew MacLeod wrote:
On 10/4/22 08:13, Aldy Hernandez via Gcc-patches wrote:
On Tue, Oct 4, 2022, 13:28 Aldy H
It probably should just be changed to a print if it doesn't return..
something like
if (idx && res)
{
tracer.print (idx, "logical_combine produced");
r.dump (dump_file);
fputc ('\n', dump_file);
}
Andrew
On 10/10/22 14:58, Aldy Hernandez wrote:
[Andrew, you OK with this? I c
perfect.
On 10/11/22 10:08, Aldy Hernandez wrote:
Sure.
OK?
Aldy
On Tue, Oct 11, 2022 at 3:11 PM Andrew MacLeod wrote:
It probably should just be changed to a print if it doesn't return..
something like
if (idx && res)
{
tracer.print (idx, "logical_combine produced");
r.dump
On 10/10/22 04:54, Jakub Jelinek via Gcc-patches wrote:
Hi!
My earlier patches gimplify the simplest non-side-effects assumptions
into if (cond) ; else __builtin_unreachable (); and throw the rest
on the floor.
The following patch attempts to do something with the rest too.
For -O0, it actuall
As discussed in the PR, this patch adjusts rangers cache query to
*always* use dominators to lookup ranges in the cache.
It use to give up if it encountered a block with outgoing edge ranges.
This patch changes that to continue looking back until a value is found,
then applies any outgoing ran
On 3/17/22 19:27, Jeff Law via Gcc-patches wrote:
On 3/15/2022 2:03 AM, Roger Sayle wrote:
Speaking of tree-ssa passes that could be improved, I was wondering
whether
you could review my EVRP patch to fix regression PR/102950. Pretty
please?
https://gcc.gnu.org/pipermail/gcc-patches/2022-
On 3/18/22 03:43, Roger Sayle wrote:
Hi Jeff/Andrew,
If you're going to do more work in this space, you might want to reach out to
Aldy and Andrew to see if there's space for collaboration.
One (clever?) suggestion that I do have for ranger would be to add support for
an additional value_range_
On 3/17/22 19:27, Jeff Law via Gcc-patches wrote:
On 3/15/2022 2:03 AM, Roger Sayle wrote:
-Original Message-
From: Richard Biener
Sent: 15 March 2022 07:29
To: Roger Sayle
Cc: GCC Patches
Subject: Re: [PATCH] Ignore (possible) signed zeros in operands of FP
comparisons.
On Mon, Mar
When range_of_stmt was adjusted to avoid large recursion depth, I added
code to precalculate the dependencies without recursion.
This patch adjusted that pre-fill code to intersect the current known
range with the newly calculated one before setting the global range.
this Is what range_of_stm
This patch happens to fix the PR, but I believe it only papers over a
deeper issue that is uncovered in PR104067.
That said, examination of the issue uncovered an oversight in the way
equivalence sets are merged by the equivalence oracle. I have not seen
an instance via the ranger, but I susp
On 1/19/22 04:33, Richard Biener wrote:
On Wed, Jan 19, 2022 at 2:37 AM Andrew MacLeod via Gcc-patches
wrote:
OK for trunk?
OK. I don't quite understand how what you describe above works, it sounds
a bit odd with respect to the idea that equivalences should be transitive but
The trans
I have a proposal for PR 104288.
This PR highlights the shortcomings of assuming that when the non-null
property is seen within a block, that it applies to the entire block.
This is a 3 patch set, but is less dramatic than it sounds. I just
wanted to split it into small bits for safety and r
This patch changes the non-null tracking in ranger to use 2 bits in order
to distinguish between blocks which contain uses of NAME in:
1) non-null generating statements, (1 bit)
2) statements which are not non-null generating (the other bit),
THis is the new bit.
3) and the existence of
This patch adds the ability to register side effects within a block to
ranger. This is currently only for tracking non-null values.
the rvrp_folder performs a DOM walk and then attempts to simplify and
the fold each stmt during the walk. This patch adds a call to
register_side_effects() to re
This changes the non-null interface to provide more granularity and
facilitate more precise queries.
Previously, we could only ask if NAME was nonnull anywhere in the block,
and it applied to the entire block. now we can ask:
bool always_nonnull_p (tree name, basic_block bb); // all uses
The patches resolves the issue for GCC11 in a much simpler way.
By default, ranger and EVRP are running in hybrid mode. This means if
ranger misses something, evrp will pick up the slack. This enables us to
change the 2 places which check for non-null to ignore potentially
incorrect block-wide
On 2/7/22 09:29, Andrew MacLeod wrote:
I have a proposal for PR 104288.
ALL patches (in sequence) bootstrap on their own and each cause no
regressions.
I've been continuing to work with this towards the GCC13 solution for
statement side effects. And There is another possibility we could
pu
101 - 200 of 687 matches
Mail list logo
