[Bug middle-end/43760] [4.6 regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760 Steve Ellcey changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #9 from Steve Ellcey 2010-10-18 21:48:17 UTC --- Resolved by making IA64 more conservative in its bundling and not putting multiple (predicated) instructions in one bundle if they read/write the same register.
[Bug middle-end/43760] [4.6 regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760 --- Comment #8 from Steve Ellcey 2010-10-18 21:34:51 UTC --- Author: sje Date: Mon Oct 18 21:34:46 2010 New Revision: 165664 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165664 Log: 2010-10-18 Steve Ellcey PR target/36898 PR middle-end/43760 * config/ia64/ia64.c (rws_access_regno): Remove predicate check. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.c
[Bug middle-end/43760] [4.6 regression] New test failures
--- Comment #7 from sje at cup dot hp dot com 2010-09-02 18:26 --- I wonder if we should attack this from a different angle. We have been trying to make the .pred.mutex.rel info more accurate to avoid this warning. If we can't do that I wonder if we should make GCC more conservative about doing two predicated writes in a single instruction group. This would make the code slower but it might be an infrequent enough occurance that it doesn't matter. Also, I currently see gfortran.dg/maxlocval_3.f90 failing with this message and when I look at the assembly code, there are two predicated writes that are using two consecutive pr registers (p12 and p13) but they are not set in a single cmp instructions. They are set seperately and I believe that both could be true which would mean that we are generating invalid code. I am going to test a patch that changes rws_access_regno to not allow two predicated register write in the same instruction group. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug middle-end/43760] [4.6 regression] New test failures
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-02 10:36 --- So this is, after all, an assembler bug and not a GCC bug? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug middle-end/43760] [4.6 regression] New test failures
--- Comment #5 from wilson at gcc dot gnu dot org 2010-04-26 15:46 --- Created an attachment (id=20495) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20495&action=view) initial patch This patch fixes gcc.c-torture/compile/920625-1.c, but unfortunately doesn't fix any of the 3 failures reported in this PR. I will have to revise it and try again. I also noticed that we had support for an obsolete assembler errata warning, and removed that too in this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug middle-end/43760] [4.6 regression] New test failures
--- 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 +, 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
[Bug middle-end/43760] [4.6 regression] New test failures
--- Comment #3 from sje at cup dot hp dot com 2010-04-20 00:01 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug middle-end/43760] [4.6 regression] New test failures
--- Comment #2 from wilson at gcc dot gnu dot org 2010-04-19 23:28 --- gcc-c.torture/compiler/920625-1.c would also be failing for the same reason, except it has dg-prune-output hacks to discard the assembler warnings. We should fix the IA-64 compiler, and then eliminate these dg-prune-output hacks in this testcase. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug middle-end/43760] [4.6 regression] New test failures
--- Comment #1 from sje at cup dot hp dot com 2010-04-19 21:30 --- /var/tmp//ccGMk41W.s: Assembler messages: /var/tmp//ccGMk41W.s:201: Warning: Use of 'mov' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 18 /var/tmp//ccGMk41W.s:201: Warning: Only the first path encountering the conflict is reported /var/tmp//ccGMk41W.s:200: Warning: This is the location of the conflicting usage It looks like this is PR 36898. The warning is bogus in the sense that there is no real WAW dependency conflict but the assembler isn't able to figure that out on it's own without some help with better .pred.rel.mutex lines from the compiler. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-19 21:30:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug middle-end/43760] [4.6 regression] New test failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||ia64-linux Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
