Hi Everyone,
I was one of the original authors of hot cold splitting optimization in LLVM. I
was wondering if implementing
a region based hot cold splitting optimization would be useful in GCC? We
already have optimal implementation of SESE region detection in GCC
(https://github.com/gcc-mirror/
2:47 AM
To: Aditya K ; gcc@gcc.gnu.org
Cc: Jan Hubicka
Subject: Re: GSoC topic: Implement hot cold splitting at GIMPLE IR level
Hello.
Thank you for idea. I would like to provide some comments about what GCC can
currently
do and I'm curious we need something extra on top of what we do.
Righ
IIUC, in the haifa-sched.c, the default scheduling algorithm seems to be
top-down (before reload).
Is there a way to schedule the other way (bottom up), or both ways?
As a use case for bottom-up or some other heuristic:
Currently, the first priority in the selection is given to the longest path,
> Subject: Re: Combined top-down and bottom-up instruction scheduler
> To: hiradi...@msn.com; gcc@gcc.gnu.org
> CC: vmaka...@redhat.com
> From: l...@redhat.com
> Date: Tue, 8 Sep 2015 12:51:24 -0600
>
> On 09/08/2015 12:39 PM, Aditya
I started with one of the test cases in the plugin testsuite "def_plugin.c".
Pasted the code for convenience.
I want to traverse all the loops in a function.
Maybe use, loops_for_fn (DECL_STRUCT_FUNCTION (fndef)), but this does not seem
to work.
/* Callback function to invoke after GCC finishe
> Date: Mon, 9 Mar 2015 15:26:26 -0400
> From: tbsau...@tbsaunde.org
> To: gcc@gcc.gnu.org
> Subject: Re: Proposal for adding splay_tree_find (to find elements without
> updating the nodes).
>
> On Mon, Mar 09, 2015 at 06:59:10PM +, vax mzn wrote:
>>
> From: stevenb@gmail.com
> Date: Mon, 9 Mar 2015 23:59:52 +0100
> Subject: Re: Proposal for adding splay_tree_find (to find elements without
> updating the nodes).
> To: hiradi...@msn.com
> CC: gcc@gcc.gnu.org
>
> On Mon, Mar 9, 2015 at 7:59 PM, vax
---
> Date: Tue, 10 Mar 2015 11:20:07 +0100
> Subject: Re: Proposal for adding splay_tree_find (to find elements without
> updating the nodes).
> From: richard.guent...@gmail.com
> To: stevenb@gmail.com
> CC: hiradi...@msn.com; gcc@gcc.gnu.org
>
> On Mon, Ma
You're right. I'll change this to:
/* A stable comparison functor to sort trees. */
struct tree_compare_decl_uid {
bool operator ()(const tree &xa, const tree &xb) const
{
return DECL_UID (xa) < DECL_UID (xb);
}
};
New patch attached.
Thanks,
-Aditya
--
> Date: Sat, 14 Mar 2015 18:22:29 +0300
> From: malts...@gmail.com
> To: gcc@gcc.gnu.org; san...@codesourcery.com
> Subject: Examples of GCC plugins
>
> Hi, all.
>
> When I first tried to write a simple plugin for GCC, it turned out that
> existing docs on
> From: ajit.kumar.agar...@xilinx.com
> To: l...@redhat.com; richard.guent...@gmail.com; gcc@gcc.gnu.org
> CC: vin...@xilinx.com; shail...@xilinx.com; vid...@xilinx.com;
> nmek...@xilinx.com
> Subject: Proposal for another approach for Loop transformation
> From: ajit.kumar.agar...@xilinx.com
> To: l...@redhat.com; richard.guent...@gmail.com; gcc@gcc.gnu.org
> CC: vin...@xilinx.com; shail...@xilinx.com; vid...@xilinx.com;
> nmek...@xilinx.com
> Subject: Proposal for another approach for Loop transformation
strap enabled),
I'm not sure if 'omp' related tests were exercised.
I'm still unfamiliar with several components of gcc. Any pointers on how to
ensure all tests were run, would be useful.
-Aditya
>
> thanks!
>
> Trev
>
> On Fri, Mar 13, 2015
> From: lopeziba...@gmail.com
> Date: Mon, 16 Mar 2015 15:16:55 +0100
> Subject: Re: Proposal for adding splay_tree_find (to find elements without
> updating the nodes).
> To: tbsau...@tbsaunde.org; gcc@gcc.gnu.org; hiradi...@msn.com
>
>>> Thanks for the
> From: lopeziba...@gmail.com
> Date: Mon, 16 Mar 2015 17:04:58 +0100
> Subject: Re: Proposal for adding splay_tree_find (to find elements without
> updating the nodes).
> To: jwakely@gmail.com
> CC: hiradi...@msn.com; tbsau...@tbsaunde.org; gcc@gcc.g
> From: hiradi...@msn.com
> To: lopeziba...@gmail.com; jwakely@gmail.com
> CC: tbsau...@tbsaunde.org; gcc@gcc.gnu.org
> Subject: RE: Proposal for adding splay_tree_find (to find elements without
> updating the nodes).
> Date: Mon, 16 Mar 2015 18:45:22
gnu.org
>
> On Mon, Mar 16, 2015 at 4:33 AM, Aditya K wrote:
>>
>>
>>
>>> Date: Sun, 15 Mar 2015 02:32:23 -0400
>>> From: tbsau...@tbsaunde.org
>>> To: gcc@gcc.gnu.org
>>> Subject: Re: Proposa
.@gmail.com; tbsau...@tbsaunde.org; gcc@gcc.gnu.org
>
> On 18 March 2015 at 21:20, Aditya K wrote:
>>
>>
>>
>>> Date: Wed, 18 Mar 2015 11:50:16 +0100
>>> Subject: Re: Proposal for adding splay_tree_find (to find elemen
athamesh.kulka...@linaro.org
>> To: hiradi...@msn.com
>> CC: richard.guent...@gmail.com; tbsau...@tbsaunde.org; gcc@gcc.gnu.org
>>
>> On 18 March 2015 at 21:20, Aditya K wrote:
>>>
>>>
>>>
>>>>
out
> updating the nodes).
> Date: Tue, 31 Mar 2015 09:09:24 +0200
>
> Hi!
>
> On Mon, 30 Mar 2015 22:28:41 +, Aditya K wrote:
>> So I have modified the patch to use hash_map instead of std::map. The patch
>> is attached.
>>
>> However, I got one regres
After patching linux perf. This script collects creates a coverage file (e.g.,
for linpack) which can be used for fdo.
gcov=linpack-x86.gcov
MAKE='make'
# x86
x86() {
CC=/usr/bin/gcc
CXX=/usr/bin/g++
export CFLAGS="-Ofast -g3 -static"
export CPPFLAGS=$CFLAGS
$MAKE -C $SRC/SingleSource/Benchm
> CC: hiradi...@msn.com; gcc@gcc.gnu.org
> From: pins...@gmail.com
> Subject: Re: Compiler warnings while compiling gcc with clang
> Date: Tue, 5 May 2015 01:11:38 -0700
> To: renato.go...@linaro.org
>
>
>
>
>
>> On May 5, 2015, at 1:00 AM, Renato Golin
~
../../gcc/gcov-tool.c:462:10: note: initialize the variable 'ret' to silence
this warning
int ret;
^
= 0
I think I can fix few of these if we want them to be fixed.
For some e.g. ( gcc/gcov-tool.c:225:7: warning: array index 1 is past the end
of the
gt;
>
>> On May 5, 2015, at 8:13 PM, Aditya K wrote:
>>
>> So, I analyzed other warnings and following is the list of relevant warning
>> that I could collect. Hope this is useful.
>>
>>
>> gcc/ipa-icf.c:508:12: warning: logical not is only applied to
> Date: Fri, 8 May 2015 11:19:12 -0700
> Subject: Re: AutoFDO profile toolchain is open-sourced
> From: de...@google.com
> To: i.palac...@samsung.com
> CC: davi...@google.com; hubi...@ucw.cz; gcc@gcc.gnu.org;
> v.bari...@samsung.com; dnovi...@google.com;
Recently we found an ICE while compiling a program with auto-fdo
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972).
The ICE was caused because SSA is not in a valid state when the early inliner
is run. The fix was to update_ssa before running the early inliner
(https://gcc.gnu.org/bugzilla/sh
>
> 2) ipa-split is very simplistic and only splits when there is no value
>computed in header of function used in the tail. We should support
> adding extra parameters for values computed and do more general SESE
>outlining
> Note that we do SESE outlining for openMP but this code is
reuse them.
-Aditya
From: Jakub Jelinek
Sent: Monday, March 16, 2020 5:19:16 PM
To: Aditya K
Cc: Jan Hubicka ; gcc@gcc.gnu.org
Subject: Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level
On Mon, Mar 16, 2020 at 11:11:14PM +, Aditya K via Gcc
28 matches
Mail list logo
