Re: ifcvt/crossjump patch: Fix PR 42496, 21803

[Jim Wilson <wilson at codesourcery dot com>]

On Tue, 2010-04-06 at 11:22 +0100, Bernd Schmidt wrote:
>   * Examine the testcase gcc.c-torture/compile/920625-1.c: it has
>     workarounds for an ia64 assembler bug related to predication.  The
>     same issue now also occurs in a libstdc++ testcase and two
>     libgfortran ones.  Jim - any ideas what to do about this?

Sorry, I didn't notice that there was a question for me in here.

There is a known problem that the assembler can't handle some complex
uses of predicate registers correctly.  However, fixing the assembler to
handle all known broken cases will require a complete rewrite of the
dependency violation code which is probably about a man-month of work,
and hence unlikely to happen.  This issue looks a bit simpler, and may
not require a complete rewrite, but this would take some research.

Mostly this has been OK because ifcvt wasn't smart enough to emit the
cases that the assembler couldn't handle.  If ifcvt is getting smarter,
and triggering the assembler bug more often, then we will have to do
something about this.

Meanwhile, there is a way to work around this in the compiler.  The
compiler can emit directives to tell the assembler about predicate
register relationships.  There is already some code for this in the
emit_predicate_relation_info function in ia64.c which is called during
md reorg.  This handles a couple of cases at the moment.

It looks like emit_predicate_relation_info needs to handle one more
case.  If we change
       (p17) cmp.geu p6, p7 = r42, r51
       (p16) cmp.gtu p6, p7 = r42, r51
to
       (p17) cmp.geu p6, p7 = r42, r51
       (p16) cmp.gtu p6, p7 = r42, r51
       .pred.rel.mutex p6, p7
Then the assembler will stop warning about the code.

It looks like the assembler is failing to handle this after a call insn,
because p6/p7 are call-clobbered.  p16/p17 are call saved, which in
theory should be enough, but the assembler apparently only gets this
right if it knows that p6/p6 are mutex beforehand.  In which case the
assembler can tell that each instruction individually does not destroy
the pre-existing mutex relationship and hence we still have a p6/p7
mutex at the end.  But if we don't know that p6/p7 are mutex beforehand,
then we have to keep track of a matrix of mutex relationships in order
to deduce that we end up with a p6/p7 mutex at the end, and the
assembler currently doesn't do that.  This part requires a major
rewrite.

I think all we need here is a bugzilla report against the compiler to
document that we don't handle this case correctly, and that it is
generating testsuite failures, and then when I or someone else has time
we can try to fix this problem in emit_predicate_relation_info.  We
should also remove the hack in gcc.c-torture/compile/920625-1.c when we
do this.

Jim