On 9/29/23 16:17, Jeff Law wrote:
On 9/5/23 01:12, Andrew Pinski wrote:
On Mon, Sep 4, 2023 at 11:06 PM Jeff Law via Gcc-patches
wrote:
On 9/1/23 11:30, Andrew Pinski via Gcc-patches wrote:
So it turns out there was a simplier way of starting to
improve VRP to start to fix PR 110131, P
On 5/16/25 02:35, Richard Biener wrote:
On Thu, May 15, 2025 at 7:02 PM Andrew MacLeod wrote:
Recent changes to get_range_from_bitmask can sometimes turn a small
range into an undefined one if the bitmask indicates the bits make all
values impossible.
range_cast () was not expecting this and
. Pushed.
Andrew
From b3327649bffd32af962662dce054b94be2d7330d Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Wed, 14 May 2025 11:13:15 -0400
Subject: [PATCH 3/4] Allow bitmask intersection to process unknown masks.
bitmask_intersection should not return immediately if the current mask is
w
From f332f23d6b6b45dce3ab19440eecffa26bf3fc15 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 15 May 2025 11:06:05 -0400
Subject: [PATCH 1/5] Check for casts becoming UNDEFINED.
In various situations a cast that is ultimately unreahcable may produce
an UNDEFINED result, and we can't check th
r for irange_bitmask.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.
From e4c6a0214c3ea8aa73e50b1496eb7a8aa5eda635 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 13 May 2025 13:23:16 -0400
Subject: [PATCH 1/4] Turn get_bitmask_from_range into an irange_bitmask
constructor.
lves the PR by successfully tracking the bit through to
the AND operation.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From ac55655ce45a237a6a01e0cce50211841603c2ec Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Wed, 14 May 2025 11:32:58 -0400
Subject: [PATC
: [5, 7] mask 0x3 value 0x4 // first 6 bits are known to
be 01
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 65cd212bd4c533351a09e6974f40ae5d7effca84 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Wed, 14 May 2025 11:12:22 -0400
Subject: [PATCH 2/
On 4/29/25 18:00, Andrew MacLeod wrote:
On 3/28/25 05:25, Jakub Jelinek wrote:
On Fri, Mar 28, 2025 at 08:12:35AM +0100, Richard Biener wrote:
On Thu, Mar 27, 2025 at 8:14 PM Andrew MacLeod
wrote:
This patch backports the ASSUME support that was rewritten in GCC 15.
Its slightly more
regressions. Pushed.
Andrew
From c40a4cc2d943d8572a62f21d3eb1d4171e51d5ac Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 8 May 2025 20:28:11 -0400
Subject: [PATCH] Remove negative ranges using trailing zero masks.
When there are trailing 0's in the bitmask, set_range_from_bitmask ()
perator for new operand combinations.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 6f375445ef09d5c97d5bcc0fcb6069612217963e Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 12 May 2025 11:41:37 -0400
Subject: [PATCH] Add dispatch for casts between intege
On 5/3/25 07:41, Richard Biener wrote:
On Sat, May 3, 2025 at 12:39 AM Andrew MacLeod wrote:
On trunk I'll eventually do something different.. but it will be more
invasive than I think is reasonable for a backport.
The problem in the PR is that there is a variable with a range and
On 5/3/25 07:41, Richard Biener wrote:
On Sat, May 3, 2025 at 12:39 AM Andrew MacLeod wrote:
On trunk I'll eventually do something different.. but it will be more
invasive than I think is reasonable for a backport.
The problem in the PR is that there is a variable with a range and
e:
On Fri, Mar 28, 2025 at 08:12:35AM +0100, Richard Biener wrote:
On Thu, Mar 27, 2025 at 8:14 PM Andrew MacLeod wrote:
This patch backports the ASSUME support that was rewritten in GCC 15.
Its slightly more complicated than the port to GCC 14 was in that a few
classes have been rewritten. I&#
On 5/3/25 07:41, Richard Biener wrote:
On Sat, May 3, 2025 at 12:39 AM Andrew MacLeod wrote:
On trunk I'll eventually do something different.. but it will be more
invasive than I think is reasonable for a backport.
The problem in the PR is that there is a variable with a range and
more failure.
bootstraps on -x86_64-pc-linux-gnu with no regressions.
If this is acceptable, I will push it to trunk, then also test/verify
for the GCC15 and 14(?) branches and check it in there.
Andrew
From bfe4b05074232fbba28f0c189762f46f3b042616 Mon Sep 17 00:00:00 2001
From: Andrew MacLe
OK by me.
Andrew
On 5/2/25 10:48, Jakub Jelinek wrote:
On Mon, Mar 31, 2025 at 11:30:20AM -0400, Andrew MacLeod wrote:
From 7116177599a3bb907d21fe642a4bdcb401e1263b Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 31 Mar 2025 11:18:22 -0400
Subject: [PATCH 2/2] Use the current cache
On 4/30/25 02:56, Richard Biener wrote:
On Wed, Apr 30, 2025 at 12:00 AM Andrew MacLeod wrote:
On 4/28/25 17:26, Andrew MacLeod wrote:
I have committed this patch to trunk after bootstrap/regression
testing again on trunk.
I'll get to gcc14/15 once I flush the current queue.
Andrew
On 3/28/25 05:25, Jakub Jelinek wrote:
On Fri, Mar 28, 2025 at 08:12:35AM +0100, Richard Biener wrote:
On Thu, Mar 27, 2025 at 8:14 PM Andrew MacLeod wrote:
This patch backports the ASSUME support that was rewritten in GCC 15.
Its slightly more complicated than the port to GCC 14 was in
On 4/28/25 17:26, Andrew MacLeod wrote:
I have committed this patch to trunk after bootstrap/regression
testing again on trunk.
I'll get to gcc14/15 once I flush the current queue.
Andrew
On 1/23/25 04:39, Richard Biener wrote:
On Wed, Jan 22, 2025 at 12:49 AM Andrew MacLeod
wrote:
On 4/28/25 17:26, Andrew MacLeod wrote:
I have committed this patch to trunk after bootstrap/regression
testing again on trunk.
I'll get to gcc14/15 once I flush the current queue.
Andrew
On 4/17/25 06:44, Richard Biener wrote:
On Wed, Apr 16, 2025 at 10:55 PM Andrew MacLeod
wrote:
On 3/28/25 10:36, Andrew MacLeod wrote:
On 3/28/25 03:19, Richard Biener wrote:
On Fri, Mar 28, 2025 at 12:28 AM Andrew MacLeod
wrote:
This patch fixes both 119471 and the remainder of 110992.
At issue is we do not recognize that if
"a * b != 0" , then neither "a"
etween LHS and OP2...
so I dont think it needs back porting at this point... although it would
be harmless to do so.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 1df77858cac29c71fc29bc6571e17d3b26d9d176 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: T
"nearest"
relations.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From bf2e0fb97183d46a84d283b795067d586d874556 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 10 Feb 2025 16:14:17 -0500
Subject: [PATCH 6/9] Add a Relation iterator to the relation ora
new dispatch patterns to range-ops as lhs_op1_relation had no
prange/prange/irange combination.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 6b88dab02640f1653bbab66f411da1d28ef1c1dc Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 22 Apr 2025 10:36:26 -0400
Subj
I have committed this patch to trunk after bootstrap/regression testing
again on trunk.
I'll get to gcc14/15 once I flush the current queue.
Andrew
On 4/17/25 06:44, Richard Biener wrote:
On Wed, Apr 16, 2025 at 10:55 PM Andrew MacLeod wrote:
This was a fun one! An actual bug, a
sions. Pushed.
Andrew
From f2e2d6202b1af94a22775706d9987f155f3f6760 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 31 Mar 2025 11:18:22 -0400
Subject: [PATCH 3/9] Use the current cache when creating inferred ranges.
Infer range processing was adjusted to allow a query to be specified,
but d
I have committed this patch to trunk after bootstrap/regression testing
again on trunk.
I'll get to gcc14/15 once I flush the current queue.
Andrew
On 1/23/25 04:39, Richard Biener wrote:
On Wed, Jan 22, 2025 at 12:49 AM Andrew MacLeod wrote:
This patch simply adds an op2_ran
On 4/16/25 16:55, Andrew MacLeod wrote:
I started at a 0.2% overall compilation increase (1.8% in VRP). In the
end, this patch is down to 0.6% in VRP, and only 0.08% overall, so
manageable for all the extra work.
Final version performance run...
VRP slowed down by 0.28%
Threading sped
On 4/16/25 17:28, Sam James wrote:
Andrew MacLeod writes:
* gcc.dg/tree-ssa/phi-opt-value-5.c : WIth the expanded ranges, CCP2
pass use to export:
Global Exported: d_3 = [irange] int [-INF, +INF] MASK 0xfffe
VALUE 0x1
and now
Global Exported: d_3 = [irange] int [-INF, -1][1
bitmask is explicitly
applied in some places and not others.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Finally. Is
this OK for trunk, or should I hold off a little bit?
Andrew
From 36e4b77565a1965d5bca15d196f32d5758393063 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon
On 4/11/25 10:27, Qing Zhao wrote:
On Apr 10, 2025, at 11:12, Martin Uecker wrote:
Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
On 2025-04-10 10:50, Andrew MacLeod wrote:
Its not clear to me exactly what is being asked, but I think the
suggestion is that
On 4/11/25 11:36, Qing Zhao wrote:
On Apr 11, 2025, at 10:42, Andrew MacLeod wrote:
On 4/11/25 10:27, Qing Zhao wrote:
On Apr 10, 2025, at 11:12, Martin Uecker wrote:
Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
On 2025-04-10 10:50, Andrew MacLeod wrote
On 4/11/25 10:05, Qing Zhao wrote:
On Apr 10, 2025, at 10:55, Siddhesh Poyarekar wrote:
On 2025-04-10 10:50, Andrew MacLeod wrote:
Its not clear to me exactly what is being asked, but I think the suggestion is
that pointer references are being replaced with a builtin function called
On 4/8/25 13:13, Siddhesh Poyarekar wrote:
On 2025-04-08 12:41, Qing Zhao wrote:
For the following small example:
[ counted_by_whole]$ cat t.c
#include
#include
struct annotated {
size_t count;
char other;
char array[] __attribute__((counted_by (count)));
};
#define MAX(A, B) (A
On 4/4/25 00:57, Jakub Jelinek wrote:
Hi!
As the first two testcases show, even with pointers IPA-VRP can optimize
return values from functions if they have singleton ranges into just the
exact value, so we need to virtually undo that for tail calls similarly
to integers and floats. The third
On 3/29/25 20:54, Jeff Law wrote:
On 3/4/25 2:10 AM, Jakub Jelinek wrote:
Hi!
On Fri, Nov 22, 2024 at 07:25:23PM -0500, Andrew MacLeod wrote:
I will shortly be submitting , and presumable committing, this
patch as
part of a series to improve VRP time for 117467..
So it may be in place
On 3/28/25 03:19, Richard Biener wrote:
On Fri, Mar 28, 2025 at 12:28 AM Andrew MacLeod wrote:
This patch fixes both 119471 and the remainder of 110992.
At issue is we do not recognize that if
"a * b != 0" , then neither "a" nor "b" can be zero.
This is
nches. OK for gcc13 and gcc14 branches?
Andrew
From 74edd2831affac005d2d5bf0170668188aa1a091 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 27 Mar 2025 13:44:00 -0400
Subject: [PATCH] If the LHS does not contain zero, neither do multiply
operands.
Given ~[0,0] = op1 * op2, range-ops sho
x-gnu with no regressions.
Andrew
From e39271c8c13b8fd5a49349000bfe8639c25cf470 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 27 Mar 2025 10:51:16 -0400
Subject: [PATCH 1/2] backport new assume implementation and cache.
---
gcc/Makefile.in| 1 +
gcc/gi
On 2/12/25 10:18, Jakub Jelinek wrote:
On Tue, Feb 11, 2025 at 05:20:49PM -0700, Jeff Law wrote:
So this is a fairly old regression, but with all the ranger work that's been
done, it's become easy to resolve.
The basic idea here is to use known relationships between two operands of a
SUB_OVER
The patch is mostly fine, although you probably want to change the
condition to check for a non-null stmt as well... ie
- if (subcode == MINUS_EXPR)
+ if (s && subcode == MINUS_EXPR)
because it looks like the stmt defaults to NULL and I suspect the
relation query will trap if S is null.
I
ndrew
From 83260dd7c035a2317a6a5083d70288c3fdaf6ab4 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 21 Jan 2025 11:49:12 -0500
Subject: [PATCH] infer non-zero for integral division RHS.
Adding op2_range for operator_div allows ranger to notice the divisor
is non-zero after execution.
00:00 2001
From: Andrew MacLeod
Date: Fri, 10 Jan 2025 13:33:01 -0500
Subject: [PATCH] Use relations when simplifying MIN and MAX.
Query for known relations between the operands, and pass that to
fold_range to help simplify MIN and MAX relations.
Make it type agnostic as well.
Adapt testcases from D
I have no issues. ok by me. I clearly need a proofreader :-)
Andrew
On 12/18/24 11:22, Andrew Carlotti wrote:
I think this counts as obvious, but I'll leave it a few days before committing
in case Andrew (or anyone else) disagrees.
gcc/ChangeLog:
* tree-assume.cc: Fix comment typos.
, Nov 25, 2024 at 07:55:46PM -0500, Andrew MacLeod wrote:
From 97bea858ff782dc5c80490bb48cbd3241ad3413c Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 25 Nov 2024 09:50:33 -0500
Subject: [PATCH 1/3] Do not calculate an entry range for invariant names.
If an SSA_NAME is invariant, do not
registering redundant inferred
ranges .
Bootstraps on build-x86_64-pc-linux-gnu with no regressions. OK?
Andrew
From 0aee6d112bf4dd9accd7aaa8b48a520a878dedf9 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 16 Nov 2024 08:29:30 -0500
Subject: [PATCH 2/3] Add a range query to inferred ranges
-gnu with no regressions. OK?
Andrew
From 9434efb95a481ea57db8d47919d05cbe17b8bcba Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 23 Nov 2024 14:05:54 -0500
Subject: [PATCH 3/3] Only add inferred ranges if they change the value.
Do not add an inferred range if it is already
n Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 25 Nov 2024 09:50:33 -0500
Subject: [PATCH 1/3] Do not calculate an entry range for invariant names.
If an SSA_NAME is invariant, do not calculate an on_entry value.
PR tree-optimization/117467
* gimple-range-cache.cc (ranger_cache::entry_
FYI,
I will shortly be submitting , and presumable committing, this patch
as part of a series to improve VRP time for 117467..
So it may be in place by the time you need it
Andrew
On 11/18/24 09:31, Andrew MacLeod wrote:
Attached is a pre-approved patch which adds a range_query to the
as a
bootstrap with your patches..
Andfrew
On 11/15/24 04:36, Jakub Jelinek wrote:
On Thu, Nov 14, 2024 at 06:25:49PM +0100, Jakub Jelinek wrote:
On Thu, Nov 14, 2024 at 10:05:05AM -0500, Andrew MacLeod wrote:
The inferred range mechanism is also initialized using cfun, so again
introducing a
Unfortunately that broke bootstrap.
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668554.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668699.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668700.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/66
On 11/15/24 04:36, Jakub Jelinek wrote:
On Thu, Nov 14, 2024 at 06:25:49PM +0100, Jakub Jelinek wrote:
On Thu, Nov 14, 2024 at 10:05:05AM -0500, Andrew MacLeod wrote:
The inferred range mechanism is also initialized using cfun, so again
introducing a use of cfun shouldnt be an issue
On 11/15/24 10:19, Jan Hubicka wrote:
I have seen this happen when the result of the intersection is an empty
set (one of the few comments in value-range.h actually describes an
undefined range as an "empty range"). I have only seen this happen when
the edge has been redirected to builtin_unre
On 11/14/24 05:26, Jakub Jelinek wrote:
Hi!
On top of the
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668554.html
patch which introduces the nonnull_if_nonzero attribute (because
C2Y is allowing NULL arguments on various calls like memcpy, memset,
strncpy etc. as long as the count
were made. I'll add a gcc14 version in
a few days to keep them in sync.. assuming we want that.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 137b26412f681bb1f8b3eb52b8f9efd79e6bda2a Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 5 Nov 2024 12:
On 11/5/24 03:37, Richard Biener wrote:
On Mon, Nov 4, 2024 at 4:52 PM Andrew MacLeod wrote:
Am 04.11.2024 um 16:32 schrieb Andrew MacLeod :
On 11/4/24 10:27, Richard Biener wrote:
Am 04.11.2024 um 16:01 schrieb Andrew MacLeod :
The invert() range operation is not supported on
On 11/4/24 10:00, Andrew MacLeod wrote:
The invert() range operation is not supported on values of either
VARYING or UNDEFINED. Primarily this is because UNDEFINED has no
type, which makes it impossible to perform invert() twice on a value,
and produce that same value. There were also
Am 04.11.2024 um 16:32 schrieb Andrew MacLeod :
On 11/4/24 10:27, Richard Biener wrote:
Am 04.11.2024 um 16:01 schrieb Andrew MacLeod :
The invert() range operation is not supported on values of either VARYING or
UNDEFINED. Primarily this is because UNDEFINED has no type, which
On 11/4/24 10:27, Richard Biener wrote:
Am 04.11.2024 um 16:01 schrieb Andrew MacLeod :
The invert() range operation is not supported on values of either VARYING or
UNDEFINED. Primarily this is because UNDEFINED has no type, which makes it
impossible to perform invert() twice on a value
hed.
Backports to GCC12 - 14 forthcoming.
Andrew
From 766075c47db5cc9d04463bfb2219b593bb4263ee Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 2 Nov 2024 10:26:24 -0400
Subject: [PATCH] Don't call invert on VARYING.
When all cases go to one label and resul in a VARYING value,
anger instance into the assume pass to access gori.
Other than that, they are pretty much in sync.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 34db084961e01172de81f7689f31fe30fb0a781a Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 31 Oct 2024 14:
Fresh extract and bootstrap, and I dont see those spurious failures I
mnetioned. And everything is good with the port of these patches too on
GCC14. so whenever seems reasonable.
Andrew
On 11/1/24 17:10, Andrew MacLeod wrote:
It eas an existing branch. I will get a scrtach branch and do
.. it should.
Andrew
On 11/1/24 17:05, Jakub Jelinek wrote:
On Fri, Nov 01, 2024 at 05:00:05PM -0400, Andrew MacLeod wrote:
no, I mean those are on the branch as is... at least when I extracted and
built stage 1 release gcc14 branch. UNless there was something wrong with my
build which I
, Jakub Jelinek wrote:
On Fri, Nov 01, 2024 at 04:00:17PM -0400, Andrew MacLeod wrote:
Maybe. The bitwise_and op1_range is very complicated.. I think its heavily
used, so I would be surprised if it didn't. bitwise or was doing nothing
at all and showed up immediately when I tried a few t
errors
Andrew
On 11/1/24 15:45, Jakub Jelinek wrote:
On Fri, Nov 01, 2024 at 03:25:37PM -0400, Andrew MacLeod wrote:
When experimenting with more complex flow for the assume pass, I found a
case where we were not as precise as we should be, but it was because
range-ops hadn't been taught
es to this
alogithm. This is certainly better than it was before anyway, and I
think it should always be correct.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 74710442f291902c19b84cebf7642b74ecec8965 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 28 Oct 202
3f708a4fc11fb6dfcf208ab218a5d9 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 31 Oct 2024 14:07:00 -0400
Subject: [PATCH 3/3] Update bitwise_or op_range.
If the LHS of a bitwise OR is positive, then so are both operands when
using op1_range or op2_range.
gcc/
* range-op.cc (operator_bit
.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 548a78d0e4c02f1e5d07c8812d4324fef581d14b Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 31 Oct 2024 15:44:15 -0400
Subject: [PATCH 1/3] Make fur_edge accessible.
Move the decl of fur_edge out of the source file
Fixed.
Bootstrapped on with no regressions. Pushed.
Andrew
On 10/28/24 10:25, Mikael Morin wrote:
Le 28/10/2024 à 14:38, Andrew MacLeod a écrit :
On 10/26/24 15:08, Mikael Morin wrote:
Hello,
Le 24/10/2024 à 14:53, Andrew MacLeod a écrit :
diff --git a/gcc/range-op-ptr.cc b/gcc/range-op
On 10/26/24 15:08, Mikael Morin wrote:
Hello,
Le 24/10/2024 à 14:53, Andrew MacLeod a écrit :
diff --git a/gcc/range-op-ptr.cc b/gcc/range-op-ptr.cc
index dd312a80366..ef2b2cce516 100644
--- a/gcc/range-op-ptr.cc
+++ b/gcc/range-op-ptr.cc
(...)
-void
-pointer_or_operator::wi_fold (irange
From: Andrew MacLeod
Date: Wed, 23 Oct 2024 10:59:13 -0400
Subject: [PATCH 4/4] Implement pointer_or_operator.
The class pointer_or is no longer used, and can be removed. Its
functionality was never moved to the new dispatch system.
This implements operator_bitwise_or::fold_range() for prange ope
::fold_range (prange &r, tree type, const prange &op1,
const prange &op2, relation_trio) const
This patch removes the unused clas to avoid confusion.
Bootstraps on x86_64-pc-linux-gnu with no regressions. pushed.
Andrew
From b6e18f91e75a28e16b4fa117d8275ab146acbb01 Mon Sep 17 00:00:00 2
removed them.
Bootstraps on x86_64-pc-linux-gnu with no regressions. pushed.
Andrew
From 4eb25bfee859a9161c0fd48215feaf1c307f2480 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 21 Oct 2024 16:47:32 -0400
Subject: [PATCH 1/4] Cleanup pointer_plus_operator.
The POINTER_PLUS operator
00:00:00 2001
From: Andrew MacLeod
Date: Mon, 21 Oct 2024 18:20:10 -0400
Subject: [PATCH 3/4] Remove pointer_and_operator.
This operator class predates the dispatch system, and is no longer used.
The functionality of wi_fold has been replaced by
operator_bitwise_and::fold_range with prange
On 10/18/24 12:48, Richard Sandiford wrote:
[+ranger folks, who I forgot to CC originally, sorry!]
This patch applies X /[ex] Y cmp Z -> X cmp (Y * Z) when Y * Z is
representable. The closest check for "is representable" on range
operations seemed to be overflow_free_p. However, that is desi
operators to see if similar dispatch
related issues were missed.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 774ad67fba458dd1beaa0f2d3e389aac46ca18b5 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 21 Oct 2024 16:32:00 -0400
Subject: [PATCH] Implement
That seems like a very reasonable place.
Andrew
On 10/18/24 08:11, Richard Biener wrote:
On Fri, 18 Oct 2024, Richard Sandiford wrote:
At the moment, ranger punts entirely on POLY_INT_CSTs. Numerical
ranges are a bit difficult, unless we do start modelling bounds on
the indeterminates. But
Good catch. Probably not a common case as usually we're already in
supported type contexts when we get around to check range_compatible..
I guess it wouldn't hurt to put a gcc_checking_assert in
range_compatible_p to confirm that they are supported types before
returning true.
Certainly ok.
On 9/26/24 10:03, Andrew MacLeod wrote:
On 9/26/24 03:07, Richard Biener wrote:
On Wed, 25 Sep 2024, Andrew MacLeod wrote:
I added a note to the PR before I saw this... we can just disable
transitives
when the graph gets too big... I don't think they are worth the
expense when
t
On 9/26/24 03:07, Richard Biener wrote:
On Wed, 25 Sep 2024, Andrew MacLeod wrote:
I added a note to the PR before I saw this... we can just disable transitives
when the graph gets too big... I don't think they are worth the expense when
things get large. I've attached that pa
On 9/25/24 06:51, Richard Biener wrote:
dom_oracle::register_transitives contains an unbound dominator walk
which for the testcase in PR114855 dominates the profile. I've also
noticed odd behavior in the case when set_one_relation returns NULL,
we'd then completely abort processing other relati
Absolutely ok.
Thanks!
Andrew
On 9/24/24 05:52, Richard Biener wrote:
For the testcase in PR114855 VRP takes 320.41s (23%) (after mitigating
backwards threader slowness). This is mostly due to the bitmap check
in equiv_oracle::find_equiv_dom. The following turns this bitmap
to tree view, tra
. Pushed.
Andrew
From 73356860e2e96cf3319de8f11eed74fd9ff80c65 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 6 Sep 2024 11:42:14 -0400
Subject: [PATCH 5/5] Before running fast VRP, make sure all edges have
EXECUTABLE set.
PR tree-optimization/116588
gcc/
* tree-vrp.cc
On 8/7/24 03:13, Richard Biener wrote:
On Tue, 6 Aug 2024, Andrew MacLeod wrote:
On 8/6/24 09:12, Richard Biener wrote:
Currently the forward threader isn't limited as to the search space
it explores and with it now using path-ranger for simplifying
conditions it runs into it became p
. Pushed.
Andrew
From 9e4da946c4263a4c89d5fc365b3c97ae244c5018 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 8 Aug 2024 16:37:28 -0400
Subject: [PATCH 2/2] Adjust rangers recomputation depth based on the number of
BBs.
As the number of block increase, recomputations can become more
expensive
nds in DOM.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 5ce3874b3c2fdd76f506005cb1171a732af7c807 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 8 Aug 2024 16:34:15 -0400
Subject: [PATCH 1/2] Limit equivalency processing in rangers cache.
When the numbe
On 8/6/24 17:27, Andrew Pinski wrote:
This is a set of 5 small cleanups for the ranger op table.
I noticed it after was pointed out an uninitialized warning
sometimes happens for it. We should use final classes a lot more,
even if it just used for documentation that you can't use it as a
base c
On 8/6/24 09:12, Richard Biener wrote:
Currently the forward threader isn't limited as to the search space
it explores and with it now using path-ranger for simplifying
conditions it runs into it became pretty slow for degenerate cases
like compiling insn-emit.cc for RISC-V esp. when compiling
On 7/23/24 15:18, Jeff Law wrote:
On 7/11/24 9:17 PM, HAO CHEN GUI wrote:
So why the test for real_isinf on the upper/lower bound? If op1 is
known to be a NaN, then why test the bounds at all? If a bounds
test is needed, why only test the upper bound?
IMHO, logical is if the op1 is a N
On 7/20/24 14:54, Jakub Jelinek wrote:
On Sat, Jul 20, 2024 at 12:57:39PM -0400, Andrew MacLeod wrote:
perhaps easier to just do
That works as well, sure.
Committed.
Andrew
commit 15571d2d54c705f22aced5e972cb463d0593aa3c
Author: Andrew MacLeod
Date: Sat Jul 20 12:49:39 2024 -0400
On 7/20/24 12:54, Jakub Jelinek wrote:
This isn't enough.
The bitint effective target just means that the target supports
at least some _BitInt precisions (the standard in that case mandates
support for at least bits in long long, so 64), but this testcase
uses _BitInt(129), for that one needs
On 7/20/24 12:00, Jakub Jelinek wrote:
On Sat, Jul 20, 2024 at 11:48:36AM -0400, Andrew MacLeod wrote:
On 7/20/24 01:58, Sam James wrote:
FAIL: gcc.dg/pr116003.c (test for excess errors)
Excess errors:
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/gcc/testsuite
mplemented: '_BitInt(128)' is not supported on this target
I think it needs dg-do compile { target bitint }.
Indeed, thanks. Pushed.
Andrew
commit 320c0d49dd5d7d96443b8ee2fde3cce533eaa761
Author: Andrew MacLeod
Date: Sat Jul 20 11:45:16 2024 -0400
Add bitint to options for tes
2001
From: Andrew MacLeod
Date: Fri, 19 Jul 2024 17:39:40 -0400
Subject: [PATCH] Check for SSA_NAME not in the IL yet.
Check for an SSA_NAME not in the CFG before trying to create an
equivalence record in the defintion block.
PR tree-optimization/116003
gcc/
* value-relation.cc (equiv_oracle
vs the GCC default of precision 1.
This patch addresses this oversight by returning a boolean range of the
type requested.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 8565cb2e22fd116e26aeb9d95030ee0e48d6e6c7 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date:
I have no issues with any of the range-op work in this patch series,
but I am unequipped to review the floating point aspects of any of the
patches.
We just need someone to signoff that this properly reflects those builtins.
Andrew
On 7/11/24 03:32, HAO CHEN GUI wrote:
Hi,
The builtin i
little more flexibility.
bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 5612541834c063dd4126fb059e59c5dc8d5f2f8e Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Wed, 26 Jun 2024 14:53:54 -0400
Subject: [PATCH] ssa_lazy_cache takes an optional bitmap_obstack
...@gmail.com/
since those are the ones which are detected right now.
Thanks,
Andrew
Thanks. Final version checked in:
Andrew
From 1ea95cc5e099d554764b82df8e972129e9d20885 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 17 Jun 2024 11:38:46 -0400
Subject: [PATCH] Add param for bb lim
On 6/25/24 09:44, Richard Biener wrote:
The following replaces conditional is_export_p calls as is_export_p
handles a NULL bb itself.
Bootstrap running on x86_64-unknown-linux-gnu, OK?
Absolutely.
Thanks
Andrew
Thanks,
Richard.
* gimple-range-gori.cc (gori_compute::may_recompute
On 6/24/24 22:35, Andrew Pinski wrote:
On Mon, Jun 24, 2024 at 7:20 PM Andrew MacLeod wrote:
// Fill ssa-cache R with any outgoing ranges on edge E, using QUERY.
bool gori_on_edge (class ssa_cache &r, edge e, range_query *query =
NULL);
This is what the fast_vrp routines uses.
1 - 100 of 1083 matches
Mail list logo
