This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] crash in coalesce_abnormal_edges, merge from mainline?
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: law at redhat dot com
- Cc: Andrew MacLeod <amacleod at redhat dot com>, Diego Novillo <dnovillo at redhat dot com>, Gerald Pfeifer <gerald at pfeifer dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Wed, 10 Sep 2003 13:15:06 -0400 (EDT)
- Subject: Re: [tree-ssa] crash in coalesce_abnormal_edges, merge from mainline?
- References: <200309101703.h8AH3F1A028847@speedy.slc.redhat.com>
On Wed, 10 Sep 2003 email@example.com wrote:
> In message <1063211660.30914.18.camel@p4>, Andrew MacLeod writes:
> >On Wed, 2003-09-10 at 12:30, Andrew MacLeod wrote:
> >> On Wed, 2003-09-10 at 11:32, Daniel Berlin wrote:
> >> Looking at each place where may_propagate_copy() is called, in virtually
> >> every instance that matters, we are processing the arguments of a PHI,
> "virtually every instance" is not good enough. We need to know for any
> arbitrary copy if one of its arguments is referenced in an abnormal PHI.
> >> which means have access to the edge that arguement comes across right
> >> there on the spot... so we could just check the flag on the edge and not
> >> do the copy propagate based on that.. Then we dont have this auxillary
> >> bit hanging around.
> No, you really need to set the bit -- you can't assume that you're only
> going to query this information at PHI nodes.
> What I want to know is why the code which sets this bit is not working
> in this case -- when we initialize a PHI argument (add_phi_arg) we query
> the edge flags and set SSA_NAME_OCCURS_IN_ABNORMAL_PHI appropriately.
This is what i'm trying to figure out. we don't have any abnormal edges
that we add phi arguments to (IE when we call add_phi_arg, the edge we
pass to it is not flagged as abnormal at any point in this testcase)
> So either something is bypassing add_phi_arg
Nope, we don't do that.
> or something is modifying an
> existing phi argument by replacing one variable with another -- which is
> copy propagation --
We do this on EPHI's, actually, before we turn them into PHI's (in order
to minimize the new SSA and phis we generate), so that's
where i'm looking now. If it's the problem, I might just turn it off, and
let copy prop + DCE do the extra work of eliminating the useless phis, so that i don't have to
worry about this problem.
Otherwise, i'd have to add an ephi flag for abnormal phis, and not replace
across them, etc.
> which in turn would imply that something is doing a
> copy propagation without checking the SSA_NAME_OCCURS_IN_ABNORMAL_PHI