On 9/18/23 02:53, Richard Biener wrote:
On Fri, Sep 15, 2023 at 4:45 PM Andrew MacLeod wrote:
Ive been looking at __builtin_unreachable () regressions. The
fundamental problem seems to be a lack of consistent expectation for
when we remove it earlier than the final pass of VRP.After
Ive been looking at __builtin_unreachable () regressions. The
fundamental problem seems to be a lack of consistent expectation for
when we remove it earlier than the final pass of VRP. After looking
through them, I think this provides a sensible approach.
Ranger is pretty good at
The original invocation of phi_analysis was only invoked if there was no
loop information available. I have found situations where phi analysis
enhances existing loop information, and as such this patch moves the phi
analysis block to before loop analysis is invoked (in case a query is
made
Somewhere along the way a large sequence of code in range_of_phi() ended
up with the same indentation of the preceeding loop.. this simply fixes it.
committed as obvious.
Andrew
From e35c3b5335879afb616c6ead0f41bf6c275ee941 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Wed, 13 Sep 2023
On 9/14/23 22:07, Jiufu Guo wrote:
undefined is a perfectly acceptable range. It can be used to
represent either values which has not been initialized, or more
frequently it identifies values that cannot occur due to
conflicting/unreachable code. VARYING means it can be any range,
UNDEFINED
On 9/12/23 21:42, Jiufu Guo wrote:
Hi,
Richard Biener writes:
On Thu, 7 Sep 2023, Jiufu Guo wrote:
Hi,
As discussed in PR111303:
For pattern "(X + C) / N": "div (plus@3 @0 INTEGER_CST@1) INTEGER_CST@2)",
Even if "X" has value-range and "X + C" does not overflow, "@3" may still
be
When range_of_stmt invokes prefill_name to evaluate unvisited
dependneciesit should not mark visited names as always_current.
when raner_cache::get_globaL_range() is invoked with the optional
"current_p" flag, it triggers additional functionality. This call is
meant to be from within ranger
On 9/1/23 02:40, Andrew Pinski wrote:
On Fri, Aug 11, 2023 at 8:08 AM Andrew MacLeod via Gcc-patches
wrote:
If this is only going to work with integers, you might want to check
that somewhere or switch to irange and int_range_max..
You can make it work with any kind (if you know op1
Rangers PHI analyzer currently only allows a single initializing value
to a group. This patch changes that to use an initialization range, which is
cumulative of all integer constants, plus a single symbolic value.
There were many times when there were multiple constants feeding into
PHIs and
Rangers Phi Analyzer was creating a group consisting of a single PHI,
which was problematic. It didn't really help anything, and it prevented
larger groups from including those PHIs and stopped some useful things
from happening.
Bootstrapped on x86_64-pc-linux-gnu with no regressions.
operator_addr was simply calling fold_range() to implement op1_range,
but it turns out op1_range needs to be more restrictive.
take for example from the PR :
_13 = >maj
when folding, getting a value of 0 for op1 means dso->maj resolved to a
value of [0,0].
On 8/11/23 05:51, Richard Biener wrote:
On Fri, Aug 11, 2023 at 11:17 AM 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, PR 108360, and PR 108397.
That was rewrite test_for_singularity to use range_op_handler
We're looking to add the unordered relations for floating point, and as
a result, we can no longer determine the relation between op1 and op2 in
a statement based purely on the LHS... we also need to know the type of
the operands on the RHS.
This patch adjusts op1_op2_relation to fit the same
We've been assuming x == x is always VREL_EQ in GORI, but this is not
always going to be true with floating point. Provide an API to return
the relation.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 430ff4f3e670e02185991190a5e2d90e61b39e07 Mon Sep 17 00:00:00
When you use a Value_Range, you need to set it's type first so it knows
whether it will be an irange or an frange or whatever.
There are a few set routines which take a type, and you shouldn't need
to set the type first in those cases.. For instance set_varying() takes
a type, so it seems
This is OK.
On 8/2/23 22:18, Jiufu Guo wrote:
Hi,
I would like to have a ping on this patch.
BR,
Jeff (Jiufu Guo)
Jiufu Guo writes:
Hi,
As discussed in previous reviews, adding overflow APIs to range-op
would be useful. Those APIs could help to check if overflow happens
when operating
The fold_using_range operand fetching mechanism has a variety of modes.
The "normal" mechanism simply invokes the current or supplied
range_query to satisfy fetching current range info for any ssa-names
used during the evalaution of the statement,
I also added support for fur_list which
When we first introduced range_query, we provided a base class for
constants rather than range queries. Then inherioted from that and
modified the value queries for a range-specific engine. . At the time,
we figured there would be other consumers of the value_query class.
When all the dust
This adds some tweaks to the ssa-range cache.
1) Adds a new merge_range which works like set_range, except if there
is already a value, the two values are merged via intersection and
stored. THis avpoids having to check if there is a value, load it,
intersect it then store that in the
This patch simply fixes the code up a little to remove potential warnings.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 7905c071c35070fff3397b1e24f140c128c08e64 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 10 Jul 2023 13:58:22 -0400
Subject: [PATCH
On 7/24/23 12:49, Richard Biener wrote:
Am 24.07.2023 um 16:40 schrieb Andrew MacLeod via Gcc-patches
:
Aldy has ported his irange reduction patch to GCC 13. It resolves this PR.
I have bootstrapped it and it passes regression tests.
Do we want to check it into the GCC 13 branch
Aldy has ported his irange reduction patch to GCC 13. It resolves this PR.
I have bootstrapped it and it passes regression tests.
Do we want to check it into the GCC 13 branch? The patch has all his
comments in it.
Andrew
From 777aa930b106fea2dd6ed9fe22b42a2717f1472d Mon Sep 17 00:00:00
On 7/17/23 09:45, Jiufu Guo wrote:
Should we decide we would like it in general, it wouldnt be hard to add to
irange. wi_fold() cuurently returns null, it could easily return a bool
indicating if an overflow happened, and wi_fold_in_parts and fold_range would
simply OR the results all
On 7/14/23 09:37, Richard Biener wrote:
On Fri, 14 Jul 2023, Aldy Hernandez wrote:
I don't know what you're trying to accomplish here, as I haven't been
following the PR, but adding all these helper functions to the ranger header
file seems wrong, especially since there's only one use of
This simply tweaks cmpute_operand_range a little so the recursion is a
tail call.
With this, the patchset produces a modest speedup of 0.2% in VRP and
0.4% in threading. It will also have a much smaller stack profile.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
now operand2 alone is resolved, and returned as the result. much
cleaner, and removes it from the recursion stack.
compute_operand_range() will decide if further evaluation is required.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From
now operand1 alone is resolved, and returned as the result. much
cleaner, and removes it from the recursion stack.
compute_operand_range() will decide if further evaluation is required.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From
This patch simplifies compute_operand1_and_operand2() such that it only
calls each routine one. This will simplify the next couple of patches.
It also allows moves the determination that op1 and op2 have an
interdependence to compute_operand_range().
Bootstraps on x86_64-pc-linux-gnu with
This is a set of 5 patches which cleans up GORIs compute_operand routines.
This is the mechanism GORI uses to calculate ranges from the bottom of
the routine back thru definitions in the block to the name that is
requested.
Currently, compute_operand_range() is called on a stmt, and it
On 6/27/23 12:24, Jan Hubicka wrote:
On 6/27/23 09:19, Jan Hubicka wrote:
Hi,
as shown in the testcase (which would eventually be useful for
optimizing std::vector's push_back), ipa-prop can use context dependent ranger
queries for better value range info.
Bootstrapped/regtested
On 6/27/23 09:19, Jan Hubicka wrote:
Hi,
as shown in the testcase (which would eventually be useful for
optimizing std::vector's push_back), ipa-prop can use context dependent ranger
queries for better value range info.
Bootstrapped/regtested x86_64-linux, OK?
Quick question.
When you call
When calculating ranges, GORI evaluates the chain of definitions until
it finds the desired name.
_4 = (short unsigned int) c.2_1;
_5 = _4 + 65535;
a_lsm.19_30 = a;
_49 = _4 + 65534;
_12 = _5 & _49;
_46 = _12 + 65535;
_48 = _12 & _46; <<--
if (_48 != 0)
When
With the expanded capabilities of range-op dispatch, floating point
complex objects can appear when folding, whic they couldn't before. In
the processing for extracting integers from complex int's, make sure it
actually is an integer.
Bootstraps on x86_64-pc-linux-gnu. Regtesting currently
Add a hybrid operator to choose between integer and pointer versions at
runtime.
This is the last use of the pointer table, so it is also removed.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From cd194f582c5be3cc91e025e304e2769f61ceb6b6 Mon Sep 17 00:00:00 2001
Add some missing overrides, and add the diaptch pattern for FII which
will be used for integer to float conversion.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 1bed4b49302e2fd7bf89426117331ae89ebdc90b Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 12
Add a hybrid operator to choose between integer and pointer versions at
runtime.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 80f402e832a2ce402ee1562030d5c67ebc276f7c Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 10 Jun 2023 16:33:17 -0400
Subject:
This provides range_op_handler with a default range_operator, so you no
longer need to check if it has a valid handler or not.
The valid check now turns into a "is this something other than a default
operator" check. IT means you can now simply invoke fold without
checking.. ie instead of
Add a hybrid operator to choose between integer and pointer versions at
runtime.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 8adb8b2fd5797706e9fbb353d52fda123545431d Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 10 Jun 2023 16:28:40 -0400
Subject:
This patch removes the hack introduced late last year for the
non-standard range-op support.
Instead of adding a a pointer to a range_operator in the header file,
and then setting the operator from another file via that pointer, the
table itself is extended and we provide new #defines to
Now that the unified table is the only one, remove it and simply use
range_op_table as the class instead of inheriting from it.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 5bb9d2acd1987f788a52a2be9bca10c47033020a Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 508645fd461ceb8b743837e24411df2e17bd3950 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 10 Jun 2023 16:09:58 -0400
Subject: [PATCH 06/17] Move operator_min to the unified range-op table.
* range-op-mixed.h
Lucky 13. WIth the unified table complete, it is no longer necessary to
specify a type when constructing a range_op_handler. This patch removes
that requirement.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 8934830333933349d41e62f9fd6a3d21ab71150c Mon Sep 17
This patch moves all the pointer specific code into a new file
range-op-ptr.cc
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From cb511d2209fa3a05801983a6965656734c1592c6 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 10 Jun 2023 16:17:51 -0400
Subject:
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From a71ee5c2d48691280f76a90e2838d968f45de0c8 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 10 Jun 2023 16:05:33 -0400
Subject: [PATCH 05/17] Move operator_bitwise_or to the unified range-op table.
*
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From f2166fc81194a3e4e9ef185a7404551b410bb752 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 10 Jun 2023 16:02:09 -0400
Subject: [PATCH 04/17] Move operator_bitwise_and to the unified range-op
table.
At this
Add a hybrid operator to choose between integer and pointer versions at
runtime.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 08f2e419b1e29f114857b3d817904abf3b4891be Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 10 Jun 2023 16:34:26 -0400
Subject:
This is the last of the integral operators, so also remove the integral
table.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 6585fa54e0f2a54f1a398b49b5b4b6a9cd6da4ea Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 10 Jun 2023 16:10:54 -0400
Subject:
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From cc18db2826c5449e84366644fa461816fa5f3f99 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 10 Jun 2023 16:01:05 -0400
Subject: [PATCH 03/17] Move operator_bitwise_xor to the unified range-op
table.
*
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 5bb4c53870db1331592a89119f41beee2b17d832 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 10 Jun 2023 15:59:43 -0400
Subject: [PATCH 02/17] Move operator_bitwise_not to the unified range-op
table.
*
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 438f8281ad2d821e09eaf5691d1b76b6f2f39b4c Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 10 Jun 2023 15:56:15 -0400
Subject: [PATCH 01/17] Move operator_addr_expr to the unified range-op table.
*
This patch set completes the range-op dispatch and unification rework.
The first 7 patches move the remainder of the integral table to the
unified table, and remove the integer table.
The 8th patch moves all the pointer specific code into a new file
range-op-ptr.cc
Patches 9-12 introduce a
This is the final shared integer/float opcode.
This patch also removes the floating point table and all references to it.
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From cc4eaf6f1e1958f920007d4cc7cafb635b5dda64 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:41:28 -0400
Subject: [PATCH 11/31] Unify PLUS_EXPR range operator
Move the declaration of the class to
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
Unify GT_EXPR the range operator
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From e5a4bb7c12d00926e0c7bbf0c77dd1be8f23a39a Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:32:25 -0400
Subject: [PATCH 06/31] Unify GT_EXPR range operator
Move
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From ee46a15733524103a9eda433df5dc44cdc055d73 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:39:54 -0400
Subject: [PATCH 10/31] Unify operator_cast range operator
Move the declaration of the class
Unify the LE_EXPR opcode.
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From 9de70a61ca83d50c35f73eafaaa7276d8f0ad211 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:30:56 -0400
Subject: [PATCH 05/31] Unify LE_EXPR range operator
Move the
Unify GE_EXPR the range operator
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From 364b936b8d82e86c73b2b964d4c8a2c16dcbedf8 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:33:33 -0400
Subject: [PATCH 07/31] Unify GE_EXPR range operator
Move
THis patch move the CONST operator into the mixed header. It also sets
REAL_CST to use this instead, as it has no op1_range routines.
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From 35a580f09eaceda5b0dd370b1e39fe05ba0a154f Mon Sep 17 00:00:00 2001
From: Andrew
This unifies the identity operation, which is used by SSA_NAME,
PAREN_EXPR, OBJ_TYPE_REF and REAL_CST.
REAL_CST is using it incorrectly, but preserves current functionality.
There will not be an SSA_NAME in the op1 position, so there is no point
in having an op1_range routine. That will be
Unify the EQ_EXPR opcode
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From 684959c5c058c2368e65c4c308a2cb3e3912782e Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:18:39 -0400
Subject: [PATCH 02/31] Unify EQ_EXPR range operator
Move the
Unify the LT_EXPR opcode
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From f7c1366a89edf1ffdd9c495cff544358f2ff395e Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:29:15 -0400
Subject: [PATCH 04/31] Unify LT_EXPR range operator
Move the
Unify the NE_EXPR opcode
Bootstrap on x86_64-pc-linux-gnu and pass all regressions. Pushed.
Andrew
From cb409a3b3367109944ff332899ec401dc60f678c Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 13:25:49 -0400
Subject: [PATCH 03/31] Unify NE_EXPR range operator
Move the
With all the operators unified under range_operator, I can now start
moving them into a unified table rather than have them spread around in
various type tables.
This patch creates a range_table for the unified operations, and has
checks to ensure that if the operator comes from the unified
before casting into an irange, make sure the type being cast into is
also supported by irange.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 6314d76cf87df92a0f7d0fdd48240283e667998a Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 9 Jun 2023 10:17:59
THis patch moves range_cast into the header file and makes it inlinable.
I also added a trap so that if you try to cast into an unsupported
type, it traps. It can't return a value of the correct type, so the
caller needs to be doing something else...
Such as using the new variant of
Range_operator and range_operator_float are 2 different classes, which
was not the original intent. This makes generalized dispatch to the
appropriate function more difficult. The distinction between what is a
float operator and what is an integral operator also blurs when some
methods have
This patch introduces a new dispatch mechanism for range_op_handler.
Instead of ad-hoc if then elses based on is_a and is_a,frange
*>, the discriminators in class vrange are used for each operand to
create a triplet, ie (III for "LHS = Irange, op1 = Irange, op2 =
Irange", and IFI for "Irange
Range_operator had a tree code added last release to facilitate bitmask
operations. This was intended to be a temporary change until we could
figure out something more strategic going forward.
This patch removes the tree_code and replaces it with a virtual routine
to perform the masking.
We currently do not have any floating point operators where operand 1 is
a different type than the LHS. When we eventually do there is a bug in
fold_range. If either operand is a known NAN, it returns a NAN of the
type of operand 1 instead of the result type.
This patch sets it to the correct
With the addition of floating point ranges, we did a lot of additional
class abstraction, then added a bunch more routines for floating point.
We didn't know how it would look in the end, so we just marched forward
and got it working.
Now that has settled down a bit, and before we go and add
On 5/25/23 03:03, Richard Biener wrote:
On Wed, May 24, 2023 at 11:21 PM Andrew MacLeod via Gcc-patches
There is about a 1.5% slowdown to VRP to invoke and utilize the
analyzer in all 3 passes of VRP. overall compile time is 0.06% slower.
Bootstraps on x86_64-pc-linux-gnu
By having an ssa_cache inherit from a range_query, and then providing a
range_of_expr routine which returns the current global value, we open up
the possibility of folding statements and doing other interesting things
with an ssa-cache.
In particular, you can now call fold_range() with an
This patch provide the framework for a gimple-range phi analyzer.
Currently, the primary purpose is to give better initial values for
members of a "phi group"
a PHI group is defined as a a group of PHI nodes whose arguments are all
either members of the same PHI group, or one of 2 other
This tweaks someof the fold_stmt routines and helpers.. in particular
the ones which you provide a vector of ranges to to satisfy any ssa-names.
Previously, once the vector was depleted, any remaining values were
picked up from the default get_global_range_query() query. It is useful
to be
I originally implemented the lazy ssa cache by inheriting from an
ssa_cache in protected mode and providing the required routines. This
makes it a little awkward to do various things, and they also become not
quite as interchangeable as I'd like. Making the routines virtual and
using proper
This implements suggestion 3) from the PR:
3) When we first set the intial value for _1947 and give it the
ALWAYS_CURRENT timestamp, we lose the context of when the initial
value was set. So even with 1) & 2) implemented, we are *still*
need to set a timestamp for it when its
This patch implements suggestion 1) from the PR:
1) We unconditionally write the new value calculated to the global
cache once the dependencies are resolved. This gives it a new
timestamp, and thus makes any other values which used it out of date
when they really aren't. This
Instead of defaulting to an initial value of VARYING before resolving
cycles, try folding the statement using available global values
instead. THis can give us a much better initial approximation,
especially in cases where there are no dependencies, ie
f_45 = 77
This implements suggestion
The original ssa_global_cache was intended to simply be the global cache
for ranger, but uses of it have since percolated such that it is really
just a range acche for a list of ssa-names. This patch renames it from
"ssa_global_cache" to "ssa_cache".
It also adds a method called "has_range"
Sparsely used ssa caches can benefit from using a bitmap to determine if
a name already has an entry. The path_query class was already managing
something like this internally, but there is benefit to making it
generally available.
ssa_lazy_cache inherits from ssa_cache and adds management of
This implements a sparse vector class for rangers cache and uses it bey
default except when the CFG is very small, in qhich case the original
full vectors are faster. It works like a normal vector cache (in fact
it inherits from it), but uses a sparse bitmap to determine whether a
vector
If either of the SSA names in a comparison do not have any equivalences
or relations, we can short-circuit the check slightly and be a bit faster.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From ee03aca78fb5739f4cd76cb30332f8aff2c5243a Mon Sep 17 00:00:00 2001
On 4/25/23 22:34, Jeff Law wrote:
On 4/24/23 07:51, Andrew MacLeod wrote:
Its not a real cache.. its merely a statement shortcut in dependency
analysis to avoid re-parsing statements every time we look at them
for dependency analysis
It is not suppose to be used for anything other
On 4/11/23 05:21, Richard Biener via Gcc-patches wrote:
On Wed, Apr 5, 2023 at 11:53 PM Jeff Law via Gcc-patches
wrote:
On 4/5/23 14:10, Andrew MacLeod via Gcc-patches wrote:
When a statement is first processed, any SSA_NAMEs that are dependencies
are cached for quick future access
We cant represent ADDR_EXPR in ranges, so when we are processing
builtin_unreachable() we should not be removing comparisons that utilize
ADDR_EXPR during the early phases, or we lose some important information.
It was just an oversight that we think its a comparison to a
representable
This removes specal casing UNDEFINED ranges when we are checking to see
if all arguments are the same and registering an equivalence.
previously if there were 2 different names, and one was undefined, we
ignored it an created an equivaence with the other one. as observed,
this is not a 2 way
On 4/18/23 04:52, Aldy Hernandez wrote:
[Andrew, we talked about this a few months ago. Just making sure we're
on the same page so I can push it. Also, a heads-up for Jakub.]
The == operator for ranges signifies that two ranges contain the same
thing, not that they are ultimately equal. So
On 4/13/23 09:56, Richard Biener wrote:
On Wed, Apr 12, 2023 at 10:55 PM Andrew MacLeod wrote:
On 4/12/23 07:01, Richard Biener wrote:
On Wed, Apr 12, 2023 at 12:59 PM Jakub Jelinek wrote:
Would be nice.
Though, I'm afraid it still wouldn't fix the PR101912 testcase, because
it has
On 4/12/23 07:01, Richard Biener wrote:
On Wed, Apr 12, 2023 at 12:59 PM Jakub Jelinek wrote:
Would be nice.
Though, I'm afraid it still wouldn't fix the PR101912 testcase, because
it has exactly what happens in this PR, undefined phi arg from the
pre-header and uses of the previous
On 4/12/23 04:20, Jakub Jelinek wrote:
On Tue, Apr 11, 2023 at 07:52:29PM -0400, Andrew MacLeod wrote:
This bootstraps on x86_64-pc-linux-gnu with that single regression, which I
have XFAILed for now. OK for trunk?
Yes.
Once Jakub verifies it actually fixes
the execution problem.
This is a carry over from PR 108139.
When we have a PHI node which has 2 arguments and one is undefined, we
create an equivalence between the LHS and the non-undefined PHI
argument. THis allows us to perform certain optimizations.
The problem is, when we are evaluating range-on-entry in the
On 4/11/23 04:21, Jakub Jelinek wrote:
Hi!
This patch was what I've tried first before the currently committed
PR109386 fix. Still, I think it is the right thing until we have proper
full set of VREL_* relations for NANs (though it would be really nice
if op1_op2_relation could be passed
When a statement is first processed, any SSA_NAMEs that are dependencies
are cached for quick future access.
if we ;later rewrite the statement (say propagate a constant into it),
its possible the ssa-name in this cache is no longer active. Normally
this is not a problem, but the changed to
Bah.. forgot that.. thanks :-)
Andrew
On 4/3/23 04:04, Martin Liška wrote:
gcc/ChangeLog:
* doc/invoke.texi: Document new param.
---
gcc/doc/invoke.texi | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index def2df4584b..c9482886c5a 100644
On 3/31/23 19:31, Hans-Peter Nilsson wrote:
Date: Fri, 31 Mar 2023 15:48:22 -0400
From: Andrew MacLeod via Gcc-patches
Reply-To: Andrew MacLeod
commit 55bf4f0d443e5adbacfcdbbebf4b2e0c74d1dcc8
Author: Andrew MacLeod
Date: Fri Mar 31 15:42:43 2023 -0400
Adjust testcases to not produce
On 3/31/23 15:59, Jeff Law wrote:
On 3/31/23 13:48, Andrew MacLeod wrote:
should we do something like this to tweak the testcases? or does
someone have something else in mind?
Go ahead and tweak the testcase. Unless you want to revamp it per
Jakub's suggestions.
not particularly :-)
should we do something like this to tweak the testcases? or does
someone have something else in mind?
Richi opened a PR for the STL failure (109350)
Andrew
On 3/31/23 13:37, Jakub Jelinek wrote:
On Fri, Mar 31, 2023 at 01:02:18PM -0400, Andrew MacLeod wrote:
I guess it figures the
1 - 100 of 687 matches
Mail list logo
