On Fri, 5 Oct 2012, Steven Bosscher wrote:
> On Fri, Sep 14, 2012 at 2:26 PM, Richard Guenther wrote:
> > If you can figure out a better name for the function we should
> > probably move it to cfganal.c
>
> It looks like my previous e-mail about this appears to have gone got
> somehow, so retry:
On Fri, Sep 14, 2012 at 2:26 PM, Richard Guenther wrote:
> If you can figure out a better name for the function we should
> probably move it to cfganal.c
It looks like my previous e-mail about this appears to have gone got
somehow, so retry:
Your my_rev_post_order_compute is simply inverted_post
On Fri, 14 Sep 2012, Steven Bosscher wrote:
> On Fri, Sep 14, 2012 at 12:50 PM, Richard Guenther wrote:
> >> Yikes, I didn't know about my_rev_post_order_compute. How horrible!
> >> That function doesn't compute reverse post-order of the CFG, but a
> >> post-order of the reverse CFG!
> >
> > Ok, w
On Fri, Sep 14, 2012 at 12:50 PM, Richard Guenther wrote:
>> Yikes, I didn't know about my_rev_post_order_compute. How horrible!
>> That function doesn't compute reverse post-order of the CFG, but a
>> post-order of the reverse CFG!
>
> Ok, well - then that's what we need for compute_antic to have
On Fri, 14 Sep 2012, Richard Guenther wrote:
> As for the equiv sets - yes, that's known. I wanted to investigate
> at some point what happens if we instead record the SSA name we
> registered the assert for (thus look up a chain of lattice values
> instead of recording all relevant entries in a
On Fri, 14 Sep 2012, Steven Bosscher wrote:
> On Fri, Sep 14, 2012 at 11:43 AM, Richard Guenther wrote:
> >> > Any reason why you didn't just re-use the tree-ssa-live machinery?
> >>
> >> Probably I didn't know about it or didn't want to keep the full life
> >> problem life (it tries to free thin
On Fri, Sep 14, 2012 at 11:43 AM, Richard Guenther wrote:
>> > Any reason why you didn't just re-use the tree-ssa-live machinery?
>>
>> Probably I didn't know about it or didn't want to keep the full life
>> problem life (it tries to free things as soon as possible).
I think it'd be good to use t
On Fri, 14 Sep 2012, Richard Guenther wrote:
> On Thu, 13 Sep 2012, Steven Bosscher wrote:
>
> > On Wed, Sep 12, 2012 at 4:52 PM, Steven Bosscher wrote:
> > > On Wed, Sep 12, 2012 at 4:02 PM, Richard Guenther wrote:
> > >> for a followup (and I bet sth else than PRE blows up at -O2 as well).
> >
On Thu, 13 Sep 2012, Steven Bosscher wrote:
> On Wed, Sep 12, 2012 at 4:52 PM, Steven Bosscher wrote:
> > On Wed, Sep 12, 2012 at 4:02 PM, Richard Guenther wrote:
> >> for a followup (and I bet sth else than PRE blows up at -O2 as well).
> >
> > Actually, the only thing that really blows up is tha
On Wed, Sep 12, 2012 at 4:52 PM, Steven Bosscher wrote:
> On Wed, Sep 12, 2012 at 4:02 PM, Richard Guenther wrote:
>> for a followup (and I bet sth else than PRE blows up at -O2 as well).
>
> Actually, the only thing that really blows up is that enemy of scalability,
> VRP.
FWIW, this appears to
On Wed, Sep 12, 2012 at 4:02 PM, Richard Guenther wrote:
> for a followup (and I bet sth else than PRE blows up at -O2 as well).
Actually, the only thing that really blows up is that enemy of scalability, VRP.
With -O2 -fno-tree-{pre,fre,vrp}, the slowest part of the compiler on
this test case ar
This removes the need for FRE to compute AVAIL_OUT which can
consume an unreasonable amount of memory for testcases like
int foo (int a)
{
int b = 0;
#define X if (a) b = b + 1;
#define XX X X X X X X X X X X
#define XXX XX XX XX XX XX XX XX XX XX XX
#define XXX XXX XXX XXX XXX XXX XXX XXX
12 matches
Mail list logo
