[Bug middle-end/43760] [4.6 regression] New test failures

["wilson at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #4 from wilson at codesourcery dot com  2010-04-20 01:54 -------
Subject: Re:  [4.6 regression] New test failures

On Tue, 2010-04-20 at 00:01 +0000, sje at cup dot hp dot com wrote:
> Any ideas on how to fix the compiler?  The best idea I could come up with was
> to check each basic block to see if there are any conditional sets of predicate
> registers in it and add pred.rel.mutex lines for those registers.  If we add
> pred.rel.mutex lines for all used predicate registers we wind up adding a lot
> of unneeded pred.rel.mutex statements.

I haven't had a chance to look at all of the details yet.

I believe that we only need to handle the case when one mutex pair is
used to create another one, e.g. something like
       (p17) cmp.geu p6, p7 = r42, r51
       (p16) cmp.gtu p6, p7 = r42, r51
We also only need to handle the case where we have a call-clobbered
mutex pair, e.g. p6/p7 in this case, and there was a call insn in
between here and any previous set of p6/p7.

Currently, we only insert pred.rel.mutex lines at the beginning of basic
blocks that start with labels.  So now we also need to emit them after
such sequences, or alternatively after calls.

I'm not sure if the assembler is wrong here.  mutex just means that we
will never have both p16 and p17 set at the same time.  So there are 3
possibilities, p16 true, p17 true, neither true.  If p16 is true, then
clearly p6/p7 will be mutex.  Likewise if p17 is true.  But if neither
is true, then p6/p7 will be unmodified, and hence aren't guaranteed to
be mutex unless they were already mutex before these lines.  This is why
it only fails when we have a call-clobbered mutex pair after an
intervening call, as now we don't know anything about the previous
values of p6/p7.

If we know that p16/p17 were set in a simple compare, then we will know
that 1 and only 1 will be true, which is a stronger condition than
mutex, and in this case p6/p7 will be mutex.  There is no
standard .pred.rel syntax for this though, which means that if the
p16/p17 set was in a different basic block, and we have only
the .pred.rel.mutex line inserted by the compiler, then the assembler
can't prove that p6/p7 will be mutex after this point.  I'm not eager to
extend the assembler syntax to fix this, and rewrite the DV code in the
assembler, so I'm hoping that we can fix it in the compiler by emitting
another .pred.rel.mutex line in this case.  This hopefully doesn't
happen too often and isn't too hard.

OK, maybe I have studied it a little, but I need to look at this a bit
more before I'm sure I understand everything that is going on here.

Jim


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760