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 m
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
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. Each
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 F
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 mu
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_c
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 -04
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 ta
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 decla
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 decla
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 decla
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 c
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 M
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 t
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 decl
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
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
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
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 t
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
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
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.
* range-op-mix
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.
* range-op-m
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.
* range-op-m
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: [PATC
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: [PA
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 point
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.
* range-op-mix
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: [PATC
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 00:
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 (c
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
Da
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 decl
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: [PA
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 80f402e832a2ce402ee1562030d5c67ebc276f7c Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Sat, 10 Jun 2023 16:33:17 -0400
Subject: [PA
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 J
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
From:
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 un
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 them
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 togethe
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 200
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? 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 1
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 clie
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
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 allow
Applied slight tweak to the patch for the gcc12 branch.
botstrapped and no regressions on x86_64-pc-linux-gnu. Pushed.
Andrew
Forwarded Message
Subject: [COMMITTED] PR tree-optimization/106114 - Don't use gori
dependencies to optimize.
Date: Wed, 29 Jun 2022 21:40:44 -0
the relation oracle works on a purely symbolic basis. It assumes for
instance that x == x, along with everything in the equivalency set.
With the coming introduction of floating point ranges, we have
circumstances beyond the symbol relation which can affect the result.
If the range of X may c
Regardless of whether this is enough of an improvement for the PR, it
should be done.
Whenever a relation is registered with the oracle, it walks the
dominator tree trying to apply any transitives it can find.
FIrst, it should check whether the operands are already in any relation.
If neithe
This patch removes the recursion from range_from_dom.
It was walking the dominators looking for a range, and if a block was
encountered with outgoing ranges, a recursive call was made to resolve
the incoming dominator range and then calculate incoming edges.
This meant the edges could all be
The main time a dominator search in the cache fails to produce an
accurate range is when we have a "complicated" join node.
ie
bb4:
if (a > 200) goto bb5 ; else goto bb9
bb5
if (b > 400) goto bb6 ; else goto bb7
bb6
foo (b)
bb7
onward()
goto bb200;
bb9:
if (b > 200) goto bb6; e
This PR demonstrates a case where evaluating equivalencies can assist
VRP in refining values.
Previous revisions did not do this due to the expense of calculating or
checking for equivalencies everytime we process a use.
Earlier change to range_from_dom provided modes for the cache to query,
When only interger ranges were supported, we knew all gimple COND
statements were supported. this is no longer true with float support,
so gracefully do nothing when they are encountered.
You can choose to remove the "unsupported relational" range-ops if you
so wish. we shouldn't need those.
The path oracles killing_def () routine was removing an ssa-name from
each equivalence in the set. This was busy work that did not need to be
done.
when checking for an equivalence between A and B, the path oracle
requires that A be in B's set and B be in A's set. By setting the
equivalence
compute_ranges_in_block loops over all the imports, and checks to see if
each one is exported, then calculated an outgoing range for those that are.
The outer loop loops over the import list, whereas the export list is
usually smaller, and empty half the time. This means we were doing a
lot o
when evaluating a COND_EXPR, we need to evaluate both operands. With the
recent changes to floating point, we missed that we are accidentally
using the LHS range type for the operands.. that was fine when
everything was an irange... but no so any more.
This patch simply uses the right range ty
On 8/9/22 09:01, Richard Biener wrote:
This revisits how we compute imports later used for the ranger path
query during backwards threading. The compute_imports function
of the path solver ends up pulling the SSA def chain of regular
stmts without limit and since it starts with just the gori i
On 8/11/22 07:42, Richard Biener wrote:
This avoids going BBs outside of the path when adding def chains
to the set of imports. It also syncs the code with
range_def_chain::get_def_chain to not miss out on some imports
this function would identify.
Bootstrap / regtest pending on x86_64-unknow
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 b
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 poi
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
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
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
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 = &dso->maj
when folding, getting a value of 0 for op1 means dso->maj resolved to a
value of [0,0]. fold_using_range::range_o
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 evaluatin
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
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 x86_64-linux,
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 divide
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
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 912b5ac49677160aada7a2d86227
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 298952bcf05d298892e99adba1f4a
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
On 2/15/23 07:51, Tamar Christina wrote:
In any case, if you disagree I don’t' really see a way forward
aside from making this its own pattern running it before the
overwidening
pattern.
I think we should look to see if ranger can be persuaded to provide
the range of the 16-bit addition, even
This patch implements the suggestion that we have an alternative
ssa-cache which does not zero memory, and instead uses a bitmap to track
whether a value is currently set or not. It roughly mimics what
path_range_query was doing internally.
For sparsely used cases, expecially in large program
On 2/15/23 12:13, Tamar Christina wrote:
On 2/15/23 07:51, Tamar Christina wrote:
Thanks, lots of useful context there.
This second pattern replaces the above into:
_6 = _3 +w level_14(D);
_7 = _6 / 255;
_8 = (unsigned char) _7;
Thus removing the need to promote before the additi
On 2/15/23 12:50, Andrew MacLeod wrote:
On 2/15/23 12:13, Tamar Christina wrote:
On 2/15/23 07:51, Tamar Christina wrote:
void
operator_plus::wi_fold (irange &r, tree type,
const wide_int &lh_lb, const wide_int &lh_ub,
const wide_int &rh_lb, co
On 2/16/23 02:55, Richard Biener wrote:
On Wed, Feb 15, 2023 at 6:07 PM Andrew MacLeod via Gcc-patches
wrote:
This patch implements the suggestion that we have an alternative
ssa-cache which does not zero memory, and instead uses a bitmap to track
whether a value is currently set or not. It
On 2/22/23 08:06, Tamar Christina wrote:
Hi Andrew,
all the range-op integer code is in gcc/range-op.cc. As this is a basic
binary operation, you should be able to get away with implementing a
single routine, wi_fold () which adds 2 wide int bounds together and
returns a result. THis si th
On 2/15/23 13:42, Andrew MacLeod wrote:
On 2/15/23 12:50, Andrew MacLeod wrote:
On 2/15/23 12:13, Tamar Christina wrote:
On 2/15/23 07:51, Tamar Christina wrote:
void
operator_plus::wi_fold (irange &r, tree type,
const wide_int &lh_lb, const wide_int &lh_ub,
On 2/22/23 13:03, Tamar Christina wrote:
-Original Message-
From: Andrew MacLeod
Sent: Wednesday, February 22, 2023 4:42 PM
To: Tamar Christina ; Richard Biener
; Richard Sandiford
Cc: Tamar Christina via Gcc-patches ; nd
; j...@ventanamicro.com
Subject: Re: [PATCH 1/2]middle-end: Fix
On 2/23/23 03:36, Tamar Christina wrote:
Hi Andrew,
Oh yeah, and in case you haven't figured it out on your own, you'll
have to remove WIDEN_MULT_EXPR from the range-ops init table. This
non-standard mechanism only gets checked if there is no standard
range-op table entry for the tree code :
On 3/9/23 14:37, Tamar Christina wrote:
Cheers,
Thanks! I'll way for him to come back then 😊
Thanks,
Tamar
-Original Message-
From: Aldy Hernandez
Sent: Wednesday, March 8, 2023 8:57 AM
To: Tamar Christina
Cc: gcc-patches@gcc.gnu.org; nd ; amacl...@redhat.com
Subject: Re: [PATCH 2/4
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
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 cause
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 finally
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 i
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 abl
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 valu
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 ssa
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 with no
Ranger spends a lot of time tracking pointer type ssa_names which are
initialized to non-null, ie (a_2 = &foo). This turns out to be a waste
of effort.
Pointers can effectively have one of 3 values we care about: VARYING,
[0,0], or [1, +INF]. If an ssa_name is globally [0,0] or [1, +INF],
The user has overridden the function name "toupper" . Its marked as a
builtin function, presumably because it matches the name. In range
folding, we were assuming the LHS and the parameter were compatible
types... but they are not in this case..
I don't know if we should be marking such a th
On 8/10/21 3:45 AM, Richard Biener wrote:
On Mon, Aug 9, 2021 at 10:31 PM Andrew MacLeod via Gcc-patches
wrote:
The user has overridden the function name "toupper" . Its marked as a
builtin function, presumably because it matches the name. In range
folding, we were assuming the L
I originally implemented range tracing as a derived class so I wouldn't
mess-up the basic range routines in ranger. Having tracing enabled this
way had its advantages, but also had some disadvantages, such as
requiring a different class to be instantiated when we want to turn on
tracing.
Reg
This patch alters the options for --param=evrp-mode=.
It removes the option of tracing when in hybrid mode, and adds some
extra discrimination.
legacy/ranger/legacy-first/ranger-first are unchanged. the default is
still 'ranger'
The modifications are:
trace : enable range tracing in ra
And this final patch provides tracing in the GORI component.
This is what I used to find the ABS problem with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101938
The code sequence looked like:
:
a1_8 = -arg1_7(D);
_1 = ABS_EXPR ;
a2_10 = -_1;
if (a1_8 > a2_10)
goto
On 8/19/21 1:30 PM, Martin Sebor 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) that enable_ranger() dynamically
allocates memory.
The patch below adds c
1 - 100 of 687 matches
Mail list logo
