On Thu, 2011-12-08 at 15:18 +0100, Jakub Jelinek wrote:
> On Thu, Dec 08, 2011 at 03:11:44PM +0100, Richard Guenther wrote:
> > >> > Another nit (sorry I didn't see this before :-/) :
> > >> >
> > >> > > + expr->ops.phi.args = (tree *) xcalloc (nargs, sizeof (tree));
> > >> >
> > >> > This l
On Thu, Dec 08, 2011 at 03:11:44PM +0100, Richard Guenther wrote:
> >> > Another nit (sorry I didn't see this before :-/) :
> >> >
> >> > > + expr->ops.phi.args = (tree *) xcalloc (nargs, sizeof (tree));
> >> >
> >> > This leaks, because you missed to add freeing to free_expr_hash_elt.
> >> >
On Mon, Dec 5, 2011 at 3:52 PM, William J. Schmidt
wrote:
>
>
> On Mon, 2011-12-05 at 08:36 -0600, William J. Schmidt wrote:
>>
>> On Mon, 2011-12-05 at 14:59 +0100, Michael Matz wrote:
>> > Hi,
>> >
>> > On Fri, 2 Dec 2011, William J. Schmidt wrote:
>> >
>> > > > on top of your current version.
On Mon, 2011-12-05 at 08:36 -0600, William J. Schmidt wrote:
>
> On Mon, 2011-12-05 at 14:59 +0100, Michael Matz wrote:
> > Hi,
> >
> > On Fri, 2 Dec 2011, William J. Schmidt wrote:
> >
> > > > on top of your current version. That ought to remove the added PHI
> > > > expressions (and only t
On Mon, 2011-12-05 at 14:59 +0100, Michael Matz wrote:
> Hi,
>
> On Fri, 2 Dec 2011, William J. Schmidt wrote:
>
> > > on top of your current version. That ought to remove the added PHI
> > > expressions (and only them) from the hash table but retain the
> > > information of equality in the
Hi,
On Fri, 2 Dec 2011, William J. Schmidt wrote:
> > on top of your current version. That ought to remove the added PHI
> > expressions (and only them) from the hash table but retain the
> > information of equality in the const_or_copies_stack. Checking the BB
> > wouldn't be required then.
Hi,
On Fri, 2 Dec 2011, Jeff Law wrote:
> So while continuing to have the phis in the available expression table
> is not useful beyond the current block, the equivalency created when a
> redundant PHI is encountered is useful to keep.
That's why I said to only clear the avail_exprs stack/vect
On Fri, 2011-12-02 at 13:46 -0700, Jeff Law wrote:
> On 12/02/11 12:27, William J. Schmidt wrote:
>
> >
> > Erm, wait. How are PHIs in different blocks going to have the
> > same incoming edges? (I was thinking of control dependence edges,
> > but these are just regular control flow incoming
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/02/11 12:27, William J. Schmidt wrote:
>
> Erm, wait. How are PHIs in different blocks going to have the
> same incoming edges? (I was thinking of control dependence edges,
> but these are just regular control flow incoming edges, right?) So
OK, one more version. This removes the basic block test and instead
implements Michael's suggestion:
On Fri, 2011-12-02 at 18:40 +0100, Michael Matz wrote:
> But I wonder why it's not enough to just do a push/pop sequence on
> avail_exprs_stack around your new PHI processing in dom_opt_enter_blo
On Fri, 2011-12-02 at 13:08 -0600, William J. Schmidt wrote:
>
> On Fri, 2011-12-02 at 11:28 -0700, Jeff Law wrote:
> > On 12/02/11 11:10, William J. Schmidt wrote:
> > >
> > >>
> > >> I see a mention of creating equivalences for redundant PHIs? Are
> > >> we just trying to determine that two P
On Fri, 2011-12-02 at 11:28 -0700, Jeff Law wrote:
> On 12/02/11 11:10, William J. Schmidt wrote:
> >
> >>
> >> I see a mention of creating equivalences for redundant PHIs? Are
> >> we just trying to determine that two PHIs are going to result in
> >> the same value?
> >
> > Jeff, see comment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/02/11 11:10, William J. Schmidt wrote:
>
>>
>> I see a mention of creating equivalences for redundant PHIs? Are
>> we just trying to determine that two PHIs are going to result in
>> the same value?
>
> Jeff, see comment #37 in
> http://gcc.
On Fri, 2011-12-02 at 10:52 -0700, Jeff Law wrote:
> On 12/02/11 10:40, Michael Matz wrote:
> > Hi,
> >
> > On Fri, 2 Dec 2011, William J. Schmidt wrote:
> >
> >> It seems like a fair amount of rip-up to avoid keeping the PHI
> >> state around between blocks, so I just check to ensure the PHI
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/02/11 10:40, Michael Matz wrote:
> Hi,
>
> On Fri, 2 Dec 2011, William J. Schmidt wrote:
>
>> It seems like a fair amount of rip-up to avoid keeping the PHI
>> state around between blocks, so I just check to ensure the PHI
>> definitions occur
Hi,
On Fri, 2 Dec 2011, William J. Schmidt wrote:
> It seems like a fair amount of rip-up to avoid keeping the PHI state
> around between blocks, so I just check to ensure the PHI definitions
> occur in the same block before recording their equivalence.
Then you should at least mix the BB num
Sorry for the previous brain-fart! Here's a revised patch.
It seems like a fair amount of rip-up to avoid keeping the PHI state
around between blocks, so I just check to ensure the PHI definitions
occur in the same block before recording their equivalence.
lookup_avail_expr may return a constant
On Fri, 2011-12-02 at 14:59 +0100, Michael Matz wrote:
> Hi,
>
> On Fri, 2 Dec 2011, William J. Schmidt wrote:
>
> > > > - tree def = gimple_get_lhs (stmt);
> > > > + /* If this is a PHI, we only want to consider it if all of its
> > > > + arguments are SSA names (which are known to be de
Hi,
On Fri, 2 Dec 2011, William J. Schmidt wrote:
> > > - tree def = gimple_get_lhs (stmt);
> > > + /* If this is a PHI, we only want to consider it if all of its
> > > + arguments are SSA names (which are known to be defined in a
> > > + single place). This avoids errors when dealing
On Fri, 2011-12-02 at 10:24 +0100, Richard Guenther wrote:
> On Thu, Dec 1, 2011 at 11:13 PM, William J. Schmidt
> wrote:
> > Greetings,
> >
> > Bug 39976 reported a degradation to 200.sixtrack wherein a hot
> > single-block loop is broken into two blocks. Investigation showed the
> > cause to
On Thu, Dec 1, 2011 at 11:13 PM, William J. Schmidt
wrote:
> Greetings,
>
> Bug 39976 reported a degradation to 200.sixtrack wherein a hot
> single-block loop is broken into two blocks. Investigation showed the
> cause to be a redundant PHI statement in the block, which the
> tree-outof-ssa logic
Greetings,
Bug 39976 reported a degradation to 200.sixtrack wherein a hot
single-block loop is broken into two blocks. Investigation showed the
cause to be a redundant PHI statement in the block, which the
tree-outof-ssa logic doesn't handle well. Currently we don't have code
following the intro
22 matches
Mail list logo