On 25/06/14 17:50, Jakub Jelinek wrote:
> On Wed, Jun 25, 2014 at 05:21:08PM +1000, Kugan wrote:
>> The problem with SRP_POINTER 0, SRP_SIGNED 1, SRP_UNSIGNED 2,
>> SRP_SIGNED_AND_UNSIGNED 3 (as I understand) is that, it will be
>> incompatible with TYPE_UNSIGNED
On 26/06/14 11:06, Kugan wrote:
> On 25/06/14 17:50, Jakub Jelinek wrote:
>> On Wed, Jun 25, 2014 at 05:21:08PM +1000, Kugan wrote:
>>> The problem with SRP_POINTER 0, SRP_SIGNED 1, SRP_UNSIGNED 2,
>>> SRP_SIGNED_AND_UNSIGNED 3 (as I understand) is that, it wi
On 26/06/14 15:50, Jakub Jelinek wrote:
> On Thu, Jun 26, 2014 at 11:06:26AM +1000, Kugan wrote:
>>>> Since our aim is to perform single bit checks, why don’t we just use
>>>> this representation internally (i.e. _rtx->unchanging = 1 if SRP_SIGNED
>>>>
On 26/06/14 20:12, Jakub Jelinek wrote:
> On Thu, Jun 26, 2014 at 07:41:22PM +1000, Kugan wrote:
>> 2014-06-26 Kugan Vivekanandarajah
>>
>> * calls.c (precompute_arguments): Use new SUBREG_PROMOTED_SET
>> instead of SUBREG_PROMOTED_UNSIGNED_SET
>
> M
On 26/06/14 20:25, Andreas Schwab wrote:
> Kugan writes:
>
>> @@ -5203,24 +5203,25 @@ store_expr (tree exp, rtx target, int call_param_p,
>> bool nontemporal)
>> == TYPE_PRECISION (TREE_TYPE (exp)))
>> {
>>
On 01/07/14 18:21, Kugan wrote:
> On 26/06/14 20:12, Jakub Jelinek wrote:
>> On Thu, Jun 26, 2014 at 07:41:22PM +1000, Kugan wrote:
>>> 2014-06-26 Kugan Vivekanandarajah
>>>
>>> * calls.c (precompute_arguments): Use new SUBREG_PROMOTED_SET
>>>
AX <= TYPE_MAX) when
checking to be sure that this is not the overflowing case. Attached
patch changes this.
I have bootstrapped on x86_64-unknown-linux-gnu and regression tested
for x86_64-unknown-linux-gnu, arm-none-linux-gnueabi (using qemu),
aarch64_be-none-elf (Foundation model), aarch64-none
Ping ?
Thanks,
Kugan
On 27/04/15 09:07, Kugan wrote:
>
>> While I support your goals, I think your approach needs some refinement.
>>
>> In particular, we DO NOT want another function that starts looking at
>> constant values and tries to decide, on a case by case bas
ping?
Thanks,
Kugan
On 15/04/15 17:53, Kugan wrote:
> As mentioned in PR65768, ARM gcc generates suboptimal code for constant
> Uses in loop. Part of the reason is cprop is undoing what loop invariant
> code motion did.
>
> Zhenqiang posted a patch at to fix this based on rtx
/gcc/fold-const.c:8431:7: note: in expansion of macro
'LOGICAL_OP_NON_SHORT_CIRCUIT'
if (LOGICAL_OP_NON_SHORT_CIRCUIT
Regression testing for arm-none-linux-gnueab is ongoing.
Is this OK for trunk if no regression?
Thanks,
Kugan
gcc/ChangeLog:
2015-05-15 Kugan Vivekanandar
Sorry, this is not the right fix. Looking at it.
Thanks,
Kugan
On 15/05/15 16:41, Kugan wrote:
> Hi Richard,
>
> r223090 seem to miss a parenthesis and seem to be causing:
>
> from ../../widen/gcc/fold-const.c:46:
> ../../widen/gcc/fold-const.c: In f
On 07/05/15 17:24, James Greenhalgh wrote:
> On Wed, May 06, 2015 at 03:12:33AM +0100, Kugan wrote:
>>>> gcc/ChangeLog:
>>>>
>>>> 2015-04-24 Kugan Vivekanandarajah
>>>>Jim Wilson
>>>>
>>>>* config/arm/aar
On 29/05/15 07:31, Jeff Law wrote:
> On 05/13/2015 11:46 PM, Kugan wrote:
>> ping?
>>
>> Thanks,
>> Kugan
>>
>> On 15/04/15 17:53, Kugan wrote:
>>> As mentioned in PR65768, ARM gcc generates suboptimal code for constant
>>> Uses in loop. P
On 30/05/15 14:54, Jeff Law wrote:
> On 05/29/2015 12:32 AM, Kugan wrote:
>>>>>
>>>>> PR target/65768
>>>>> * cprop.c (try_replace_reg): Check cost of constants before
>>>>> propagating.
>>> I should have also
int _1;
int _2;
short int _5;
:
_1 = (int) p1_4(D);
_5 = (short int) _1;
__asm__("" : "=r" p1_6 : "0" _5);
_2 = (int) p1_6;
return;
}
Thanks a lot for your time,
Kugan
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index b59b5d9..16b2df1 100644
--- a/gcc/M
of the neon-reload-class.s.
1. neon-reload-class_before_arm_split.s - before r223235
2. neon-reload-class_before_cprop.s - before r224048
3. neon-reload-class_new.s - after 224048
Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2015-06-05 Kugan Vivekanandarajah
* gcc.tar
On 15/04/15 21:18, Richard Biener wrote:
> On Wed, Apr 15, 2015 at 11:05 AM, Steven Bosscher
> wrote:
>> On Wed, Apr 15, 2015 at 9:53 AM, Kugan wrote:
>>> 2015-04-15 Kugan Vivekanandarajah < >
>>> Zhenqiang Chen <>
>>>
code so I'd certainly
>> prefer to see one of the other approaches which have been discussed.
>
> I see your point. Let me work on this based on your suggestions above.
Hi James,
Here is an attempt along this line. Is this what you have in mind?
Trying to keep functionality as
On 19/01/15 22:28, Richard Biener wrote:
> On Sat, 17 Jan 2015, Kugan wrote:
>
>>
>> This patch propagate value range wrapps attribute and save this to
>> SSA_NAME.
>
> diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
> index 9b7695d..832c35d 100644
> --- a/g
On 17/01/15 13:06, Kugan wrote:
> Freeing a spare-bit to store wrapped attribute by going back to
> representing VR_ANTI_RANGE as [max + 1, min - 1] in SSA_NAME.
>
Now that stage-1 is open, rebased it and regression tested on
x86-64-none-linux-gnu with no new regressions.
Is this OK
On 17/01/15 13:11, Kugan wrote:
>
> Re-enable zero/sign extension elimination using value range that
> includes wrapped attribute.
>
Now that stage-1 is open, rebased it and regression tested on
x86-64-none-linux-gnu with no new regressions.
Is this OK for trunk?
Thanks,
Kugan
g
On 23/04/15 09:48, H.J. Lu wrote:
> On Wed, Apr 22, 2015 at 3:15 PM, Kugan
> wrote:
>> On 17/01/15 13:11, Kugan wrote:
>>>
>>> Re-enable zero/sign extension elimination using value range that
>>> includes wrapped attribute.
>>>
>>
>> N
On 21/04/15 06:22, James Greenhalgh wrote:
> On Fri, Apr 17, 2015 at 12:19:14PM +0100, Kugan wrote:
>>>> My point is that adding your patch while keeping the logic at the top
>>>> which claims to catch ALL vector operations makes for less readable
>>>> c
>
> Thanks for the review. I have updated the patch based on the comments
> with some other minor changes. Bootstrapped and regression tested on
> aarch64-none-linux-gnu with no-new regressions. Is this OK for trunk?
>
>
> Thanks,
> Kugan
>
>
> gcc/
ootstrapped successfully on chromebook. Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2015-04-26 Kugan Vivekanandarajah
Zhenqiang Chen
PR target/65768
* config/arm/arm.h (CONST_OK_FOR_SPLIT): New macro.
* config/arm/arm.md (subsi3, andsi3, iorsi3, xo
all variables but only those
> where compensation code (zero-/sign-extensions) is not necessary?
>
Thanks for the comments. Please find an updated version of this which
addresses your review comments above. I am still to do full benchmarking
on this, but tried with few small benchmarks. I will do pro
On 30/04/15 21:35, Richard Biener wrote:
> On Thu, Apr 23, 2015 at 12:11 AM, Kugan
> wrote:
>>
>> On 19/01/15 22:28, Richard Biener wrote:
>>> On Sat, 17 Jan 2015, Kugan wrote:
>>>
>>>>
>>>> This patch propagate value range wrapps at
On 05/05/15 16:17, James Greenhalgh wrote:
> On Sat, Apr 25, 2015 at 12:26:16AM +0100, Kugan wrote:
>>
>> Thanks for the review. I have updated the patch based on the comments
>> with some other minor changes. Bootstrapped and regression tested on
>> aarch64
Looks like a typo to me. Bootstrapped and regression tested on
x86_64-unknown-linux-gnu with no new regressions.
Is this OK for stage1?
Thanks,
Kugan
gcc/ChangeLog:
2015-02-28 Kugan Vivekanandarajah
* ira-costs.c (record_operand_costs): Fix typo (remove redundant code).
diff --git
Is this
OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2015-03-16 Kugan Vivekanandarajah
Jim Wilson
PR target/65375
* config/aarch64/aarch64.c (aarch64_rtx_costs): Return
extra_cost->vect.alu for SET.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/
eck whether x is a valid immediate for
> a simd instruction and give it a cost of extra_cost->vect.alu. The logic
> should be similar to the CONST_INT case.
Sorry about the (set (reg) (const_int)) above. But the actual RTL that
is being split at 220r.subreg2 is
(insn 11 10 12 2 (set (subreg
On 16/03/15 23:32, Kugan wrote:
>>> lower-subreg.c:compute_costs() only cares about the cost of a (set (reg)
>>> (const_int )) move but I think the intention, at least for now, is to
>>> return extra_cost->vect.alu for all the vector operations.
>>
>
On 17/03/15 03:48, Kyrill Tkachov wrote:
>
> On 16/03/15 13:15, Kugan wrote:
>> On 16/03/15 23:32, Kugan wrote:
>>>>> lower-subreg.c:compute_costs() only cares about the cost of a (set
>>>>> (reg)
>>>>> (const_int )) move but I
ping?
Thanks,
Kugan
On 17/03/15 12:19, Kugan wrote:
>
>
> On 17/03/15 03:48, Kyrill Tkachov wrote:
>>
>> On 16/03/15 13:15, Kugan wrote:
>>> On 16/03/15 23:32, Kugan wrote:
>>>>>> lower-subreg.c:compute_costs() only cares about the cost of a (
=65139.
This is based on Maxim's patch. I have bootstrapped and regression
tested on aarch64-linux-gnu with no new regressions. Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2015-04-15 Kugan Vivekanandarajah
Maxim Kuvyrkov
PR target/65139
* config/aa
Ping?
Now that Stage1 is open, is this OK for trunk.
Thanks,
Kugan
On 26/03/15 18:21, Kugan wrote:
> ping?
>
> Thanks,
> Kugan
>
> On 17/03/15 12:19, Kugan wrote:
>>
>>
>> On 17/03/15 03:48, Kyrill Tkachov wrote:
>>>
>>> On 16/03/15 1
-patches/2014-08/msg00325.html to fix this
As mentioned in PR65768, I tried with few more test-cases and enhanced
it. Regression tested on arm-none-linux-gnu and no new regressions. Is
this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2015-04-15 Kugan Vivekanandarajah
Zhenqiang Chen
and bootstrapped, regression tested on x86_64-linux-gnu;
no new regressions. Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2015-04-15 Kugan Vivekanandarajah
Zhenqiang Chen
PR target/65768
* cprop.c (try_replace_reg): Check cost of constants before propagating
On 15/04/15 18:21, Kyrill Tkachov wrote:
> Hi Kugan,
>
> On 15/04/15 08:48, Kugan wrote:
>> As mentioned in PR65768, ARM gcc generates suboptimal code for constant
>> Uses in loop. Part of the reason is that ARM back-end is splitting
>> constants during expansion of
On 15/04/15 19:25, James Greenhalgh wrote:
> On Tue, Apr 14, 2015 at 11:08:55PM +0100, Kugan wrote:
>> Now that Stage1 is open, is this OK for trunk.
>
> Hi Kugan,
>
>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>> index cba3c1a..d6ad
On 15/04/15 21:18, James Greenhalgh wrote:
> On Wed, Apr 15, 2015 at 11:45:36AM +0100, Kugan wrote:
>>> There are two ways I see that we could clean things up, both of which
>>> require some reworking of your patch.
>>>
>>> Either we remove my check above
On 15/04/15 21:59, Maxim Kuvyrkov wrote:
>> On Apr 15, 2015, at 12:41 AM, Kugan
>> wrote:
>>
>> This patch uses clobber with match_scratch instead of earlyclobber for
>> aarch64_lshr_sisd_or_int_3 so that RA can have more freedom in
>> selecting suitab
On 15/04/15 22:32, Jakub Jelinek wrote:
> On Wed, Apr 15, 2015 at 01:18:36PM +0100, Richard Earnshaw wrote:
>> On 14/04/15 22:41, Kugan wrote:
>>> This patch uses clobber with match_scratch instead of earlyclobber for
>>> aarch64_lshr_sisd_or_int_3 so that
On 16/04/15 08:32, Jakub Jelinek wrote:
> On Thu, Apr 16, 2015 at 08:27:24AM +1000, Kugan wrote:
>> +if ( == LSHIFTRT)
>> + {
>> +emit_insn (gen_aarch64_lshr_sisd_or_int_3 (operands[0],
>> operands[1], operands[2]));
>
> That is
ping?
Thanks,
Kugan
On 02/06/15 09:14, Kugan wrote:
>
>
> On 08/05/15 22:48, Richard Biener wrote:
>> You compute which promotions are unsafe, like sources/sinks of memory
>> (I think you miss call arguments/return values and also asm operands here).
>> But instead
As discussed in PR64130, this patch improves the VRP value ranges for
unsigned division.
Bootstrapped and regression tested on x86_64-linux-gnu and regression
tested on arm-none-linux-gnu with no new regression.
Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2015-06-20 Kugan
On 23/06/15 01:09, Richard Biener wrote:
> On Sat, Jun 20, 2015 at 9:12 AM, Kugan
> wrote:
>> As discussed in PR64130, this patch improves the VRP value ranges for
>> unsigned division.
>>
>> Bootstrapped and regression tested on x86_64-linux-gnu and regression
&
emitting arm_emit_movpair.
Bootstrapped and regression tested on arm-none-linux (Chromebook) and
x86-64-linux-gnu with no new regression.
Is this OK for trunk,
Thanks,
Kugan
This patch allows setting REG_EQUAL for ZERO_EXTRACT and handle that in
cse (where the src for the ZERO_EXTRACT needs to be calculated)
Thanks,
Kugan
2015-06-26 Kugan Vivekanandarajah
* cse.c (cse_insn): Calculate src_eqv for ZERO_EXTRACT.
* emit-rtl.c (set_for_reg_notes
This patch sets REG_EQUAL when emitting arm_emit_movpair.
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2015-06-26 Kugan Vivekanandarajah
* gcc.target/arm/reg_equal_test.c: New test.
gcc.
2015-06-26 Kugan Vivekanandarajah
* config/arm/arm.c (arm_emit_movpair): Add REG_EQUAL
On 26/06/15 04:27, Jeff Law wrote:
> On 06/24/2015 12:36 AM, Kugan wrote:
>>
>>
>> On 23/06/15 01:09, Richard Biener wrote:
>>> On Sat, Jun 20, 2015 at 9:12 AM, Kugan
>>> wrote:
>>>> As discussed in PR64130, this patch impro
On 29/06/15 21:56, Maxim Kuvyrkov wrote:
>> On Jun 28, 2015, at 2:28 PM, Kugan wrote:
>>
>> This patch allows setting REG_EQUAL for ZERO_EXTRACT and handle that in
>> cse (where the src for the ZERO_EXTRACT needs to be calculated)
>>
Please find a patch that attempt to FIX PR66726 by factoring conversion
out of COND_EXPR as explained in the PR.
Bootstrapped and regression tested on x86-64-none-linux-gnu with no new
regressions. Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2015-07-03 Kugan Vivekanandarajah
On 04/07/15 18:51, Bernhard Reutner-Fischer wrote:
> On Sat, Jul 04, 2015 at 12:58:58PM +1000, Kugan wrote:
>> Please find a patch that attempt to FIX PR66726 by factoring conversion
>> out of COND_EXPR as explained in the PR.
>>
>> Bootstrapped and regression tested on
On 30/06/15 17:16, Maxim Kuvyrkov wrote:
>> On Jun 30, 2015, at 6:54 AM, Kugan wrote:
>>
>>
>> On 29/06/15 21:56, Maxim Kuvyrkov wrote:
>>>> On Jun 28, 2015, at 2:28 PM, Kugan
>>>> wrote:
>>>>
>>>> This patch allows setti
On 07/07/15 07:37, Jeff Law wrote:
> On 07/04/2015 06:32 AM, Kugan wrote:
> I would also verify that this turns into a MIN_EXPR. I think the patch
> as-written won't detect the MIN_EXPR until the _next_ time phi-opt is
> called. And one of the benefits we're really
enable it again.
PATCH1: Free a bit in SSA_NAME to save wrapped information
PATCH2: Propagate and save value ranges wrapped information
PATCH3: Enable zero/sign extension elimination
Bootstrapped and regression tested for x86_64-linux-gnu with no new
regressions.
Thanks,
Kugan
Freeing a spare-bit to store wrapped attribute by going back to
representing VR_ANTI_RANGE as [max + 1, min - 1] in SSA_NAME.
Thanks,
Kugan
gcc/ChangeLog:
2015-01-16 Kugan Vivekanandarajah
* tree-ssanames.c (set_range_info): Change range info representation
and represent
This patch propagate value range wrapps attribute and save this to
SSA_NAME.
Thanks,
Kugan
gcc/ChangeLog:
2015-01-16 Kugan Vivekanandarajah
* builtins.c (determine_block_size): Use new definition of
get_range_info.
* gimple-pretty-print.c (dump_ssaname_info): Dump
Re-enable zero/sign extension elimination using value range that
includes wrapped attribute.
Thanks,
Kugan
gcc/ChangeLog:
2015-01-16 Kugan Vivekanandarajah
* calls.c (precompute_arguments): Check
promoted_for_signed_and_unsigned_p and set the promoted mode
g as
expected. I haven't looked in detail but will look into it based on the
feedback.
Please also note that this pass still doest handle debug instructions
and there are couple regression failures for ARM.
Thanks,
Kugan
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 4a51393..1e26172 100644
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,
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 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
in
https://patchwork.ozlabs.org/patch/648662/. I will commit that soon.
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
-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
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
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
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
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
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
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
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: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
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
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
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
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 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 !=
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 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
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,
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
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 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
structure with wide_int.
Thanks,
Kugan
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
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
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
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/
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
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
%O%s} \
+ crt0%O%s"
Some targets seems to use shared|pie. When you change it, shouldn't it
also include for pie?
Thanks,
Kugan
RTX (SImode))
+ *cost += 1;
return true;
}
Your ChangeLog says decrease cost for ashldi3 by 1 but looks like it is
done only for SImode. Am I missing something?
Also, what was the motivation for this patch. Is that to improve the
maintainability of the arm back-end?
Thanks,
Kugan
vec *bits;
/* Value range information. */
- vec *m_vr;
+ vec *m_vr;
};
This also has the same issue so I don't think it has anything to do with
variable structure.
Thanks,
Kugan
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index aa3c997..bc6670f 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp
Hi Richard,
On 30/01/17 21:08, Richard Biener wrote:
On Mon, Jan 30, 2017 at 12:23 AM, kugan
wrote:
lto1: internal compiler error: Segmentation fault
0xdedc4b crash_signal
../../gcc/gcc/toplev.c:333
0xb46680 ipa_node_params_t::duplicate(cgraph_node*, cgraph_node*,
ipa_node_params
Hi Richard,
On 30/01/17 21:08, Richard Biener wrote:
On Mon, Jan 30, 2017 at 12:23 AM, kugan
wrote:
Hi All,
As suggested by Richard in the PR, I tried to implement variable size
structures for VR as shown in attached patch. That is, I changed ipa-prop.h
to:
diff --git a/gcc/ipa-prop.h b/gcc
amp;& integer_zerop (vr0.min))
+set_value_range_to_nonnull (vr, TREE_TYPE (op0));
Just wondering if this has to be done only for POINTER_TYPE_P (TREE_TYPE
(op))? Or is EXACT_DIV_EXPR always of POINTER_TYPE_P?
Thanks,
Kugan
On 11/03/16 03:39, Martin Jambor wrote:
Hi,
On Tue, Mar 01, 2016 at 09:04:25AM +1100, kugan wrote:
Hi,
As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69708 and
corresponding mailing list discussion, IPA CP is not detecting a
jump-function with the sq function as value
101 - 200 of 563 matches
Mail list logo
