for when stage 1 re-opens.
>
Hi Charles,
+static void
+arm_emit_long_call_profile_insn ()
+{
+ rtx sym_ref = gen_rtx_SYMBOL_REF (Pmode, "__gnu_mcount_nc");
+ /* if movt/movw are not available, use a constant pool */
+ if (!arm_arch_thumb2)
Should this be !TARGET_USE_MOVT?
Thanks,
Kugan
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 this. I bootstrapped and regression tested for
x86-64-linux-gnu with no new regression. Is this OK for statege-1.
Thanks,
Kugan
gcc/Chang
ession tested for x86-64-linux-gnu with no new
regression. Is this OK for statege-1.
Thanks,
Kugan
gcc/ChangeLog:
2016-04-17 Kugan Vivekanandarajah
* tree-vrp.c (simplify_stmt_using_ranges): Convert CST BINOP COND_EXPR
to
COND_EXPR ? (CST BINOP 1) : (CST BINOP 0) when possible
Hi Richard,
On 19/04/16 22:11, Richard Biener wrote:
On Tue, Apr 19, 2016 at 1:36 PM, Richard Biener
wrote:
On Tue, Apr 19, 2016 at 1:35 PM, Richard Biener
wrote:
On Mon, Feb 29, 2016 at 11:53 AM, kugan
wrote:
Err. I think the way you implement that in reassoc is ad-hoc and not
related
uot;last").
Hi Richard,
Thanks. Here is an attempt which does this.
Regression tested and bootstrapped on x86-64-linux-gnu with no new
regressions.
Is this OK for trunk?
Thanks,
Kugan
2016-04-23 Kugan Vivekanandarajah
PR middle-end/40921
* gcc.dg/tree-ssa/pr4092
with complex or vector math.
Btw, does it handle associating
x + 3 * x + x
to
5 * x
?
Added this to the testcase and verified it is working.
Regression tested and bootstrapped on x86-64-linux-gnu with no new
regressions.
Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016
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 this. I bootstrapped and regression tested for
x8
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 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 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 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
016-09/msg00993.html
Thanks,
Kugan
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
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,
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,
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
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 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
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
errors)
Excess errors:
I didn't add it due to this. I will leave it to someone else.
Bootstrapped and regression tested the attached patch on
x86_64-linux-gnu with no new regressions.
Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2016-09-24 Kugan Vivekanandarajah
* tre
On 25/09/16 04:50, kugan wrote:
Hi,
In make_new_ssa_for_def (tree-reassoc.c) we should use gimple_get_lhs to
get lhs instead of gimple_assign_lhs as stmt can be builtins too.
Attached patch fixes this.
Testcase from PR (attached) seems to fail. I dont any fortran so I didnt
try fixing it
regressions. Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-10-03 Kugan Vivekanandarajah
* gcc.dg/pr68217.c: Adjust testcase as more cases are now handled in
evrp.
* gcc.dg/predict-1.c: Likewise.
* gcc.dg/predict-9.c: Likewise.
* gcc.dg
Hi Richard,
Thanks for the review.
On 04/10/16 19:56, Richard Biener wrote:
On Tue, 4 Oct 2016, kugan wrote:
Hi,
This patch improves Early VRP by folding stmts using vrp_fold_stmt as it is
done in ssa_propagate for VRP.
Why?
I thought it would be good for early vrp to simplify stmts
no new
regressions. Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-10-06 Kugan Vivekanandarajah
PR tree-optimization/77862
* gcc.dg/pr77862.c: New test.
gcc/ChangeLog:
2016-10-06 Kugan Vivekanandarajah
PR tree-optimization/77862
Hi,
Attached patch Register ranges for y in (x COND y) for Early VRP.
Bootstrapped and regression tested on x86_64-linux-gnu with no new
regressions. Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2016-10-06 Kugan Vivekanandarajah
* tree-vrp.c (evrp_dom_walker
beneficial as the testcase in the patch. (For this testcase to work
with Early VRP, we need the patch posted at
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00413.html)
Bootstrapped and regression tested on x86_64-linux-gnu with no new
regressions.
Thanks,
Kugan
gcc/testsuite/ChangeLog
Hi Richard,
Thanks for the review.
On 09/08/16 18:58, Richard Biener wrote:
On Tue, Aug 9, 2016 at 12:58 AM, kugan
wrote:
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
Hi,
In vrp_intersect_ranges_1, when !vr0->equiv, we are copying vr1->equiv
without allocating bitmap. This patch fixes this.
Bootstrap and regression testing are ongoing. Is this OK if no new
regressions?
Thanks,
Kugan
gcc/ChangeLog:
2016-10-09 Kugan Vivekanandarajah
Hi Richard,
Thanks for the review.
On 07/10/16 20:11, Richard Biener wrote:
On Fri, Oct 7, 2016 at 12:00 AM, kugan
wrote:
Hi,
In vrp intersect_ranges, Richard recently changed it to create integer value
ranges when it is integer singleton.
Maybe we should do the same when the other range is
Hi Richard,
On 10/10/16 20:13, Richard Biener wrote:
On Sat, Oct 8, 2016 at 9:38 PM, kugan wrote:
Hi Richard,
Thanks for the review.
On 07/10/16 20:11, Richard Biener wrote:
On Fri, Oct 7, 2016 at 12:00 AM, kugan
wrote:
Hi,
In vrp intersect_ranges, Richard recently changed it to create
Hi Richard,
On 12/10/16 00:14, Richard Biener wrote:
On Tue, Oct 11, 2016 at 2:57 AM, kugan
wrote:
Hi Richard,
Hi Richard,
On 10/10/16 20:13, Richard Biener wrote:
On Sat, Oct 8, 2016 at 9:38 PM, kugan
wrote:
Hi Richard,
Thanks for the review.
On 07/10/16 20:11, Richard Biener wrote
Hi Richard,
On 07/10/16 21:03, Richard Biener wrote:
On Fri, Oct 7, 2016 at 2:53 AM, kugan wrote:
Hi Richard,
Thanks for the review.
On 09/08/16 18:58, Richard Biener wrote:
On Tue, Aug 9, 2016 at 12:58 AM, kugan
wrote:
Hi Jakub,
Thanks for the review.
On 08/08/16 16:40, Jakub
Hi,
This patch uses the get/set_ptr_nonnull so that ipa-vrp also propagates
nonnull ranges for pinter.
Bootstrapped and regression tested this with other patched without any
new regressions on x86_64-linux-gnu.
Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2016-10-12 Kugan
Hi,
This patch uses get_ptr_nonnull in tree-vrp.
Bootstrapped and regression tested this with other patched without any
new regressions on x86_64-linux-gnu.
Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-10-12 Kugan Vivekanandarajah
* gcc.dg/ipa/vrp4.c: Adjust
Hi Richard,
On 12/10/16 23:24, Richard Biener wrote:
On Wed, Oct 12, 2016 at 8:56 AM, kugan
wrote:
Hi,
This patch uses get_ptr_nonnull in tree-vrp.
Bootstrapped and regression tested this with other patched without any
new regressions on x86_64-linux-gnu.
Is this OK for trunk?
Um
Hi Richard,
On 13/10/16 05:53, kugan wrote:
Hi Richard,
On 12/10/16 23:24, Richard Biener wrote:
On Wed, Oct 12, 2016 at 8:56 AM, kugan
wrote:
Hi,
This patch uses get_ptr_nonnull in tree-vrp.
Bootstrapped and regression tested this with other patched without any
new regressions on x86_64
t for now as you said, I
will document it.
When we start using pt.null from PTA analysis, we would also have to
take into account pt.anything/nonlocal/escaped.
Does that make sense?
Thanks,
Kugan
Hi Richard,
On 13/10/16 20:44, Richard Biener wrote:
On Thu, Oct 13, 2016 at 6:49 AM, kugan
wrote:
Hi Richard,
what does this try to do? Preserve info VRP computed across PTA?
I think we didn't yet sort out the nonlocal/escaped vs. null handling
properly
(or how PTA should h
,
Kugan
gcc/ChangeLog:
2016-10-12 Kugan Vivekanandarajah
* ipa-prop.c (ipa_compute_jump_functions_for_edge): Set value range
for pointer type too.
(ipcp_update_vr): set_ptr_nonnull for pointer.
gcc/testsuite/ChangeLog:
2016-10-12 Kugan Vivekanandarajah
= data->loop_info;
+ basic_block *bbs = get_loop_body (loop);
Is this worth being part of the cost model such that it can have
different defaults for different micro-architecture?
Thanks,
Kugan
Hi Richard,
On 14/10/16 23:53, Richard Biener wrote:
On Fri, Oct 14, 2016 at 1:12 AM, kugan
wrote:
Hi Richard,
On 13/10/16 20:44, Richard Biener wrote:
On Thu, Oct 13, 2016 at 6:49 AM, kugan
wrote:
Hi Richard,
what does this try to do? Preserve info VRP computed across PTA?
I
is. I am not sure if this can be wrong. Any
thoughts?
Attached patch bootstraps and regression testing didn't introduce any
new regressions.
Thanks,
Kugan
gcc/ChangeLog:
2016-10-19 Kugan Vivekanandarajah
* ipa-prop.c (ipa_compute_jump_functions_for_edge): Set
v
Hi Richard,
On 19/10/16 19:23, Richard Biener wrote:
On Wed, 19 Oct 2016, kugan wrote:
Hi,
While computing jump function value range for pointer, I am wondering if we
can assume that any tree with ADDR_EXPR will be nonnull.
That is, in cases like:
int arr[10];
foo (&arr[1]);
OR
st
ch passes bootstrap and regression testing on x86_64-linu-gnu.
Thanks,
Kugan
Honza
Richard.
Thanks,
Kugan
Richard.
Attached patch bootstraps and regression testing didn't introduce any new
regressions.
Thanks,
Kugan
gcc/ChangeLog:
2016-10-19 Kugan Vivekanandarajah
ested functionality, we
need to add noclone attribute. Here is a patch to do this.
Regression tested on aatch64-linux-gnu. Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-10-20 Kugan Vivekanandarajah
* gcc.target/aarch64/test_frame_common.h: Add noclone attr
Hi Richard,
On 20/10/16 18:41, Richard Biener wrote:
On Thu, 20 Oct 2016, kugan wrote:
On 20/10/16 01:26, Jan Hubicka wrote:
Would excluding weak symbols (I believe I can check DECL_WEAK for this)
good
enough. Or looking for acceptable subset would work?
I think we should add a symtab
Hi,
On 20/10/16 23:15, Jan Hubicka wrote:
Hi Richard,
On 20/10/16 18:41, Richard Biener wrote:
On Thu, 20 Oct 2016, kugan wrote:
On 20/10/16 01:26, Jan Hubicka wrote:
Would excluding weak symbols (I believe I can check DECL_WEAK for this)
good
enough. Or looking for acceptable subset
On 21/10/16 18:16, Richard Biener wrote:
On Fri, 21 Oct 2016, kugan wrote:
Hi,
On 20/10/16 23:15, Jan Hubicka wrote:
Hi Richard,
On 20/10/16 18:41, Richard Biener wrote:
On Thu, 20 Oct 2016, kugan wrote:
On 20/10/16 01:26, Jan Hubicka wrote:
Would excluding weak symbols (I believe
at we
need any special casing for NOP_EXPR here. bit_value_unop handles
already handles CASE_CONVERT.
Is this OK if no regressions in bootstrap and regression testing.
Thanks,
Kugan
gcc/ChangeLog:
2016-10-25 Kugan Vivekanandarajah
* ipa-cp.c (ipcp_bits_lattice::meet_with): R
handle other passes like constant propagation as
follow up based on the comments.
LTO bootstrapped and regression tested on x86_64-linux-gnu with no new
regressions.
Does this look OK?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-10-25 Kugan Vivekanandarajah
* gcc.dg/ipa/vrp7.c
imes too as reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78121. I have separated
this part of the patch with a testcase.
Please note that I am using fold_convert in the attached patch.
Bootstrapped and regression tested on x86_64-linux-gnu with no new
regressions. Is this OK for
Hi,
On 28/10/16 01:58, Jan Hubicka wrote:
gcc/testsuite/ChangeLog:
2016-10-25 Kugan Vivekanandarajah
* gcc.dg/ipa/vrp7.c: New test.
gcc/ChangeLog:
2016-10-25 Kugan Vivekanandarajah
* ipa-cp.c (ipa_get_jf_pass_through_result): Skip unary expressions
otstrap and LTO bootstrap).
There are couple of testcase failures which I am looking into.
Any thoughts?
Thanks,
Kugan
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
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
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 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 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 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
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
pass.
I will give this a try.
Thanks,
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
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 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
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 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
.
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 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
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
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
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
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
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
.
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
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
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
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
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
Hi,
On 24/11/16 19:48, Richard Biener wrote:
On Wed, Nov 23, 2016 at 4:33 PM, Martin Jambor wrote:
Hi,
On Fri, Nov 18, 2016 at 12:38:18PM +1100, kugan wrote:
Hi,
I was relying on ipa_get_callee_param_type to get type of parameter and then
convert arguments to this type while computing jump
Hi Martin,
On 07/12/16 21:08, Martin Jambor wrote:
Hello Kugan,
sorry, I have lost track of this patch and re-discovered it only now.
On Mon, Nov 28, 2016 at 04:25:00PM +1100, kugan wrote:
Hi,
On 24/11/16 19:48, Richard Biener wrote:
On Wed, Nov 23, 2016 at 4:33 PM, Martin Jambor wrote
Hi,
in propagate_vr_accross_jump_function, drop_tree_overflow should be
after fold_convert. Attached patch changes this.
Bootstrapped and regression tested on x86_64-linux-gnu with no new
regressions. Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-12-09 Kugan
Hi Martin,
On 07/12/16 21:08, Martin Jambor wrote:
Hello Kugan,
sorry, I have lost track of this patch and re-discovered it only now.
On Mon, Nov 28, 2016 at 04:25:00PM +1100, kugan wrote:
Hi,
On 24/11/16 19:48, Richard Biener wrote:
On Wed, Nov 23, 2016 at 4:33 PM, Martin Jambor wrote
the VR for arguments to param_type.
In propagate_vr_accross_jump_function also, we are doing the conversion.
Thanks,
Kugan
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 2ec671f..9853467 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1846,11 +1846,11 @@ propagate_bits_accross_jump_function (cgraph_edge
e case where a powi
is detected in addition to a negation. Please also add a testcase that catches
(-y) * x * (-z).
Added this to the testcase.
Does this look better now?
Thanks,
Kugan
2016-04-23 Kugan Vivekanandarajah
PR middle-end/40921
* gcc.dg/tree-ssa/pr40921.c: N
ific multiplication
scan as you wanted.
Does this now look better?
Thanks,
Kugan
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr63586-2.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr63586-2.c
index e69de29..0dcfe32 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr63586-2.c
+++ b/gcc/testsuite/gcc.dg/
testing on
x86-64-linux-gnu.
Does this look Ok for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-05-05 Kugan Vivekanandarajah
PR middle-end/70841
* gcc.dg/tree-ssa/pr70841.c: New test.
gcc/ChangeLog:
2016-05-05 Kugan Vivekanandarajah
PR middle-end/70841
Hi Martin,
>
> I see various ICE after your commit r236356:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71170
Sorry for the breakage. Looking into it.
Thanks,
Kugan
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
.
Thanks,
Kugan
This patch adds support for new tree code SEXT_EXPR.
gcc/ChangeLog:
2015-09-07 Kugan Vivekanandarajah
* cfgexpand.c (expand_debug_expr): Handle SEXT_EXPR.
* expr.c (expand_expr_real_2): Likewise.
* fold-const.c (int_const_binop_1): Likewise.
* tree-cfg.c
.
gcc/ChangeLog:
2015-09-07 Kugan Vivekanandarajah
* Makefile.in: Add gimple-ssa-type-promote.o.
* common.opt: New option -ftree-type-promote.
* doc/invoke.texi: Document -ftree-type-promote.
* gimple-ssa-type-promote.c: New file.
* passes.def: Define new
This patch tree-vrp handling and optimization for ZEXT_EXPR.
gcc/ChangeLog:
2015-09-07 Kugan Vivekanandarajah
* tree-vrp.c (extract_range_from_binary_expr_1): Handle SEXT_EXPR.
(simplify_bit_ops_using_ranges): Likewise.
(simplify_stmt_using_ranges): Likewise.
>F
!= l5)
abort ();
return 0;
}
gcc/ChangeLog:
2015-09-07 Kugan Vivekanandarajah
* expr.c (expand_expr_real_1): Set proper SUNREG_PROMOTED_MODE for
SSA_NAME that was set by GIMPLE_CALL and assigned to another
SSA_NAME of same type.
Allow GIMPLE_DEBUG with values in promoted register.
gcc/ChangeLog:
2015-09-07 Kugan Vivekanandarajah
* expr.c (expand_expr_real_1): Set proper SUNREG_PROMOTED_MODE for
SSA_NAME that was set by GIMPLE_CALL and assigned to another
SSA_NAME of same type.
>F
Allow GIMPLE_DEBUG with values in promoted register.
gcc/ChangeLog:
2015-09-07 Kugan Vivekanandarajah
* expr.c (expand_expr_real_1): Set proper SUBREG_PROMOTED_MODE for
SSA_NAME that was set by GIMPLE_CALL and assigned to another
SSA_NAME of same type.
>F
the same PROMOTE_MODE which is used in aarch64 port. For
the time being, I am using patch
0006-temporary-workaround-for-bootstrap-failure-due-to-co.patch as a
workaround .
>From 6a10c856374446ab6d18eb9ce840c08cac440a61 Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah
Date: Tue, 1 Sep 2015 08
gcc/testsuite/ChangeLog:
2015-09-07 Kugan Vivekanandarajah
* gcc.target/arm/mla-2.c: Scan for wider mode operation.
* gcc.target/arm/wmul-1.c: Likewise.
* gcc.target/arm/wmul-2.c: Likewise.
* gcc.target/arm/wmul-3.c: Likewise.
* gcc.target/arm/wmul-9
On 07/09/15 20:46, Wilco Dijkstra wrote:
>> Kugan wrote:
>> 2. vector-compare-1.c from c-c++-common/torture fails to assemble with
>> -O3 -g Error: unaligned opcodes detected in executable segment. It works
>> fine if I remove the -g. I am looking into it and needs to be
On 07/09/15 23:10, Michael Matz wrote:
> Hi,
>
> On Mon, 7 Sep 2015, Kugan wrote:
>
>> For the following testcase (compiling with -O1; -O2 works fine), we have
>> a stmt with stm_code SSA_NAME (_7 = _ 6) and for which _6 is defined by
>> a GIMPLE_CALL. In this c
Thanks for the review.
On 07/09/15 23:20, Michael Matz wrote:
> Hi,
>
> On Mon, 7 Sep 2015, Kugan wrote:
>
>> Allow GIMPLE_DEBUG with values in promoted register.
>
> Patch does much more.
>
Oops sorry. Copy and paste mistake.
gcc/ChangeLog:
2015-0
201 - 300 of 593 matches
Mail list logo
