On Wed, Jul 23, 2014 at 9:56 PM, Andi Kleen wrote:
>> > Why didn't you replace the tree.c uses BTW?
>>
>> Patches were already quite big, but I'll add it.
>
> Actually I handled them all in tree.c. Did you
> mean something else?
I meant transform the iterative_hash_* _implementations_ to
use the
On 24 Jul 2014, at 03:48, Trevor Saunders wrote:
> On Thu, Jul 24, 2014 at 02:00:24AM +0200, Oleg Endo wrote:
>> On Wed, 2014-07-23 at 11:37 +0200, Richard Biener wrote:
>>> On Fri, Jul 18, 2014 at 3:08 AM, Trevor Saunders
>>> wrote:
On Thu, Jul 17, 2014 at 06:36:31AM +0200, Andi Kleen wr
On Thu, Jul 24, 2014 at 02:00:24AM +0200, Oleg Endo wrote:
> On Wed, 2014-07-23 at 11:37 +0200, Richard Biener wrote:
> > On Fri, Jul 18, 2014 at 3:08 AM, Trevor Saunders
> > wrote:
> > > On Thu, Jul 17, 2014 at 06:36:31AM +0200, Andi Kleen wrote:
> > >> On Wed, Jul 16, 2014 at 10:40:53PM -0400,
On Wed, 2014-07-23 at 11:37 +0200, Richard Biener wrote:
> On Fri, Jul 18, 2014 at 3:08 AM, Trevor Saunders
> wrote:
> > On Thu, Jul 17, 2014 at 06:36:31AM +0200, Andi Kleen wrote:
> >> On Wed, Jul 16, 2014 at 10:40:53PM -0400, Trevor Saunders wrote:
> >> >
> >> > > + public:
> >> > > +
> >> > >
> > Why didn't you replace the tree.c uses BTW?
>
> Patches were already quite big, but I'll add it.
Actually I handled them all in tree.c. Did you
mean something else?
I didn't convert all of tree-ssa-* and dwarf* so far,
and a few other places. This can be done step by step.
-Andi
> So there will be at most one hash implementation?
One per binary I expect. Modern hash functions are pretty good,
so it's unlikely that someone needs to come up with special
purpose hashes.
I found Bob Jenkins' spooky is rather good for this case (very
large incremential keys), but it is only
On July 23, 2014 4:27:43 PM CEST, Andi Kleen wrote:
>> Btw, what will be the way to plug in an alternative hash function?
>> That is, there doesn't seem to be a separation of interface
>> and implementation in your patch (like with a template or a
>base-class
>> you inherit from).
>
>Just change t
> Btw, what will be the way to plug in an alternative hash function?
> That is, there doesn't seem to be a separation of interface
> and implementation in your patch (like with a template or a base-class
> you inherit from).
Just change the inchash.h include file. The point was to only
change a si
On 07/15/14 23:31, Andi Kleen wrote:
From: Andi Kleen
Some files in gcc, like lto or tree, do large scale incremential hashing.
The current jhash implementation of this could be likely improved
by using an incremential hash that does not do a full rehashing
for every new value added.
This patc
On Fri, Jul 18, 2014 at 3:08 AM, Trevor Saunders wrote:
> On Thu, Jul 17, 2014 at 06:36:31AM +0200, Andi Kleen wrote:
>> On Wed, Jul 16, 2014 at 10:40:53PM -0400, Trevor Saunders wrote:
>> >
>> > > + public:
>> > > +
>> > > + /* Start incremential hashing, optionally with SEED. */
>> > > + void
On Thu, Jul 17, 2014 at 06:36:31AM +0200, Andi Kleen wrote:
> On Wed, Jul 16, 2014 at 10:40:53PM -0400, Trevor Saunders wrote:
> >
> > > + public:
> > > +
> > > + /* Start incremential hashing, optionally with SEED. */
> > > + void begin (hashval_t seed = 0)
> > > + {
> > > +val = seed;
>
On Wed, Jul 16, 2014 at 10:40:53PM -0400, Trevor Saunders wrote:
> > +++ b/gcc/inchash.h
> > +class inchash
> > +{
> > + hashval_t val;
>
> normal style would be explicit private: at the end.
Ok.
>
> > + public:
> > +
> > + /* Start incremential hashing, optionally with SEED. */
> > + void
> +++ b/gcc/inchash.h
> +class inchash
> +{
> + hashval_t val;
normal style would be explicit private: at the end.
> + public:
> +
> + /* Start incremential hashing, optionally with SEED. */
> + void begin (hashval_t seed = 0)
> + {
> +val = seed;
why isn't this the ctor?
> + /* Add u
13 matches
Mail list logo
