> Date: Sat, 18 Jul 2015 02:22:19 +0200
> From: tob...@grosser.es
> To: hiradi...@msn.com; gcc-patches@gcc.gnu.org
> CC: seb...@gmail.com; richard.guent...@gmail.com
> Subject: Re: [PATCH] Rename parameters which are within scop
>
> Hi Aditya,
>
> could yo
Thanks for the update. I'll fix that asap.
-Aditya
> Date: Thu, 19 Nov 2015 08:36:58 -0500
> Subject: Re: [PATCH 1/2] [graphite] Move codegen related functions to
> graphite-isl-ast-to-gimple.c
> From: dje@gmail.com
> To: hiradi...@msn.com; aditya..
Hi,
I have tried to refactor gimple_expr_type to make it more readable. Removed the
switch block and redundant if.
Please review this patch.
Thanks,
-Aditya
gcc/ChangeLog:
2015-05-15 hiraditya
* gimple.h (gimple_expr_type): Refactor to make it concise. Remove
redundant if.
diff
> Date: Sat, 16 May 2015 11:53:57 -0400
> From: tbsau...@tbsaunde.org
> To: hiradi...@msn.com
> CC: gcc-patches@gcc.gnu.org
> Subject: Re: Refactor gimple_expr_type
>
> On Fri, May 15, 2015 at 07:13:35AM +, Aditya K wrote:
>
The function `splay_tree_node splay_tree_lookup (splay_tree, splay_tree_key);'
updates the nodes every time a lookup is done.
IIUC, There are places where we call this function in a loop i.e., we lookup
different elements every time.
e.g.,
In this exaple we are looking for a different `t' in each
> Date: Mon, 18 May 2015 12:08:58 +0200
> Subject: Re: Refactor gimple_expr_type
> From: richard.guent...@gmail.com
> To: hiradi...@msn.com
> CC: tbsau...@tbsaunde.org; gcc-patches@gcc.gnu.org
>
> On Sun, May 17, 2015 at 5:3
w.r.t. the PR48052, here is the patch which finds out if scev would wrap or not.
The patch symbolically evaluates if valid_niter>= loop->nb_iterations is true.
In that case the scev would not wrap (??).
Currently, we only look for two special 'patterns', which are sufficient to
analyze the simple
> Date: Tue, 19 May 2015 11:33:16 +0200
> Subject: Re: Refactor gimple_expr_type
> From: richard.guent...@gmail.com
> To: hiradi...@msn.com
> CC: tbsau...@tbsaunde.org; gcc-patches@gcc.gnu.org
>
> On Tue, May 19, 2015 at 12:0
> Date: Wed, 20 May 2015 11:11:52 +0200
> Subject: Re: Refactor gimple_expr_type
> From: richard.guent...@gmail.com
> To: hiradi...@msn.com
> CC: tbsau...@tbsaunde.org; gcc-patches@gcc.gnu.org
>
> On Tue, May 19, 2015 at 6:5
I tested this patch and it passes bootstrap and no extra failures.
Thanks
-Aditya
Symbolically evaluate conditionals, and subtraction when additional constraints
are provided.
Adding this evaluation mechanism helps vectorize some loops on 64bit machines
because on 64bit, a typecast appears
w
Currently, when we print the passes it does not print its name. This becomes
confusing when we want to print all the passes at once (e.g.,
-fdump-tree-all-all=stderr &> pass.dump).
This patch adds functionality to print the pass name. It passes bootstrap (with
default configurations).
Hope this
> Subject: Re: [PATCH] Print Pass Names
> From: richard.guent...@gmail.com
> Date: Fri, 22 May 2015 21:32:24 +0200
> To: hiradi...@msn.com; gcc-patches@gcc.gnu.org
>
> On May 22, 2015 6:32:38 PM GMT+02:00, Aditya K wrote:
>>Curr
I don't have commit access. I would appreciate if someone does that for me.
Thanks,
-Aditya
> Date: Tue, 26 May 2015 08:14:41 -0600
> From: l...@redhat.com
> To: hiradi...@msn.com; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Break when has_sample is tr
bject: Re: [PATCH] Print Pass Names
>
> On 05/22/2015 02:38 PM, Aditya K wrote:
>>
>>
>>
>>> Subject: Re: [PATCH] Print Pass Names
>>> From: richard.guent...@gmail.com
>>> Date: Fri, 22 May 2015 21:32:24 +02
> Date: Wed, 27 May 2015 18:41:55 +0200
> From: ja...@redhat.com
> To: l...@redhat.com
> CC: hiradi...@msn.com; gcc-patches@gcc.gnu.org
> Subject: Re: Remove splay_tree from gimplify.c
>
> On Wed, May 27, 2015 at 10:34:46AM -0600, Jeff Law wrote:
>> So the
> Date: Wed, 27 May 2015 09:07:30 -0600
> From: l...@redhat.com
> To: hiradi...@msn.com; richard.guent...@gmail.com; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Print Pass Names
>
> On 05/26/2015 08:32 AM, Aditya K wrote:
>> I
Hi,
This is a small patch where I moved a portion of code from the function
vectorize_loops outside to improve readability.
Please see the patch attached and give comments for improvements.
Thanks
-Aditya
refactor-vect
Description: Binary data
factor gcc/tree-vectorize.c:vectorize_loops
>
> On Tue, Apr 28, 2015 at 09:53:24PM -0600, Jeff Law wrote:
>> On 04/28/2015 08:20 PM, Aditya K wrote:
>>>Hi,
>>>This is a small patch where I moved a portion of code from the function
>>>vectorize_loops outside to
; On 04/29/2015 08:37 AM, Aditya K wrote:
>>
>> Thanks for the feedback. I have added comment and properly indented the code.
> I made a couple more formatting fixes (spaces -> tab & line wrapping),
> improved the ChangeLog, did a bootstrap & regression test on
>
I recently compiled gcc with clang and found few useful warnings
(https://gcc.gnu.org/ml/gcc/2015-05/msg00015.html,
https://gcc.gnu.org/ml/gcc/2015-05/msg00041.html).
I have a patch to fix some of those, it passes bootstrap, please apply these if
it is useful.
Thanks,
-Aditya
d, 6 May 2015 18:26:10 +0200
> From: ja...@redhat.com
> To: hiradi...@msn.com
> CC: rdsandif...@googlemail.com; pola...@redhat.com; gcc-patches@gcc.gnu.org
> Subject: Re: Fix compiler warnings
>
> On Wed, May 06, 2015 at 04:22:13PM +, Aditya K wrote:
>> Thanks Richard
Hi,
I refactored number_of_iterations_exit a little bit. I hope it is helpful.
The idea is to move the call to function dominated_by_p after some sanity
checks so as to avoid call to it.
Thanks,
-Aditya
2015-05-07 Aditya Kumar
* tree-ssa-loop-niter.c (number_of_iterations_exit): Mo
Thank you very much Jakub.
-Aditya
> Date: Thu, 7 May 2015 19:58:11 +0200
> From: ja...@redhat.com
> To: hiradi...@msn.com
> CC: gcc-patches@gcc.gnu.org
> Subject: Re: Fix compiler warnings
>
> On Wed, May 06, 2015 at 04:37:49PM
> Subject: Re: Patch: Refactor number_of_iterations_exit
> From: richard.guent...@gmail.com
> Date: Thu, 7 May 2015 19:47:37 +0200
> To: hiradi...@msn.com; gcc-patches@gcc.gnu.org
>
> On May 7, 2015 6:27:28 PM GMT+02:00, Aditya K
Hi Tobias,
A test case (gcc/testsuite/gcc.dg/graphite/pr18792.c) came up when we removed
`graphite-scop-detection.c:limit_scops'.
The test case is a scop where entry==exit,
BB5 (*#) -> BB6 (#);
BB6 -> BB5;
In this case BB2 is out of the scop. This is basically an empty (infinite) loop
with no e
.1.0.243.g30d45f7
> Date: Thu, 2 Jul 2015 09:53:25 +0200
> From: tob...@grosser.es
> To: hiradi...@msn.com; seb...@gmail.com
> CC: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Discard Scops for which entry==exit
>
> On 06/30/2015 05:47 PM, Aditya K wrote:
>> Hi Tobias,
&
> Could you try the corrected patch on your benchmarks?
For the test-case you gave there is a regression.
Benchmark
Time CPU Iterations
---
Without th
Thanks,
-Aditya
From: Jonathan Wakely
Sent: Monday, January 9, 2017 6:33 AM
To: Aditya K
Cc: Aditya Kumar; Sebastian Pop; libstd...@gcc.gnu.org; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] improve string find algorithm
On 06/01/17 22:19 +, Aditya K wrote:
>> Could you t
---
libstdc++-v3/ChangeLog | 3 +++
libstdc++-v3/src/c++11/shared_ptr.cc | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 08d9229..18924c4 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@
Ping.
From: Aditya Kumar
Sent: Wednesday, December 7, 2016 11:46 AM
To: libstd...@gcc.gnu.org
Cc: gcc-patches@gcc.gnu.org; hiradi...@msn.com; Aditya Kumar
Subject: [PATCH] improve string find algorithm
Here is an improved version of basic_string::find. The idea is to
split the string fin
> Date: Thu, 13 Aug 2015 12:02:43 +0200
> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
> From: richard.guent...@gmail.com
> To: tob...@grosser.es
> CC: hiradi...@msn.com; gcc-patches@gcc.gnu.org; s@samsung.com;
> seb...@gmail.com
>
> O
; seb...@gmail.com
>
> On Thu, Aug 13, 2015 at 7:56 PM, Aditya K wrote:
>>
>>
>>> Date: Thu, 13 Aug 2015 12:02:43 +0200
>>> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
>>> From: richard.guent...@gmail.com
>>> To: tob...@grosser.
; seb...@gmail.com
>
> On Fri, Aug 14, 2015 at 11:25 AM, Aditya K wrote:
>>
>>
>>
>>> Date: Fri, 14 Aug 2015 09:31:32 +0200
>>> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
>>> From: richard.g
; seb...@gmail.com
>
> On August 14, 2015 4:31:23 PM GMT+02:00, Aditya K wrote:
>>
>>
>>
>>> Date: Fri, 14 Aug 2015 11:47:05 +0200
>>> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
>>> F
>From db5036e40ed7ac43b66ca74c44ec8d0bdc934b07 Mon Sep 17 00:00:00 2001
From: AdityaK <1108430...@users.noreply.github.com>
Date: Sun, 29 Dec 2024 18:14:29 -0800
Subject: [PATCH] libstdc++: Use string::push_back instead of string::operator+=
operator+= returns string& which is ignored anyways.
---
pinging in case this was missed.
From: Aditya K
Sent: Sunday, December 29, 2024 6:36 PM
To: gcc-patches@gcc.gnu.org ; libstd...@gcc.gnu.org
Cc: jwak...@redhat.com
Subject: [PATCH] libstdc++: Use string::push_back instead of string::operator+=
>F
se string::push_back instead of
>> string::operator+=
>>
>> operator+= returns string& which is ignored anyways.
>Why does this matter? The compiler can see that the return value isn't used.
>Using += seems more readable to me.
nvm, i see both produce the same cod
This would help compiler optimize local static objects.
```
commit e2f299679ddf56a6d6d71ea9d589cd76b2ca107b
Author: Aditya Kumar <1894981+hiradi...@users.noreply.github.com>
Date: Thu Aug 13 09:41:34 2020 -0700
Add cold attribute to one time construction APIs
__cxa_guard_acquire is
_GLIBCXX_NOTHROW _GLIBCXX_COLD;
// DSO destruction.
int
__cxa_atexit(void (*)(void*), void*, void*) _GLIBCXX_NOTHROW;
void
__cxa_finalize(void*);
// TLS destruction.
int
```
From: Aditya K
Sent: Thursday, August 13, 2020 10:47 AM
To: Jeff Law via Gcc-patches ; jwakely@gm
FYI libc++ patch sent for review: https://reviews.llvm.org/D85873
sure.
--
From: Jonathan Wakely
Sent: Thursday, August 13, 2020 11:13 AM
To: Aditya K
Cc: libstdc++ ; gcc-patches
Subject: Re: Add cold attribute to one time construction APIs
Please CC the libstdc++ list on all libstdc++ patches.
On Thu, 13 Aug 2020 at 17:51, Aditya K wrote:
>
> R
41 matches
Mail list logo
