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
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
On Fri, Apr 29, 2011 at 9:18 AM, Paolo Bonzini bonz...@gnu.org 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.
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
On Fri, Apr 29, 2011 at 09:24, Dimitrios Apostolou ji...@gmx.net 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
Paolo == Paolo Bonzini bonz...@gnu.org 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:
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
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 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 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 we take
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 Wed, Apr 27, 2011 at 10:29 PM, Basile Starynkevitch
bas...@starynkevitch.net 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
On Thu, Apr 28, 2011 at 2:52 PM, Chiheng Xu chiheng...@gmail.com wrote:
On Wed, Apr 27, 2011 at 10:29 PM, Basile Starynkevitch
bas...@starynkevitch.net 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
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
On Thu, Apr 28, 2011 at 9:13 PM, Robert Dewar de...@adacore.com 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.
On Fri, Apr 29, 2011 at 8:07 AM, Yuan Pengfei cool...@qq.com 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.
2011/4/27 Dimitrios Apostolou ji...@gmx.net:
* 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
17 matches
Mail list logo