x86_64-linux-gnu with no new
regressions. Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2016-09-24 Kugan Vivekanandarajah
PR ipa/77677
* ipa-prop.c (ipa_compute_jump_functions_for_edge): Use
extract_range_from_unary_expr to convert value_range.
* tree
Hi Richard,
Thanks for the review.
On 23/09/16 17:19, Richard Biener wrote:
On Fri, Sep 23, 2016 at 12:24 AM, kugan
wrote:
Hi,
As Richard pointed out in PR77677, TREE_OVERFLOW is not cleared in IPA-VRP.
There are three places in which we set value_range:
1. When value ranges are obtained
are ongoing. Is this OK if there is no regression.
Thanks,
Kugan
gcc/ChangeLog:
2016-09-23 Kugan Vivekanandarajah
PR ipa/77677
* ipa-cp.c (propagate_vr_accross_jump_function):Drop TREE_OVERFLOW
from constant while creating value range.
gcc/testsuite/ChangeLog:
2016
Hi Richard,
Thanks for the review.
On 19/09/16 22:56, Richard Biener wrote:
On Sun, Sep 18, 2016 at 10:50 PM, kugan
wrote:
Hi Richard,
On 16/09/16 20:21, Richard Biener wrote:
On Fri, Sep 16, 2016 at 7:59 AM, kugan
wrote:
Hi Richard,
Thanks for the review.
On 14/09/16 22:04
Hi Richard,
Thanks for the review.
On 19/09/16 23:40, Richard Biener wrote:
On Sun, Sep 18, 2016 at 10:21 PM, kugan
wrote:
Hi Richard,
On 14/09/16 21:31, Richard Biener wrote:
On Fri, Sep 2, 2016 at 10:09 AM, Kugan Vivekanandarajah
wrote:
Hi Richard,
On 25 August 2016 at 22:24
Hi Richard,
On 16/09/16 20:21, Richard Biener wrote:
On Fri, Sep 16, 2016 at 7:59 AM, kugan
wrote:
Hi Richard,
Thanks for the review.
On 14/09/16 22:04, Richard Biener wrote:
On Tue, Aug 23, 2016 at 4:11 AM, Kugan Vivekanandarajah
wrote:
Hi,
On 19 August 2016 at 21:41, Richard Biener
Hi Richard,
On 14/09/16 21:31, Richard Biener wrote:
On Fri, Sep 2, 2016 at 10:09 AM, Kugan Vivekanandarajah
wrote:
Hi Richard,
On 25 August 2016 at 22:24, Richard Biener wrote:
On Thu, Aug 11, 2016 at 1:09 AM, kugan
wrote:
Hi,
On 10/08/16 20:28, Richard Biener wrote:
On Wed, Aug 10
016-09/msg00993.html
Thanks,
Kugan
Hi Richard,
Thanks for the review.
On 14/09/16 22:04, Richard Biener wrote:
On Tue, Aug 23, 2016 at 4:11 AM, Kugan Vivekanandarajah
wrote:
Hi,
On 19 August 2016 at 21:41, Richard Biener wrote:
On Tue, Aug 16, 2016 at 9:45 AM, kugan
wrote:
Hi Richard,
I am now having -ftree-evrp which
Hi Richard,
On 19/08/16 18:00, Richard Biener wrote:
On Fri, 19 Aug 2016, Kugan Vivekanandarajah wrote:
On 19 August 2016 at 12:09, Kugan Vivekanandarajah
wrote:
The testcase pr33738.C for warning fails with early-vrp patch. The
reason is, with early-vrp ccp2 is folding the comparison that
Hi Jeff,
On 13/09/16 08:11, Jeff Law wrote:
On 08/18/2016 08:09 PM, Kugan Vivekanandarajah wrote:
The testcase pr33738.C for warning fails with early-vrp patch. The
reason is, with early-vrp ccp2 is folding the comparison that used to
be folded in simplify_stmt_for_jump_threading. Since early
Hi Richard,
On 7 September 2016 at 19:35, Richard Biener wrote:
> On Wed, Sep 7, 2016 at 2:21 AM, Kugan Vivekanandarajah
> wrote:
>> Hi Richard,
>>
>> On 6 September 2016 at 19:08, Richard Biener
>> wrote:
>>> On Tue, Sep 6, 2016 at 2:24 AM, Kugan Vivek
Hi Bin,
On 07/09/16 17:52, Bin.Cheng wrote:
On Wed, Sep 7, 2016 at 1:10 AM, kugan wrote:
Hi Bin,
On 07/09/16 04:54, Bin Cheng wrote:
Hi,
LOOP_VINFO_NITERS is computed as LOOP_VINFO_NITERSM1 + 1, which could
overflow in loop niters' type. Vectorizer needs to generate more code
comp
Hi Richard,
On 6 September 2016 at 19:08, Richard Biener wrote:
> On Tue, Sep 6, 2016 at 2:24 AM, Kugan Vivekanandarajah
> wrote:
>> Hi Richard,
>>
>> On 5 September 2016 at 17:57, Richard Biener
>> wrote:
>>> On Mon, Sep 5, 2016 at 7:26 AM, Kugan V
tree cst_nitersm1 = LOOP_VINFO_NITERSM1 (loop_vinfo);
+
+ gcc_assert (TREE_CODE (cst_nitersm1) == INTEGER_CST);
+ if (wi::to_widest (cst_nitersm1) < cst_niters)
Shouldn't you have do the addition and comparison in the type of the
loop index instead of widest_int to see if tha
Hi Richard,
On 6 September 2016 at 19:57, Richard Biener wrote:
> On Tue, Sep 6, 2016 at 11:33 AM, Kugan Vivekanandarajah
> wrote:
>> Hi Richard,
>>
>> On 6 September 2016 at 19:08, Richard Biener
>> wrote:
>>> On Tue, Sep 6, 2016 at 2:24 AM, Kug
Hi Richard,
On 6 September 2016 at 19:08, Richard Biener wrote:
> On Tue, Sep 6, 2016 at 2:24 AM, Kugan Vivekanandarajah
> wrote:
>> Hi Richard,
>>
>> On 5 September 2016 at 17:57, Richard Biener
>> wrote:
>>> On Mon, Sep 5, 2016 at 7:26 AM, Kugan V
Hi Richard,
On 5 September 2016 at 17:57, Richard Biener wrote:
> On Mon, Sep 5, 2016 at 7:26 AM, Kugan Vivekanandarajah
> wrote:
>> Hi All,
>>
>> While looking at gcc source, I noticed that we are iterating over SSA
>> variable from 0 to num_ssa_names in some case
follow some consistent usage here.
It might be also good to gave a FOR_EACH_SSAVAR iterator as we do in
other case. Here is attempt to do this based on what is done in other
places. Bootstrapped and regression tested on X86_64-linux-gnu with no
new regressions. is this OK?
Thanks,
Kugan
gcc
Ping ?
Thanks,
Kugan
On 23 August 2016 at 12:11, Kugan Vivekanandarajah
wrote:
> Hi,
>
> On 19 August 2016 at 21:41, Richard Biener wrote:
>> On Tue, Aug 16, 2016 at 9:45 AM, kugan
>> wrote:
>>> Hi Richard,
>>>
>>> On 12/08/16 20:43, Richard Bie
Hi Richard,
On 25 August 2016 at 22:24, Richard Biener wrote:
> On Thu, Aug 11, 2016 at 1:09 AM, kugan
> wrote:
>> Hi,
>>
>>
>> On 10/08/16 20:28, Richard Biener wrote:
>>>
>>> On Wed, Aug 10, 2016 at 10:57 AM, Jakub Jelinek wrote:
>>&
structure with wide_int.
Thanks,
Kugan
ant here. The analysis phase should
> not determine
> anything if function is reachable non-locally.
Removed it.
>> +/* Info about value ranges. */
>> +
>> +struct GTY(()) ipa_vr
>> +{
>> + /* The data fields below are valid only if known is true. */
>
Hi,
On 19 August 2016 at 21:41, Richard Biener wrote:
> On Tue, Aug 16, 2016 at 9:45 AM, kugan
> wrote:
>> Hi Richard,
>>
>> On 12/08/16 20:43, Richard Biener wrote:
>>>
>>> On Wed, Aug 3, 2016 at 3:17 AM, kugan
>>> wrote:
>>
>>
&g
Ping?
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00872.html
Thanks,
Kugan
On 11 August 2016 at 09:09, kugan wrote:
> Hi,
>
>
> On 10/08/16 20:28, Richard Biener wrote:
>>
>> On Wed, Aug 10, 2016 at 10:57 AM, Jakub Jelinek wrote:
>>>
>>> On Wed, Aug
Ping?
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00987.html
Thanks,
Kugan
On 12 August 2016 at 13:19, kugan wrote:
> Hi Richard,
>
>
> On 11/08/16 20:04, Richard Biener wrote:
>>
>> On Thu, Aug 11, 2016 at 6:11 AM, kugan
>> wrote:
>
>
> [SNIP]
&g
On 19 August 2016 at 12:09, Kugan Vivekanandarajah
wrote:
> The testcase pr33738.C for warning fails with early-vrp patch. The
> reason is, with early-vrp ccp2 is folding the comparison that used to
> be folded in simplify_stmt_for_jump_threading. Since early-vrp does
> not perform ju
-ssa-ccp.c. We might also run
into some other similar issues in the future.
Bootstrapped and regression tested on x86_64-linux-gnu with no new regressions.
Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2016-08-18 Kugan Vivekanandarajah
* tree-ssa-ccp.c (ccp_fold_stmt): If the
Hi Richard,
On 17/08/16 08:20, kugan wrote:
Hi,
On 16/08/16 21:56, Richard Biener wrote:
On Tue, Aug 16, 2016 at 10:09 AM, kugan
wrote:
On 23/07/16 20:12, kugan wrote:
Hi Richard,
As we had value_range_type in tree-ssanames.h why not put value_range
there?
For IPA_VRP, we now need
Hi,
On 16/08/16 20:58, Richard Biener wrote:
On Tue, Aug 16, 2016 at 9:39 AM, kugan
wrote:
Hi,
as said the refactoring that would be appreciated is to split out the
update_value_range calls
from the worker functions so you can call the respective functions
from the DOM implementations.
That
Hi,
On 16/08/16 21:56, Richard Biener wrote:
On Tue, Aug 16, 2016 at 10:09 AM, kugan
wrote:
On 23/07/16 20:12, kugan wrote:
Hi Richard,
As we had value_range_type in tree-ssanames.h why not put value_range
there?
For IPA_VRP, we now need value_range used in ipa-prop.h (in ipa-vrp
On 23/07/16 20:12, kugan wrote:
Hi Richard,
As we had value_range_type in tree-ssanames.h why not put value_range there?
For IPA_VRP, we now need value_range used in ipa-prop.h (in ipa-vrp
patch). Based on this, attached patch now adds struct value_range to
tree-ssanames.h and fixes the
Hi Richard,
On 12/08/16 20:43, Richard Biener wrote:
On Wed, Aug 3, 2016 at 3:17 AM, kugan wrote:
[SNIP]
diff --git a/gcc/common.opt b/gcc/common.opt
index 8a292ed..7028cd4 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2482,6 +2482,10 @@ ftree-vrp
Common Report Var(flag_tree_vrp
is a patch that just splits out the update_value_range calls
visit_stmts. Bootstrapped and regression tested on x86_64-linux with no
new regressions.
I also verified few random fdump-tree-vrp1-details from stage2 to make
sure they are same.
Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog
Hi Richard,
On 11/08/16 20:04, Richard Biener wrote:
On Thu, Aug 11, 2016 at 6:11 AM, kugan
wrote:
[SNIP]
+two_valued_val_range_p (tree var, tree *a, tree *b)
+{
+ value_range *vr = get_value_range (var);
+ if ((vr->type != VR_RANGE
+ && vr->type !=
Hi Richard,
On 09/08/16 20:22, Richard Biener wrote:
On Tue, Aug 9, 2016 at 4:51 AM, Kugan Vivekanandarajah
wrote:
Hi Richard,
Thanks for the review.
On 29 April 2016 at 20:47, Richard Biener wrote:
On Sun, Apr 17, 2016 at 1:14 AM, kugan
wrote:
As explained in PR61839,
Following
Hi,
On 10/08/16 20:28, Richard Biener wrote:
On Wed, Aug 10, 2016 at 10:57 AM, Jakub Jelinek wrote:
On Wed, Aug 10, 2016 at 08:51:32AM +1000, kugan wrote:
I see it now. The problem is we are just looking at (-1) being in the ops
list for passing changed to rewrite_expr_tree in the case of
On 10/08/16 18:57, Jakub Jelinek wrote:
On Wed, Aug 10, 2016 at 08:51:32AM +1000, kugan wrote:
I see it now. The problem is we are just looking at (-1) being in the ops
list for passing changed to rewrite_expr_tree in the case of multiplication
by negate. If we have combined (-1), as in the
On 10/08/16 08:51, kugan wrote:
Hi Jakub,
On 10/08/16 07:55, Jakub Jelinek wrote:
On Wed, Aug 10, 2016 at 07:51:08AM +1000, kugan wrote:
On 10/08/16 07:46, Jakub Jelinek wrote:
On Wed, Aug 10, 2016 at 07:42:25AM +1000, kugan wrote:
There was no new regression while testing. I also moved
Hi Jakub,
On 10/08/16 07:55, Jakub Jelinek wrote:
On Wed, Aug 10, 2016 at 07:51:08AM +1000, kugan wrote:
On 10/08/16 07:46, Jakub Jelinek wrote:
On Wed, Aug 10, 2016 at 07:42:25AM +1000, kugan wrote:
There was no new regression while testing. I also moved the testcase from
gcc.dg/torture
Hi Andrew,
On 10/08/16 07:50, Andrew Pinski wrote:
On Tue, Aug 9, 2016 at 2:42 PM, kugan wrote:
On 09/08/16 23:43, kugan wrote:
Hi,
The test-case in PR72835 is failing with -O2 and passing with
-fno-tree-reassoc. It also passes with -O2 -fno-tree-vrp.
diff of .115t.dse2 and
Hi Jakub,
On 10/08/16 07:46, Jakub Jelinek wrote:
On Wed, Aug 10, 2016 at 07:42:25AM +1000, kugan wrote:
There was no new regression while testing. I also moved the testcase from
gcc.dg/torture/pr72835.c to gcc.dg/tree-ssa/pr72835.c. Is this OK for trunk?
This looks strange. The tree-ssa
On 09/08/16 23:43, kugan wrote:
Hi,
The test-case in PR72835 is failing with -O2 and passing with
-fno-tree-reassoc. It also passes with -O2 -fno-tree-vrp.
diff of .115t.dse2 and .116t.reassoc1 for the c++ testcase is as
follows, which looks OK.
+ unsigned int _16;
+ unsigned int _17
resets it. With this, the
testcases in TH PR is now working.
Bootstrap and regression testing for x86_64-linux-gnu is in progress. Is
this OK for trunk if there is no regression.
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-08-09 Kugan Vivekanandarajah
PR tree-optimization/72835
Hi Richard,
Thanks for the review.
On 29 April 2016 at 20:47, Richard Biener wrote:
> On Sun, Apr 17, 2016 at 1:14 AM, kugan
> wrote:
>> As explained in PR61839,
>>
>> Following difference results in extra instructions:
>> - c = b != 0 ? 486097858 : 972195717;
Hi Jakub,
Thanks for the review.
On 08/08/16 16:40, Jakub Jelinek wrote:
On Mon, Aug 08, 2016 at 01:36:51PM +1000, kugan wrote:
diff --git a/gcc/tree-ssanames.h b/gcc/tree-ssanames.h
index c81b1a1..6e34433 100644
--- a/gcc/tree-ssanames.h
+++ b/gcc/tree-ssanames.h
@@ -43,6 +43,9 @@ struct GTY
be used in IPA-VRP such that redundant
check for NULL can be eliminated.
Bootstrapped and regression tested on x86_64-linux-gnu. Is this OK for
trunk.
Thanks,
Kugan
gcc/ChangeLog:
2016-08-08 Kugan Vivekanandarajah
* tree-ssanames.c (set_ptr_nonnull): New
uot;loop with 4
iterations completely unrolled" 2
gcc.dg/tree-ssa/pr61743-1.c scan-tree-dump-times cunroll "loop with 8
iterations completely unrolled" 2
gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps
threaded: 3"
## Differences found:
# 1 differences in 1
-bitwise-cp patch ?
Bootstrap+test in progress on x86_64-unknown-linux-gnu.
OK for trunk ?
I think I approved a better patch from Kugan.
Sorry, I was waiting for the other patches to get approved. Since this
is needed for Prathamesh too, I will commit after testing this patch alone.
Thanks.
Kugan
this point), some of
the ranges can be pessimistic and can impact the estimation. Let me have
a look at this.
Thanks,
Kugan
in
https://patchwork.ozlabs.org/patch/648662/. I will commit that soon.
Thanks,
Kugan
Hi Richard,
Thanks for the review.
On 04/08/16 17:26, Richard Biener wrote:
On Thu, Aug 4, 2016 at 6:12 AM, kugan wrote:
Hi,
During IPA-VRP implementation, I realized that we don't support streaming
wide_int in LTO. Attached patch does this. Tested with IPA-VRP. Is this OK
for tru
Hi,
During IPA-VRP implementation, I realized that we don't support
streaming wide_int in LTO. Attached patch does this. Tested with
IPA-VRP. Is this OK for trunk if bootstrap and regression testing is fine.
Thanks,
Kugan
gcc/ChangeLog:
2016-08-04 Kugan Vivekanandarajah
Hi Richard,
Thanks for the review.
On 28/07/16 21:34, Richard Biener wrote:
On Thu, Jul 28, 2016 at 9:35 AM, kugan
wrote:
Hi Richard,
Thanks for the review.
It seems that in your pop_value_range you assume you only pop one
range per BB - while that's likely true at the moment it wi
Hi Richard,
Thanks for the review.
On 27/04/16 00:14, Richard Biener wrote:
On Fri, Apr 15, 2016 at 12:44 PM, kugan
wrote:
As pointed out by Richard, for signed & sign-bit-CST value range should be
[-INF, 0] range, not a [-INF, INF] range as happens now.
This patch fixes thi
keep a work-list of nodes to be re-evaluated till the lattice reach a
fixpoint. Is that OK with you?
If we are to do this, we should be able to reuse the callbacks
vrp_visit_phi_node and vrp_visit_stmt as it is.
Do you have a reference to your DOM based prototype?
Thanks,
Kugan
Btw, you d
You are right. The problem was with the order of checking tcc_compare
and calling get_ops. We ended up calling get_ops where we should not.
Bootstrap and regression testing is ongoing. Is this OK for trunk if no
regressions?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-07-27 Kugan Viveka
Hi Richard,
On 26/07/16 21:48, Richard Biener wrote:
On Tue, Jul 26, 2016 at 5:13 AM, kugan
wrote:
Hi,
For testcase in pr71994, type of bb conditional result and the type of the
PHI stmt are different (as om.0_1 is int and the first PHI argument is
_bool; PHI stmt uses a constant zero that
.
I would like to run this only for -O2 and above but for now I am using
this to test.
I have tested the last set of patch separately.
I will do more testing on this patch based on your feedback. Does this
look better?
Thanks,
Kugan
>From eefcd1c5444cf5d
uld check the type before replacing
the value (punt otherwise). Attached patch does that. Bootstrapped and
regression tested on x86_64-linux-gnu with no new regressions. Is this
OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-07-26 Kugan Vivekanandarajah
* gcc.dg/torture/p
operand_entry_pool.allocate ();
Sorry about the breakage. Since final_range_test_p allows either lhs or
rhs to be SSA_NAME (for the different cases it accepts), we should
indeed check for TREE_CODE being SSA_NAME. Unfortunately it didn't
trigger in my testing. Lets wait for the maintainers conformation.
Thanks for working on this,
Kugan
the patches in the series. Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2016-07-25 Kugan Vivekanandarajah
* tree-vrp.c (extract_range_basic): Check cfun->after_inlining before
folding call to __builtin_constant_p with parameters to false.
>From 4805ea975de0fd3b183
large number of ASSERT_EXPRs in the
default basic block. I am not sure if this would have any impact on
compile time/memory usage? If that is the case you might want to punt at
some length?
Thanks,
Kugan
had
to add other headers in few places due to the dependency. Are you OK
with this ?
Here is alternate patch where we keep struct value_range and enum
value_range_type to tree-vrp.h. May be it is a better approach? Please
let me know what is your preference.
Thanks,
Kugan
>F
Hi Richard,
Thanks for the review.
On 22/07/16 22:49, Richard Biener wrote:
On Fri, Jul 22, 2016 at 2:27 PM, kugan
wrote:
Hi,
Now that early vrp is moved as part of tree-vrp, there is only minimal
interface tree-vrp should expose for ipa-vrp. However, I have not found the
right place to
.
Thanks,
Kugan
>From 2e7d10923fefddafdeffc571e870508ac0ee193c Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah
Date: Tue, 21 Jun 2016 12:42:44 +1000
Subject: [PATCH 4/7] Refactor vrp
---
gcc/tree-ssanames.h | 5 -
gcc/tree-vrp.c |
Hi Richard,
Thanks for the review.
On 18/07/16 21:51, Richard Biener wrote:
On Fri, Jul 15, 2016 at 9:33 AM, kugan
wrote:
Hi Andrew,
On 15/07/16 17:28, Andrew Pinski wrote:
On Fri, Jul 15, 2016 at 12:08 AM, kugan
wrote:
Hi Andrew,
Why separate out early VRP from tree-vrp? Just a
OK for trunk.
Thanks,
Kugan
gcc/ChangeLog:
2016-07-20 Kugan Vivekanandarajah
* tree-vrp.c (set_value_range): Use vrp_equiv_obstack with
BITMAP_ALLOC.
(add_equivalence): Likewise.
(get_value_range): Allocate value range with vrp_value_range_p
Hi Martin,
On 19/07/16 18:22, kugan wrote:
Hi Martin,
Thanks for the review. I have revised the patch based on the review.
Please see the comments below.
Maybe it is better to separate value range and alignment summary
writing/reading to different functions. Here is another updated
Hi Martin,
Thanks for the review. I have revised the patch based on the review.
Please see the comments below.
On 15/07/16 22:23, Martin Jambor wrote:
Hi,
thanks for working on extending IPA-CP in this way. I do have a few
comments though:
On Fri, Jul 15, 2016 at 02:46:50PM +1000, kugan
Hi Andrew,
On 15/07/16 17:28, Andrew Pinski wrote:
On Fri, Jul 15, 2016 at 12:08 AM, kugan
wrote:
Hi Andrew,
Why separate out early VRP from tree-vrp? Just a little curious.
It is based on the discussion in
https://gcc.gnu.org/ml/gcc/2016-01/msg00069.html.
In summary, conclusion (based
pass.
I will give this a try.
Thanks,
Kugan
fo;
/* Value range attributes used for zero/sign extension elimination. */
struct GTY ((tag ("1"))) range_info_def *range_info;
} GTY ((desc ("%1.typed.type ?" \
"!POINTER_TYPE_P (TREE_TYPE ((tree)&%1)) : 2"))) info;
Thanks,
Kugan
Hi,
This patch teaches tree-vrp to use the VR set in params.
Thanks,
Kugan
gcc/ChangeLog:
2016-07-14 Kugan Vivekanandarajah
* tree-vrp.c (get_value_range): Teach PARM_DECL to use ipa-vrp
results.
>From 1900ff9210f1dd673f815b3a421c6ec1e02f6e05 Mon Sep 17
Hi,
This patch extends ipa-cp/ipa-prop infrastructure to handle propagation
of VR.
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-07-14 Kugan Vivekanandarajah
* gcc.dg/ipa/vrp1.c: New test.
* gcc.dg/ipa/vrp2.c: New test.
* gcc.dg/ipa/vrp3.c: New test
Hi,
This patch adds a very simple early vrp implementation. This visits the
basic blocks in the dominance order and set the Value Ranges (VR) for
SSA_NAMEs in the scope. Use this VR to discover more VRs. Restore the
old VR once the scope is exit.
Thanks,
Kugan
gcc/ChangeLog
Hi,
This patch re-factors common code in tree-vrp to be used in early vrp. I
am not entirely sure where I should place struct value_range. For now I
have placed in tree.h.
Thanks,
Kugan
2016-07-14 Kugan Vivekanandarajah
* tree-ssanames.h (enum value_range_type): Move
Hi,
This patch adds check for POINTER_TYPE_P before accessing
SSA_NAME_PTR_INFO in remap_ssa_name in gcc/tree-inline.c. This is not
related to IPA_VRP but was exposed by that.
Thanks,
Kugan
gcc/ChangeLog:
2016-07-14 Kugan Vivekanandarajah
* tree-inline.c
time being. That is, this patch is not intended for committing but
just to get the VRP tested.
Original patch which introduced this also talks about doing it earlier.
Thanks,
Kugan
>From 99f8e7884d582cfae2d7cb50ad59dab7ac6772fc Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah
D
otstrap and LTO bootstrap).
There are couple of testcase failures which I am looking into.
Any thoughts?
Thanks,
Kugan
gimple_assign.
Attached patch fixes the place where we remove the vector (-1).
Regression tested on x86-64-linux-gnu with no new regressions.
Regression testing on aarc64-linux-gnu is ongoing. Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-06-10 Kugan Vivekanandarajah
tested and bootstrapped on x86-64-linux-gnu with no new
regression. Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2016-06-05 Kugan Vivekanandarajah
PR middle-end/71408
* tree-ssa-reassoc.c (zero_one_operation): Fix NEGATE_EXPR operand for
propagate_op_to_s
o new regression. Is this OK
for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2016-06-04 Kugan Vivekanandarajah
PR middle-end/71281
* tree-ssa-reassoc.c (reassociate_bb): Set uid for negate stmt.
gcc/testsuite/ChangeLog:
2016-06-04 Kugan Vivekanandarajah
PR middle-end/
izing range tests a_5(D) -[128, 159] and
-[192, 223]
pr46309.c.116t.reassoc1: into (a_5(D) & 4294967231) + 4294967168 > 31
Bootstrapped and regression testing on x86-64-linux-gnu and
ppc64le-linux-gnu doesn't have any new regressions. Also did regression
testing arm variants whic
On 28/05/16 01:28, Kugan Vivekanandarajah wrote:
Hi Richard,
This fix insertion point of stmt_to_insert based on your comments. In
insert_stmt_before_use , I now use find_insert_point such that we
insert the stmt_to_insert after its operands are defined. This means
that we now have to insert
PRs
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-05-28 Kugan Vivekanandarajah
* gcc.dg/tree-ssa/pr71269.c: New test.
gcc/ChangeLog:
2016-05-28 Kugan Vivekanandarajah
* tree-ssa-reassoc.c (insert_stmt_before_use): Use find_insert_point so
that inserted stmt will not dominate
trunk if the testing is fine ?
Thanks,
Kugan
gcc/ChangeLog:
2016-05-28 Kugan Vivekanandarajah
* tree-ssa-reassoc.c (swap_ops_for_binary_stmt): Fix swap such that
all fields including stmt_to_insert are swapped.
gcc/testsuite/ChangeLog:
2016-05-28 Kugan Vivekanandarajah
* gcc.dg/tree-ssa
Hi Jakub,
On 26 May 2016 at 18:18, Jakub Jelinek wrote:
> On Thu, May 26, 2016 at 02:17:56PM +1000, Kugan Vivekanandarajah wrote:
>> --- a/gcc/tree-ssa-reassoc.c
>> +++ b/gcc/tree-ssa-reassoc.c
>> @@ -3767,8 +3767,10 @@ swap_ops_for_binary_stmt (vec ops,
>>
insert.
3. In rewrite_expr_tree_parallel, build_and_add_sum relies on either
of operand being inserted. If that is not the case, we have to insert
the stmt_to_insert before calling build_and_add_sum.
4. I also moved all the other stmt_to_insert insertion after the use
stmt are created.
Also regression t
reducing the test-case is
appreciated.
Regression testing on x86_64-linux-gnu and bootstrap didn’t find any new issues.
Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-05-24 Kugan Vivekanandarajah
* gfortran.dg/pr71252.f90: New test.
gcc/ChangeLog:
2016-05-24 Kugan
On 24 May 2016 at 18:36, Christophe Lyon wrote:
> On 24 May 2016 at 05:13, Kugan Vivekanandarajah
> wrote:
>> On 23 May 2016 at 21:35, Richard Biener wrote:
>>> On Sat, May 21, 2016 at 8:08 AM, Kugan Vivekanandarajah
>>> wrote:
>>>> On 20 May 2016 at
On 23 May 2016 at 21:35, Richard Biener wrote:
> On Sat, May 21, 2016 at 8:08 AM, Kugan Vivekanandarajah
> wrote:
>> On 20 May 2016 at 21:07, Richard Biener wrote:
>>> On Fri, May 20, 2016 at 1:51 AM, Kugan Vivekanandarajah
>>> wrote:
>>>> Hi Richard,
(optimized).
I will also try to gather test-cases based on testing/benchmarking.
Thanks,
Kugan
Hi Jeff,
On 20 May 2016 at 04:17, Jeff Law wrote:
> On 05/15/2016 06:45 PM, Kugan Vivekanandarajah wrote:
>>
>> Hi Richard,
>>
>> Now that stage1 is open, I would like to get the type promotion passes
>> reviewed again. I have tested the patches on aarch64, x86-6
On 20 May 2016 at 21:07, Richard Biener wrote:
> On Fri, May 20, 2016 at 1:51 AM, Kugan Vivekanandarajah
> wrote:
>> Hi Richard,
>>
>>> I think it should have the same rank as op or op + 1 which is the current
>>> behavior. Sth else doesn't work c
tested on x86-64-linux-gnu with no new regressions.
Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-05-20 Kugan Vivekanandarajah
* gcc.dg/tree-ssa/pr71179.c: New test.
gcc/ChangeLog:
2016-05-20 Kugan Vivekanandarajah
* tree-ssa-reassoc.c
erting the multiplication to
> rewrite_expr_tree time. For example by adding a ops->stmt_to_insert
> member.
>
Here is an implementation based on above. Bootstrap on x86-linux-gnu
is OK. regression testing is ongoing.
Thanks,
Kugan
gcc/ChangeLog:
2016-05-20 Kugan Vivekanandarajah
On 19 May 2016 at 18:55, Richard Biener wrote:
> On Thu, May 19, 2016 at 10:26 AM, Kugan
> wrote:
>> Hi,
>>
>>
>> On 19/05/16 18:21, Richard Biener wrote:
>>> On Thu, May 19, 2016 at 10:12 AM, Kugan Vivekanandarajah
>>> wrote:
>>>> Hi
Hi,
On 19/05/16 18:21, Richard Biener wrote:
> On Thu, May 19, 2016 at 10:12 AM, Kugan Vivekanandarajah
> wrote:
>> Hi Martin,
>>
>> Thanks for the fix. Just to elaborate (as mentioned in PR)
>>
>> At tree-ssa-reassoc.c:3897, we have:
>>
>> s
We could try Martin Liška's approach, We could also move _17 = c_7(D)
* 3; at tree-ssa-reassoc.c:3897 satisfy the gcc_assert. We could do
this based on the use count of _17.
This patch does this. I have no preferences. Any thoughts ?
Thanks,
Kugan
On 19 May 2016 at 18:04, Martin Lišk
201 - 300 of 551 matches
Mail list logo
