Hi,
On Wed, 15 Jul 2015, Richard Biener wrote:
> >Or, maybe we're talking past each other. You mean the case where
> >complicated-expr-on-Y is the value-expr, and Y is _no_ stale decl, but
> >the complicated expr itself nevertheless is mentioned nowhere else?
> >Yes, those trees must be reta
On Wed, Jul 15, 2015 at 04:52:41PM +0200, Michael Matz wrote:
> On Wed, 15 Jul 2015, Michael Matz wrote:
>
> > Similar for "ptr->foo" if "ptr" is nowhere mentioned in code or tables.
> > In effect DECL_VALUE_EXPR refers to stale decls that aren't initialized,
> > aren't given a place and aren't
On July 15, 2015 4:52:41 PM GMT+02:00, Michael Matz wrote:
>Hi,
>
>On Wed, 15 Jul 2015, Michael Matz wrote:
>
>> Similar for "ptr->foo" if "ptr" is nowhere mentioned in code or
>tables.
>> In effect DECL_VALUE_EXPR refers to stale decls that aren't
>initialized,
>> aren't given a place and aren
Hi,
On Wed, 15 Jul 2015, Michael Matz wrote:
> Similar for "ptr->foo" if "ptr" is nowhere mentioned in code or tables.
> In effect DECL_VALUE_EXPR refers to stale decls that aren't initialized,
> aren't given a place and aren't dealt with in code.
Or, maybe we're talking past each other. You
Hi,
On Wed, 15 Jul 2015, Jakub Jelinek wrote:
> > No, I really meant value. If you think it has meaning, then tell me
> > what it is for DECL_VALUE_EXPR (X) to be 'Y', if Y is nowhere else
> > mentioned, neither in code, nor in local-decls, nor in globals, or
> > anywhere else that would be r
On Wed, Jul 15, 2015 at 04:25:44PM +0200, Michael Matz wrote:
> On Wed, 15 Jul 2015, Jakub Jelinek wrote:
>
> > On Wed, Jul 15, 2015 at 04:14:07PM +0200, Michael Matz wrote:
> > > That's Toms other approach with supporting multi-step dependencies. As I
> > > have tried to argue in the other thre
Hi,
On Wed, 15 Jul 2015, Jakub Jelinek wrote:
> On Wed, Jul 15, 2015 at 04:14:07PM +0200, Michael Matz wrote:
> > That's Toms other approach with supporting multi-step dependencies. As I
> > have tried to argue in the other thread, I think this idea is
> > fundamentally broken and just hides r
On Wed, Jul 15, 2015 at 04:14:07PM +0200, Michael Matz wrote:
> That's Toms other approach with supporting multi-step dependencies. As I
> have tried to argue in the other thread, I think this idea is
> fundamentally broken and just hides real bugs, and I don't see why this
> would be different
Hi,
On Tue, 14 Jul 2015, Richard Biener wrote:
> For example have those special caches have two marking phases. The first
> phase marks all non-key edges originating from each entry. The second
> phase is the same as what we have now - unmarked entries get removed.
>
> The first phase would go
On Tue, Jul 14, 2015 at 12:45 PM, Richard Biener
wrote:
> On Sun, Jul 12, 2015 at 5:53 PM, Tom de Vries wrote:
>> On 12/07/15 17:45, Tom de Vries wrote:
>>>
>>> Hi,
>>>
>>> this patch series implements the forbidding of multi-step garbage
>>> collection liveness dependencies between caches.
>>>
>
On Sun, Jul 12, 2015 at 5:53 PM, Tom de Vries wrote:
> On 12/07/15 17:45, Tom de Vries wrote:
>>
>> Hi,
>>
>> this patch series implements the forbidding of multi-step garbage
>> collection liveness dependencies between caches.
>>
>> The first four patches downgrade 3 caches to non-cache, since th
. Don't mark live recursively in gt_cleare_cache
Bootstrapped and reg-tested on x86_64, with ENABLE_CHECKING.
I'll post the patches in response to this email.
This patch downgrade value_expr_for_decl to non-cache.
OK for trunk?
Thanks,
- Tom
[PATCH 4/5] Downgrade value_expr_for_d
12 matches
Mail list logo
