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
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
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
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 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
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
/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
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
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
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
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
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
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
>
> 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/
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
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 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 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 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
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 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 <>
>>>
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
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 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 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 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 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
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
-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
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
=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?
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 (
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
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.
>>
>
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
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/
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
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
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
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
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
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
On 01/10/14 01:00, Jiong Wang wrote:
> On 27/09/14 22:20, Kugan wrote:
>>
>> On 23/09/14 01:58, Jiong Wang wrote:
>>> On 22/09/14 16:43, Kugan wrote:
>>>
>>>> AArch64 has the same issue ARM had where the LR register was not
>>>> use
On 23/09/14 01:58, Jiong Wang wrote:
> On 22/09/14 16:43, Kugan wrote:
>
>> AArch64 has the same issue ARM had where the LR register was not used in
>> leaf functions. This was reported in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42017. In AArch64, this
>> t
?
Thanks,
Kugan
gcc/ChangeLog:
2014-09-23 Kugan Vivekanandarajah
* config/aarch64/aarch64.h (EPILOGUE_USES): Return true only after
epilogue_completed is true.
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index db950da..b3e4585 100644
--- a/gcc/config
On 08/09/14 19:48, Richard Biener wrote:
> On Sun, Sep 7, 2014 at 11:50 AM, Kugan
> wrote:
>> On 05/09/14 19:50, Richard Biener wrote:
>>
>>> Well - the best way would be to expose the target specifics to GIMPLE
>>> at some point in the optimization pi
e overflow/wrap around. Will that be something
acceptable?
Thanks again,
Kugan
regression tested on x86_64 and arm.
Thanks,
Kugan
gcc/testsuite
2014-09-05 Kugan Vivekanandarajah
PR target/43550
* gcc.target/arm/pr43550.c: New test.
gcc/
2014-09-05 Kugan Vivekanandarajah
PR target/43550
* builtins.c (expand_builtin_bswap): Generate promoted
idence. Can we rely on this?
Is there anyway we can fix this?
Thanks again,
Kugan
ld need is VRP computing value-ranges in the promoted
> mode from the start (and it doesn't do that).
Hi Richard,
Here is an attempt to do the value range computation in promoted_mode's
type when it is overflowing. Bootstrapped on x86-84.
Based on your feedback, I will do
On 27/08/14 20:07, Richard Biener wrote:
> On Wed, Aug 27, 2014 at 12:01 PM, Uros Bizjak wrote:
>> Hello!
>>
>>> 2014-08-07 Kugan Vivekanandarajah
>>>
>>> * calls.c (precompute_arguments): Check
>>> promoted_
On 28/08/14 16:44, Marc Glisse wrote:
> On Thu, 28 Aug 2014, Kugan wrote:
>
>> On 27/08/14 23:02, Kugan wrote:
>>> On 27/08/14 20:01, Uros Bizjak wrote:
>>>> Hello!
>>>>
>>>>> 2014-08-07 Kugan Vivekanand
On 27/08/14 23:02, Kugan wrote:
> On 27/08/14 20:01, Uros Bizjak wrote:
>> Hello!
>>
>>> 2014-08-07 Kugan Vivekanandarajah
>>>
>>> * calls.c (precompute_arguments): Check
>>> promoted_for_signed_and_unsigned_p and set the promoted mode.
>
On 27/08/14 20:01, Uros Bizjak wrote:
> Hello!
>
>> 2014-08-07 Kugan Vivekanandarajah
>>
>> * calls.c (precompute_arguments): Check
>> promoted_for_signed_and_unsigned_p and set the promoted mode.
>> (promoted_for_signed_and_unsigned_p): New func
MD registers so the vector variant must be
split.
+(define_insn_and_split "*xor_one_cmpl3"
+ [(set (match_operand:GPI 0 "register_operand" "=r,w")
+(not:GPI (xor:GPI (match_operand:GPI 1 "register_operand" "r,?w")
Hi Alan,
Is
>>
>> Is this OK?
>
> Err.
>
> @@ -0,0 +1,24 @@
> +
>
> Excessive vertical space
>
> +/* { dg-do compile } */
> +/* { dg-options "-Wstrict-overflow -O2" } */
> +/* { dg-bogus "assuming signed overflow does not occur when simplifying&quo
On 11/08/14 18:03, Richard Biener wrote:
> On Sat, Aug 9, 2014 at 2:33 PM, Kugan
> wrote:
>> Hi,
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904
>>
>> Tescase was generating warning: assuming signed overflow does not occur
>> when simplifying
requested there in the PR, I am sending this patch to add the test-case
to test-suite.
Is this OK ?
Thanks,
Kugan
gcc/testsuite
2014-08-09 Kugan Vivekanandarajah
PR tree-optimization/52904
* gcc.dg/PR52904.c: New test.
diff --git a/gcc/testsuite/gcc.dg/PR52904.c b/gcc
On 06/08/14 23:29, Richard Biener wrote:
> On Wed, Aug 6, 2014 at 3:21 PM, Kugan
> wrote:
>> On 06/08/14 22:09, Richard Biener wrote:
>>> On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek wrote:
>>>> On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richard Biener wr
case with larger mode signed and 'ssa' unsigned will not work.
Therefore larger mode unsigned and 'ssa' signed will be the only case
that we should consider.
However, with PROMOTE_MODE, isnt that we will miss some cases with this.
Thanks,
Kugan
On 02/08/14 02:03, Kugan wrote:
>>>> if (rhs_uns)
>>>>return wi::ge_p (min, 0); // if min >= 0 then range contains positive
>>>> values
>>>> else
>>>>return wi::le_p (max, wi::max_value (TYPE_PRECISION (TREE_TYPE
&g
lhs_mode, lhs_uns);
limit = wide_int::from (TYPE_MAX_VALUE (lhs_type),
TYPE_PRECISION (TREE_TYPE (ssa)), SIGNED);
if (lhs_uns)
/* If min >= 0 then range contains positive values and doesnt need
zero-extension. */
return wi::ge_p (min, 0, rhs_signop);
else
/* If min >= 0 and max <= signed-max-of-type then range doesn't need
sign-extension. */
return wi::ge_p (min, 0, rhs_signop) && wi::le_p (max, limit,
rhs_signop);
}
Thanks,
Kugan
lang_hooks.types.type_for_mode (lhs_mode, lhs_uns);
min_tree = wide_int_to_tree (rhs_type, min);
max_tree = wide_int_to_tree (rhs_type, max);
/* Check if values lies in-between the type range. */
if (int_fits_type_p (min_tree, lhs_type)
&& int_fits_type_p (max_tree, lhs_type))
return true;
else
return false;
}
Thanks,
Kugan
On 11/07/14 22:47, Richard Biener wrote:
> On Fri, Jul 11, 2014 at 1:52 PM, Kugan
> wrote:
>> Thanks foe the review and suggestions.
>>
>> On 10/07/14 22:15, Richard Biener wrote:
>>> On Mon, Jul 7, 2014 at 8:55 AM, Kugan
>>> wrote:
>>
>
or that might
confuse the readers. I am fixing that as well.
regression tested on qemu for arm-none-linux-gnueabi with no new
regressions.
Please let me know if this is OK?
Thanks,
Kugan
gcc/
2014-057-12 Kugan Vivekanandarajah
* config/arm/arm.c (bdesc_2arg): Fix typo.
Thanks foe the review and suggestions.
On 10/07/14 22:15, Richard Biener wrote:
> On Mon, Jul 7, 2014 at 8:55 AM, Kugan
> wrote:
[...]
>>
>> For -fwrapv, it is due to how PROMOTE_MODE is defined in arm back-end.
>> In the test-case, a function (which has signed char re
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
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
>>>
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 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 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 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 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 24/06/14 22:21, Jakub Jelinek wrote:
> On Tue, Jun 24, 2014 at 09:53:35PM +1000, Kugan wrote:
>> 2014-06-24 Kugan Vivekanandarajah
>>
>> * gcc/calls.c (precompute_arguments: Check is_promoted_for_type
>> and set the promoted mode.
>> (is_
TED_UNSIGNED_P(RTX) \
RTL_FLAG_CHECK1 ("SUBREG_PROMOTED_UNSIGNED_P", (RTX),
SUBREG)->volatil)\
+ (RTX)->unchanging) == 0) ? -1 : ((RTX)->volatil == 1))
Am I missing anything here? Please let me know. I am attaching the patch
based on this with your other
Sets proper flags on the SUBREG based on value
range info and enables elimination of zext/sext when possible.
Thanks,
Kugan
gcc/
2014-06-24 Kugan Vivekanandarajah
* gcc/calls.c (precompute_arguments: Check is_promoted_for_type
and set the promoted mode
Changes the the SUBREG flags to be able to set promoted for sign
(SRP_SIGNED), unsigned (SRP_UNSIGNED), sign and unsigned
(SPR_SIGNED_AND_UNSIGNED) in SUBREG_PROMOTED_VAR_P.
Thanks,
Kugan
gcc/
2014-06-24 Kugan Vivekanandarajah
* gcc/calls.c (precompute_arguments): Use new
r0, lsr #1
eorne r0, r0, #2
movne r0, r0, lsr #1
orrne r0, r0, #32768
- andsr3, r3, #255
+ subsr2, r2, #1
bne .L3
bx lr
Tested both patches on x86_64-unknown-linux-gnu and
arm-none-linux-gnueabi with no new regressions. Is this OK?
Thanks,
Kugan
re are no mrc/mcr versions of these
instructions in thumb1. So these should be conditional on not being
ARM_THUMB1.
Is this OK. Regression tested with no new refression on qemu for
arm-none-linux-gnueabi -march=armv7-a and on arm-none-linux-gnueabi
--with-mode=thumb and -march=armv5t.
Is this OK?
Th
On 22/05/14 22:18, Richard Earnshaw wrote:
> On 22/05/14 00:44, Kugan wrote:
>> Compiling some applications with -mgeneral-regs-only produces better
>> code (runs faster) compared to not using it. The difference here is that
>> when -mgeneral-regs-only is not used, floati
On 22/05/14 01:08, Marcus Shawcroft wrote:
> On 15 May 2014 01:10, Kugan wrote:
>>
>> Hi All,
>>
>> AAarch64 back-end defines GENERAL_REGS and CORE_REGS with the same set
>> of register. Is there any reason why we need this?
>
> Nope an artifact of t
Ping^2 ?
Thanks,
Kugan
On 12/05/14 09:47, Kugan wrote:
> Ping ?
>
> Thanks,
> Kugan
>
> On 02/05/14 19:04, Kugan wrote:
>> On 02/05/14 10:15, Joseph S. Myers wrote:
>>> It doesn't seem a good idea to me for a host-side GCC file to use the FE_*
>>>
On 24/05/14 00:06, Christophe Lyon wrote:
> Hi,
> Since merge from upstream r209283 (210743 in GCC), my build fails on
> ARM, because rpc/xdr.h is not found.
> Is this expected?
I also have the same issue. I had to build glibc with
--enable-obsolete-rpc to bootstrap now.
Thanks,
Kugan
a
lot but others regress). I am looking to see if I can make it perform
better overall. Any suggestions welcome.
Attached experimental patch passes regression but 168.wupwise and
187.facerec miscompares now. I am looking at fixing this as well.
Thanks,
Kugan
gcc/
2014-05-22 Kugan
Hi All,
In AArch64 back-end, BASE_REG_CLASS is defined to be POINTER_REGS.
Shouldn’t this be GENERAL_REGS?
Attached RFC patch makes it GENERAL_REGS. Regression tested for
aarch64-none-linux-gnu on qemu-aarch64 with now new regression. Is this OK ?
Thanks,
Kugan
gcc/
2014-05-15 Kugan
alternate; this might get confused with this.
Attached RFC patch removes it. regression tested for
aarch64-none-linux-gnu on qemu-aarch64 with now new regression. Is this OK ?
Thanks,
Kugan
gcc/
2014-05-14 Kugan Vivekanandarajah
* config/aarch64/aarch64.c (aarch64_regno_regclass
Ping ?
Thanks,
Kugan
On 02/05/14 19:04, Kugan wrote:
> On 02/05/14 10:15, Joseph S. Myers wrote:
>> It doesn't seem a good idea to me for a host-side GCC file to use the FE_*
>> names for the target's FE_* values; you'd run into problems if that file
>&g
Ping ?
Thanks,
Kugan
On 02/05/14 22:27, Kugan wrote:
>
>
> On 02/05/14 20:06, Marcus Shawcroft wrote:
>> On 29 April 2014 03:37, Kugan wrote:
>>>
>>> On 28/04/14 21:01, Ramana Radhakrishnan wrote:
>>>> On 04/26/14 11:57,
On 02/05/14 20:06, Marcus Shawcroft wrote:
> On 29 April 2014 03:37, Kugan wrote:
>>
>> On 28/04/14 21:01, Ramana Radhakrishnan wrote:
>>> On 04/26/14 11:57, Kugan wrote:
>>>> Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV for AARCH64.
>>&g
>
> +2014-04-29 Kugan Vivekanandarajah
> +
> + * config/aarch64/aarch64.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New
> + define.
> + * config/aarch64/aarch64-protos.h (aarch64_atomic_assign_expand_fenv):
> + New function declaration.
> + * config/aa
ny
> host. The same comment applies to the AArch64 patch as well.
>
> Instead I suggest names such as ARM_FE_* that won't conflict with the
> host's system headers.
>
Thanks for spotting it. Here is the updated patch that changes it to
ARM_FE_*.
Thanks,
Kugan
gcc/
+2014-
On 28/04/14 20:29, Ramana Radhakrishnan wrote:
> On 04/26/14 11:26, Kugan wrote:
>> Hi,
>>
>> Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV for ARM. With
>> this, atomic test-case gcc.dg/atomic/c11-atomic-exec-5.c now PASS.
>>
>> This im
On 28/04/14 21:01, Ramana Radhakrishnan wrote:
> On 04/26/14 11:57, Kugan wrote:
>> Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV for AARCH64.
>> With this, atomic test-case gcc.dg/atomic/c11-atomic-exec-5.c now PASS.
>>
>> This implementation
this OK for trunk?
Thanks,
Kugan
gcc/
+2014-04-27 Kugan Vivekanandarajah
+
+ * config/aarch64/aarch64.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New
+ define.
+ * config/aarch64/aarch64-builtins.c (arm_builtins) : Add
+ AARCH64_BUILTIN_LDFPSCR and AARCH64_BUILTIN_STFPSCR
this OK for trunk?
Thanks,
Kugan
gcc/
+2014-04-27 Kugan Vivekanandarajah
+
+ * config/arm/arm.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New define.
+ (arm_builtins) : Add ARM_BUILTIN_LDFPSCR and ARM_BUILTIN_STFPSCR.
+ (bdesc_2arg) : Add description for builtins __builtins_arm_stfpscr
On 24/04/14 23:05, Richard Biener wrote:
> On Wed, Apr 9, 2014 at 10:07 PM, Kugan
> wrote:
>> Value range propagation simplifies convergence in vrp_visit_phi_node by
>> setting minimum to TYPE_MIN when the computed minimum is smaller than
>> the previous minimum. Th
Ping?
On 10/04/14 06:07, Kugan wrote:
> Value range propagation simplifies convergence in vrp_visit_phi_node by
> setting minimum to TYPE_MIN when the computed minimum is smaller than
> the previous minimum. This can however result in pessimistic value
> ranges in some cases.
>
and converge to the right minimum value.
Attached patch fixes this. Is this OK for stage-1?
Bootstrapped and regression tested on X86_64-unknown-linux-gnu with no
new regressions.
Thanks,
Kugan
gcc/
+2014-04-09 Kugan Vivekanandarajah
+
+ * tree-vrp.c (vrp_visit_phi_node) : Improve va
nt of the object, if we have a SYMBOL_REF_BLOCK
> then we can get the block alignment irrespective of
> SYMBOL_REF_ANCHOR_P().
Thanks for the explanation. Is the attached patch looks OK ?
Thanks,
Kugan
gcc/
2014-03-25 Kugan Vivekanandarajah
PR target/60034
* aarch64/aa
On 12/03/14 20:07, Marcus Shawcroft wrote:
> Hi Kugan
>
>
> On 3 March 2014 21:56, Kugan wrote:
>
>> gcc/
>>
>> 2014-03-03 Kugan Vivekanandarajah
>>
>> PR target/60034
>> * aarch64/aarch64.c (aarch64_classify_ad
401 - 500 of 561 matches
Mail list logo
