Re: Ping: GAS/ia64: spurious dv conflict

[Jim Wilson <wilson at specifixinc dot com>]

On Tue, 2003-10-14 at 13:04, H. J. Lu wrote:
> I shouldn't add a mutex relation on a predicated compare. Here is
> an updated patch.

The DV handling is by far the most complicated part of the IA-64
assembler.  It would be a good idea to test this on some real code, such
as the kernel and glibc.  If you get extra messages you didn't have
before, or some go away that shouldn't have, then there is a problem
with your patch.  The kernel and glibc have some hand written IA-64 code
that can detect problems that gcc can't trigger.  Also, there is the
chance that this will expose latent kernel/glibc bugs which will have to
be fixed.

You put the update_qp_mutex call before the code for .and/.or compares
which is not correct.  cmp.and can only clear predicate registers, and
thus cmp.and will never destroy a mutex.  Also, in the .or case, you now
have a clear_qp_mutex call which is redundant with the update_qp_mutex
call.  I think the correct place to put the call to update_qp_mutex is
right before the test for .unc compares.  You can then handle fixing the
code for .and/.or as a separate problem.

I am guessing that you put the update_qp_mutex call before the .and/.or
compares because you need it even when one of the predicates is pr0. 
The right fix for that is to delete the if statement that checks for p1
== 0 or p2 == 0, as that code is bogus.  This forces us to make other
changes to avoid problems though, as we don't want to pass pr0 to
add_qp_mutex.

One way to do this is to force the mask for pr0 to be zero.  That is
      valueT p1mask = (p1 != 0) ? (valueT) 1 << p1 : 0;
      valueT p2mask = (p2 != 0) ? (valueT) 1 << p2 : 0;
I think this should work fine for the clear_qp_mutex and
clear_qp_implies calls, but does not work for the update_qp_mutex and
add_qp_mutex.  For add_qp_mutex, we need to make sure that we have two
mask bits.  For update_qp_mutex, if we don't have two mask bits, then we
can call clear_qp_mutex instead.  Or perhaps use the original mask bits
there since passing a pr0 mask bit to update_qp_mutex is likely to be
safe.

Actually, the add_qp_mutex call for the .and.orcm/.or.andcm case is
bogus too, since these compares are not guaranteed to create a mutex. 
So that call can be dropped.  That leaves only the last call and we can
check for two mask bits there before making the call.

The comment before the update_qp_mutex function needs fixing.  It refers
to P1 and P2, but there are no variables of that name.  It should
instead state that mask must contain two and only two bits, which
indicate two mutex predicate registers.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com