>
> Ah, ok. Well, let's hope walk_tree walks all edges the DFS walk walks ;)
> A quick look tells me it doesn't walk DECL_VINDEX or
> DECL_FUNCTION_PERSONALITY for example.
I guess it should - will try patch adding that :) Both seems like just
ommisions - these fileds were added quite recently (
On Fri, 11 Jul 2014, Jan Hubicka wrote:
> > On Fri, 11 Jul 2014, Jan Hubicka wrote:
> >
> > > > > Hmm, walking everything first and then starting streaming sounds bad
> > > > > idea
> > > > > for locality. Can't I just re-do the walk since I know what the SCC
> > > > > is?
> > > > > I will rea
> On Fri, 11 Jul 2014, Jan Hubicka wrote:
>
> > > > Hmm, walking everything first and then starting streaming sounds bad
> > > > idea
> > > > for locality. Can't I just re-do the walk since I know what the SCC is?
> > > > I will read the code more after lunch.
> > >
> > > Might be possible with
On Fri, 11 Jul 2014, Jan Hubicka wrote:
> > > Hmm, walking everything first and then starting streaming sounds bad idea
> > > for locality. Can't I just re-do the walk since I know what the SCC is?
> > > I will read the code more after lunch.
> >
> > Might be possible with a 2nd SCC stack set up
> > Hmm, walking everything first and then starting streaming sounds bad idea
> > for locality. Can't I just re-do the walk since I know what the SCC is?
> > I will read the code more after lunch.
>
> Might be possible with a 2nd SCC stack set up, yes.
I set up hash_map to store the hash values
On Fri, 11 Jul 2014, Jan Hubicka wrote:
> > >
> > > We hash only on outgoing SCC edges. You can easily have
> > > main variant type T and variants T1,T2 that are same all used by type
> > > T again.
> >
> > Ok, but then the two variants shouldn't be in the same SCC or at
> > least not in the sa
> >
> > We hash only on outgoing SCC edges. You can easily have
> > main variant type T and variants T1,T2 that are same all used by type
> > T again.
>
> Ok, but then the two variants shouldn't be in the same SCC or at
> least not in the same SCC as the main variant.
They will because T refers
On Fri, 11 Jul 2014, Jan Hubicka wrote:
> >
> > Well - as we re-use the streamer cache to store the hash value it isn't
> > really possible to do better ... (at least I don't have a clever idea)
>
> OK, no cleverness on my side either.
> >
> > Yeah (though you wouldn't need the extra hashing -
>
> Well - as we re-use the streamer cache to store the hash value it isn't
> really possible to do better ... (at least I don't have a clever idea)
OK, no cleverness on my side either.
>
> Yeah (though you wouldn't need the extra hashing - we only need to know
> the hash of the SCC). The curre
On Fri, 11 Jul 2014, Jan Hubicka wrote:
> > Are we sure it ever stabilizes? But yes, I had something like this in mind
> > (just do one iteration always) in case we need to improve hashing.
>
> Hi,
> this is bit quick experiment with strengthening the hash by iteration. I don't
> seem to be able
> Are we sure it ever stabilizes? But yes, I had something like this in mind
> (just do one iteration always) in case we need to improve hashing.
Hi,
this is bit quick experiment with strengthening the hash by iteration. I don't
seem to be able to measure WPA time difference for the patch though
>
> Are we sure it ever stabilizes? But yes, I had something like this in mind
> (just do one iteration always) in case we need to improve hashing.
Not necesarily - imagine two identical type variants, no matter how hard we
hash&rehash, they will be same as they are identical. We can just keep
On July 9, 2014 2:36:57 PM CEST, Jan Hubicka wrote:
>> This part can probably be speed up quite a bit by doing the SCC
>unification
>> before materializing the SCC, that is, doing the "on-disk" format
>compare idea.
>> The issue here is that for bigger SCCs that have hash collisions in
>their
>> e
> This part can probably be speed up quite a bit by doing the SCC unification
> before materializing the SCC, that is, doing the "on-disk" format compare
> idea.
> The issue here is that for bigger SCCs that have hash collisions in their
> entries we need to do the edge walk - but eventually havin
On Wed, Jul 9, 2014 at 10:58 AM, Jan Hubicka wrote:
> Hello,
> perhaps I could write bit more on my longer term plans. At the moment 30% of
> firefox WPA is taken
> by straming trees and another roughly 30% is taken by inliner. It is bit
> anoying but relatively
> easy to optimize inliner, but
Hello,
perhaps I could write bit more on my longer term plans. At the moment 30% of
firefox WPA is taken
by straming trees and another roughly 30% is taken by inliner. It is bit
anoying but relatively
easy to optimize inliner, but trees represent bigger problem.
According to the stats average
>
> We have reverted the patch for now but I note that at least the piece
> below is a step backward from doing the compare in the on-disk
> format.
Why it is step backward from compare in the on-dist format? All the information
is still streamed, just not duplicated. Since we explicitly stream
On Mon, 30 Jun 2014, Dominique Dhumieres wrote:
> > Note that testusite passes with the patch; ...
>
> Confirmed. There is a typo
> s/fileds/fields/
>
> I have seen the failures because I now run the gfortran testsuite with
> the addition of '-g -flto'. Is it worth pushing in this direction?
Y
On Mon, 30 Jun 2014, Jan Hubicka wrote:
> >
> > Please revert the original patch instead which was not tested properly.
> > I'll get back to this after I return from vacation.
>
> OK, I will bootstrap and revert tomorrow morning.
>
> Note that testusite passes with the patch; the problem appea
On Sun, 29 Jun 2014, Jan Hubicka wrote:
> > In addition of pr61644 and pr61646, this commit breaks a lot of
> > fortran tests with -flto -O0.
> Hello,
> the problem here is that we have POINTER_TYPE that points to array of variable
> length (not sure why it happens only with -O0). The ICE is intro
> On June 29, 2014 9:53:03 PM CEST, Jan Hubicka wrote:
> >> In addition of pr61644 and pr61646, this commit breaks a lot of
> >> fortran tests with -flto -O0.
> >Hello,
> >the problem here is that we have POINTER_TYPE that points to array of
> >variable
> >length (not sure why it happens only with
> Note that testusite passes with the patch; ...
Confirmed. There is a typo
s/fileds/fields/
I have seen the failures because I now run the gfortran testsuite with
> Note that testusite passes with the patch; ...
Confirmed. There is a typo
s/fileds/fields/
I have seen the failures because I now run the gfortran testsuite with
the addition of '-g -flto'. Is it worth pushing in this direction?
Cheers,
Dominique
>
> Please revert the original patch instead which was not tested properly. I'll
> get back to this after I return from vacation.
OK, I will bootstrap and revert tomorrow morning.
Note that testusite passes with the patch; the problem appears only at -O0
-flto and fortran
that we apparently do
On June 29, 2014 9:53:03 PM CEST, Jan Hubicka wrote:
>> In addition of pr61644 and pr61646, this commit breaks a lot of
>> fortran tests with -flto -O0.
>Hello,
>the problem here is that we have POINTER_TYPE that points to array of
>variable
>length (not sure why it happens only with -O0). The ICE
> In addition of pr61644 and pr61646, this commit breaks a lot of
> fortran tests with -flto -O0.
Hello,
the problem here is that we have POINTER_TYPE that points to array of variable
length (not sure why it happens only with -O0). The ICE is introduced by the
fact that we stream the type inside of
In addition of pr61644 and pr61646, this commit breaks a lot of
fortran tests with -flto -O0.
TIA
Dominique
FAIL: gfortran.dg/actual_array_constructor_1.f90 -g -flto (internal compiler
error)
FAIL: gfortran.dg/alloc_comp_assign_6.f90 -g -flto (internal compiler error)
FAIL: gfortran.dg/allo
> Minor comments below, ok with those changes.
Thanks!
This is version of patch I commited after additional testing on building of
some bigger apps with LTO. The main change (in addition to those requested) is
that I moved the fixups into lto_copy_fields_not_streamed and added loop before
SCC unif
On Fri, 27 Jun 2014, Jan Hubicka wrote:
> Hi,
> the most common types of tree nodes streamed are declarations (5.4M for
> Firefox) and types (4.2M for Firefox). This patch makes representation of
> types smaller by avoiding saving redundent info about type and its variants.
> About 50% of types a
29 matches
Mail list logo
