------- Comment #16 from law at redhat dot com 2006-11-08 18:29 -------
Subject: Re: bootstrap comparision fails with
"-ftree-vectorize -maltivec" on ppc
On Wed, 2006-11-08 at 11:33 +0000, irar at il dot ibm dot com wrote:
>
> ------- Comment #14 from irar at il dot ibm dot com 2006-11-08 11:33 -------
> (In reply to comment #11)
> > 1. Put a breakpoint in tree_ssa_cd_dce when compiling the
> > offending function from recog.c. When that breakpoint
> > triggers issue:
> > verify_ssa (true)
> > I can't see any way for that to fail, but better safe than
> > sorry.
>
> It fails...
[ ... ]
> (gdb) p debug_generic_stmt (0xf74510f0)
> # VUSE <SFT.1940D.29535>;
> # VUSE <TMT.1945D.29540_551>;
> opD.24623_172 = recog_dataD.15550.operandD.15539[opnoD.24621_29];
>
Ah. I had discounted this scenario as I thought this class of
problems had been fixed.
We've got an operand inside a VUSE which was never placed into
SSA form. This typically occurs when a pass mucks around with
aliasing information. The vectorizer has been problematical
in this respect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26197
I think there are links inside that PR which point to other instances
of this underlying problem.
Anyway, what typically happens is the aliasing information gets
mucked up by an early pass, but the affected statements aren't
marked as modified and thus the mucked up aliasing information
isn't exposed until some later pass (typically SSA updates due
to jump threading) marks the statement as modified and rebuilds
the operand cache, exposing the non-SSA operand. The pass
following jump threading typically core dumps or triggers an
assert like we're seeing in DCE.
Because of the hidden nature of this problem it can be difficult
to determine which pass mucked up the aliasing information.
I think the easiest way to at least find out what pass is mucking
things up is to insert some code like this at the start of verify_ssa
FOR_EACH_BB (bb)
for (bsi = bsi_start (bb); ! bsi_end_p (bsi); bsi_next (&bsi))
update_stmt (bsi_stmt (bsi));
In fact, one could argue that such code really belongs at the
start of verify_ssa permanently.
Hopefully you'll get a checking failure much earlier. At the least
it'll allow you to look at the dump files for the first reference to
SFT.1940D.29535 that is not in SSA form.
If I had to venture a guess, my money would be on the vectorizer
being the culprit here.
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
