On Fri, 29 Apr 2011, Laurynas Biveinis wrote:
Thanks Diego, please send me the form. I'll sign it as soon as my
contributions require it.
Don't wait; sign it right away - it might take a while to process it.
Hey all, I should have told you, I sent the email so I'm now waiting for
the papers
> Thanks Diego, please send me the form. I'll sign it as soon as my
> contributions require it.
Don't wait; sign it right away - it might take a while to process it.
--
Laurynas
On Fri, Apr 29, 2011 at 04:20:15PM +0200, Paolo Bonzini wrote:
> On 04/29/2011 04:15 PM, Nathan Froyd wrote:
>>> > * cxx_binding should be 16 bytes, not 20.
>>
>> Not your fault, but comments like this on SpeedupAreas are so opaque as
>> to be useless. *Why* should cxx_binding be 16 bytes? Should
On 04/29/2011 04:15 PM, Nathan Froyd wrote:
> * cxx_binding should be 16 bytes, not 20.
Not your fault, but comments like this on SpeedupAreas are so opaque as
to be useless. *Why* should cxx_binding be 16 bytes? Should we take
the next member out and have a VEC someplace instead of chaining?
On Fri, Apr 29, 2011 at 09:18:56AM +0200, Paolo Bonzini wrote:
> * Get rid of EXPR_LIST and INSN_LIST
This is reasonably difficult, though particular subprojects may be easy
enough. Notable uses of EXPR_LIST:
- loop-iv.c
- the interface to TARGET_FUNCTION_VALUE
- the scheduler
- REG_NOTES
-
On Fri, 29 Apr 2011, Diego Novillo wrote:
The very first one is a copyright assignment. Have you started that
process? If not, I will send you the form.
Thanks Diego, please send me the form. I'll sign it as soon as my
contributions require it.
Dimitris
> "Paolo" == Paolo Bonzini writes:
Paolo> * Put the string at the end of the IDENTIFIER_NODE using the trailing
Paolo> array hack (or possibly in the ht_identifier, see
Paolo> libcpp/include/symtab.h and libcpp/symtab.c)
I implemented this once:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg
On Fri, Apr 29, 2011 at 09:24, Dimitrios Apostolou wrote:
> Thank you all for your ideas, they are much appreciated. I will certainly
> investigate into the areas you mentioned, so do keep the feedback coming. I
> will certainly comment on them, once I have a better understanding. And I'd
> like t
Thank you all for your ideas, they are much appreciated. I will certainly
investigate into the areas you mentioned, so do keep the feedback coming.
I will certainly comment on them, once I have a better understanding. And
I'd like to get in sync with existing work, so that duplicate effort is
a
On Fri, Apr 29, 2011 at 9:18 AM, Paolo Bonzini wrote:
> On 04/27/2011 03:28 PM, Yuan Pengfei wrote:
>>>
>>> Any other advice will be appreciated.
>>
>> I think you can look into llvm-clang. It compiles faster and uses
>> much less memory than gcc.
>
> It is also a completely different compiler. I
On 04/27/2011 03:28 PM, Yuan Pengfei wrote:
Any other advice will be appreciated.
I think you can look into llvm-clang. It compiles faster and uses
much less memory than gcc.
It is also a completely different compiler. It doesn't make sense to
compare the two, unless Dimitrios wants to rewr
On Fri, Apr 29, 2011 at 8:07 AM, Yuan Pengfei wrote:
> B+ tree is more commonly used in file systems. In memory, I think RB-tree is
> better.
> RB-tree vs. hash table is just like map vs. unordered_map.
>
Any balanced tree that have O(log(n)) lookup complexity, including splay tree.
--
Chiheng
On Thu, Apr 28, 2011 at 9:13 PM, Robert Dewar wrote:
> I think the hash table is a much better choice than the B+ tree. You
> really are much more interested in average case performance in a compiler
> than worst case, especially when the worst case will not
> happen in practice.
Basically, I agr
Hi Xu,
B+ tree is more commonly used in file systems. In memory, I think RB-tree is
better.
RB-tree vs. hash table is just like map vs. unordered_map.
--
Yuan Pengfei
Peking Unversity, China
On 4/28/2011 8:55 AM, Richard Guenther wrote:
It seems to me that hash table in GCC is more like mapping(or
dictionary, or associated array, or function(Key->Value)), instead of
containter.
I think the main problem of hash table is that conflict rate is
unpredictable, so the lookup time is unp
On Thu, Apr 28, 2011 at 2:52 PM, Chiheng Xu wrote:
> On Wed, Apr 27, 2011 at 10:29 PM, Basile Starynkevitch
> wrote:
>>
>>> Here are some areas I'll look closer to, as shown by some early profiling
>>> I performed:
>>> * hash tables (both htab and symtab)
>>
>> There is probably a lot of tuning
On Wed, Apr 27, 2011 at 10:29 PM, Basile Starynkevitch
wrote:
>
>> Here are some areas I'll look closer to, as shown by some early profiling
>> I performed:
>> * hash tables (both htab and symtab)
>
> There is probably a lot of tuning possible around GCC hash tables. However,
> I would imagine th
2011/4/27 Dimitrios Apostolou :
> * ggc_internal_alloc_stat() or maybe implementing proper memory management
> instead of garbage collection, for hottest caller
This one can easily take much more time than three months. I've been
working in this area, right now I'm working on allocating RTL outsid
>> Here are some areas I'll look closer to, as shown by some early profiling
>> I performed:
>> * hash tables (both htab and symtab)
>
> There is probably a lot of tuning possible around GCC hash tables.
Yes. I'd like to mention that I have been working on this myself during the
past weeks and
On Wed, Apr 27, 2011 at 06:07:58AM -0700, Richard Guenther wrote:
> * Speedup_areas wiki page is very interesting, but lacks measurements to
> help me assess the weight of each area mentioned. Any comments on those?
On Wed, Apr 27, 2011 at 3:06 PM, Dimitrios Apostolou wrote:
> General comment: w
On Wed, Apr 27, 2011 at 04:06:48PM +0300, Dimitrios Apostolou wrote:
> Hello list,
>
> I am Dimitris (IRC nick: jimis), and this summer I will be working
> on optimising GCC, under the umbrella of Google Summer of Code. My
> proposal involves profiling and benchmarking in order to detect
> hotspot
On Wed, Apr 27, 2011 at 3:06 PM, Dimitrios Apostolou wrote:
> Hello list,
>
> I am Dimitris (IRC nick: jimis), and this summer I will be working on
> optimising GCC, under the umbrella of Google Summer of Code. My proposal
> involves profiling and benchmarking in order to detect hotspots in both C
22 matches
Mail list logo
