On Wed, 2015-10-14 at 11:00 +0200, Richard Biener wrote:
> On Tue, Oct 13, 2015 at 5:32 PM, David Malcolm wrote:
> > On Thu, 2015-09-24 at 10:15 +0200, Richard Biener wrote:
> >> On Thu, Sep 24, 2015 at 2:25 AM, David Malcolm wrote:
> >> > On Wed, 2015-09-23 at 15:36 +0200, Richard Biener wrote:
On Mon, 2015-10-19 at 16:51 +0200, Michael Matz wrote:
> Hi,
>
> On Fri, 16 Oct 2015, David Malcolm wrote:
>
> > This fixes much of the bloat seen for influence.i when sending ranges
> > through for every token.
>
> Yeah, I think that's on the right track.
Thanks.
> > This was with 8 bits al
Hi,
On Fri, 16 Oct 2015, David Malcolm wrote:
> This fixes much of the bloat seen for influence.i when sending ranges
> through for every token.
Yeah, I think that's on the right track.
> This was with 8 bits allocated for packed ranges (which is probably
> excessive, but it makes debugging e
On Wed, 2015-10-14 at 11:00 +0200, Richard Biener wrote:
> On Tue, Oct 13, 2015 at 5:32 PM, David Malcolm wrote:
> > On Thu, 2015-09-24 at 10:15 +0200, Richard Biener wrote:
> >> On Thu, Sep 24, 2015 at 2:25 AM, David Malcolm wrote:
> >> > On Wed, 2015-09-23 at 15:36 +0200, Richard Biener wrote:
Hi,
On Wed, 14 Oct 2015, Richard Biener wrote:
> The compile-time and memory-usage impact for the adhocloc at every token
> patchkit is quite big. Remember that gaining 1% in compile-time is hard
> and 20-40% memory increase for influence.i looks too much.
Yes. OTOH the compile time and memo
On Tue, Oct 13, 2015 at 5:32 PM, David Malcolm wrote:
> On Thu, 2015-09-24 at 10:15 +0200, Richard Biener wrote:
>> On Thu, Sep 24, 2015 at 2:25 AM, David Malcolm wrote:
>> > On Wed, 2015-09-23 at 15:36 +0200, Richard Biener wrote:
>> >> On Wed, Sep 23, 2015 at 3:19 PM, Michael Matz wrote:
>> >>
On Thu, 2015-09-24 at 10:15 +0200, Richard Biener wrote:
> On Thu, Sep 24, 2015 at 2:25 AM, David Malcolm wrote:
> > On Wed, 2015-09-23 at 15:36 +0200, Richard Biener wrote:
> >> On Wed, Sep 23, 2015 at 3:19 PM, Michael Matz wrote:
> >> > Hi,
> >> >
> >> > On Tue, 22 Sep 2015, David Malcolm wrote
On 09/24/2015 02:15 AM, Richard Biener wrote:
On Thu, Sep 24, 2015 at 2:25 AM, David Malcolm wrote:
LTO code does support ad-hoc locations but they are "restored" only
when reading function bodies and stmts (by means of COMBINE_LOCATION_DATA).
The obvious simplification would be, as you sugge
On Thu, Sep 24, 2015 at 2:25 AM, David Malcolm wrote:
> On Wed, 2015-09-23 at 15:36 +0200, Richard Biener wrote:
>> On Wed, Sep 23, 2015 at 3:19 PM, Michael Matz wrote:
>> > Hi,
>> >
>> > On Tue, 22 Sep 2015, David Malcolm wrote:
>> >
>> >> The drawback is that it could bloat the ad-hoc table. C
On Wed, 2015-09-23 at 15:36 +0200, Richard Biener wrote:
> On Wed, Sep 23, 2015 at 3:19 PM, Michael Matz wrote:
> > Hi,
> >
> > On Tue, 22 Sep 2015, David Malcolm wrote:
> >
> >> The drawback is that it could bloat the ad-hoc table. Can the ad-hoc
> >> table ever get smaller, or does it only ever
On 09/23/2015 07:47 AM, Michael Matz wrote:
Hi,
On Wed, 23 Sep 2015, Richard Biener wrote:
The issue we have with LTO is that the linemap gets populated in quite
random order and thus we repeatedly switch files (we've mitigated this
somewhat for GCC 5).
Yes.
We also considered dropping col
Hi,
On Wed, 23 Sep 2015, Richard Biener wrote:
> The issue we have with LTO is that the linemap gets populated in quite
> random order and thus we repeatedly switch files (we've mitigated this
> somewhat for GCC 5).
Yes.
> We also considered dropping column info (and would drop range info) as
On Wed, Sep 23, 2015 at 3:19 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 22 Sep 2015, David Malcolm wrote:
>
>> The drawback is that it could bloat the ad-hoc table. Can the ad-hoc
>> table ever get smaller, or does it only ever get inserted into?
>
> It only ever grows.
>
>> An idea I had is that
Hi,
On Tue, 22 Sep 2015, David Malcolm wrote:
> The drawback is that it could bloat the ad-hoc table. Can the ad-hoc
> table ever get smaller, or does it only ever get inserted into?
It only ever grows.
> An idea I had is that we could stash short ranges directly into the 32
> bits of locatio
This is an updated version of this patch kit:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00726.html
It's still at the level of an RFC/work-in-progress; I'm posting for
feedback rather than for formal approval at this time (though the
first two patches are perhaps ready).
For the sake of simpl
15 matches
Mail list logo
