Here's a small patch to fix a spurious WAW hazard reported on this for p2: {.mmi cmp.eq.or.andcm p3,p2=r49,r39 cmp.ne.and p2,p1=r49,r36 nop.i 0 ;; } Index: tc-ia64.c =================================================================== RCS file: /cvs/src/src/gas/config/tc-ia64.c,v retrieving revision 1.190 diff -b -u -r1.190 tc-ia64.c --- tc-ia64.c 1 Feb 2007 14:12:18 -0000 1.190 +++ tc-ia64.c 3 Feb 2007 10:06:06 -0000 @@ -9001,14 +9001,18 @@ int p2 = CURR_SLOT.opnd[1].X_add_number - REG_P; int or_andcm = strstr (idesc->name, "or.andcm") != NULL; int and_orcm = strstr (idesc->name, "and.orcm") != NULL; + int and = strstr (idesc->name, "and") != NULL; + int or = strstr (idesc->name, "or") != NULL; if ((idesc->operands[0] == IA64_OPND_P1 || idesc->operands[0] == IA64_OPND_P2) && p1 >= 1 && p1 < 16) { specs[count] = tmpl; - specs[count].cmp_type = - (or_andcm ? CMP_OR : (and_orcm ? CMP_AND : CMP_NONE)); + specs[count].cmp_type = (or_andcm ? CMP_OR : + (and_orcm ? CMP_AND : + (and ? CMP_AND : + (or ? CMP_OR : CMP_NONE)))); specs[count++].index = p1; } if ((idesc->operands[1] == IA64_OPND_P1 @@ -9016,8 +9020,10 @@ && p2 >= 1 && p2 < 16) { specs[count] = tmpl; - specs[count].cmp_type = - (or_andcm ? CMP_AND : (and_orcm ? CMP_OR : CMP_NONE)); + specs[count].cmp_type = (or_andcm ? CMP_AND : + (and_orcm ? CMP_OR : + (and ? CMP_AND : + (or ? CMP_OR : CMP_NONE)))); specs[count++].index = p2; } } @@ -9123,14 +9129,18 @@ int p2 = CURR_SLOT.opnd[1].X_add_number - REG_P; int or_andcm = strstr (idesc->name, "or.andcm") != NULL; int and_orcm = strstr (idesc->name, "and.orcm") != NULL; + int and = strstr (idesc->name, "and") != NULL; + int or = strstr (idesc->name, "or") != NULL; if ((idesc->operands[0] == IA64_OPND_P1 || idesc->operands[0] == IA64_OPND_P2) && p1 >= 16 && p1 < 63) { specs[count] = tmpl; - specs[count].cmp_type = - (or_andcm ? CMP_OR : (and_orcm ? CMP_AND : CMP_NONE)); + specs[count].cmp_type = (or_andcm ? CMP_OR : + (and_orcm ? CMP_AND : + (and ? CMP_AND : + (or ? CMP_OR : CMP_NONE)))); specs[count++].index = p1; } if ((idesc->operands[1] == IA64_OPND_P1 @@ -9138,8 +9148,10 @@ && p2 >= 16 && p2 < 63) { specs[count] = tmpl; - specs[count].cmp_type = - (or_andcm ? CMP_AND : (and_orcm ? CMP_OR : CMP_NONE)); + specs[count].cmp_type = (or_andcm ? CMP_AND : + (and_orcm ? CMP_OR : + (and ? CMP_AND : + (or ? CMP_OR : CMP_NONE)))); specs[count++].index = p2; } } @@ -9587,22 +9599,28 @@ int p2 = CURR_SLOT.opnd[1].X_add_number - REG_P; int or_andcm = strstr (idesc->name, "or.andcm") != NULL; int and_orcm = strstr (idesc->name, "and.orcm") != NULL; + int and = strstr (idesc->name, "and") != NULL; + int or = strstr (idesc->name, "or") != NULL; if (p1 == 63 && (idesc->operands[0] == IA64_OPND_P1 || idesc->operands[0] == IA64_OPND_P2)) { specs[count] = tmpl; - specs[count++].cmp_type = - (or_andcm ? CMP_OR : (and_orcm ? CMP_AND : CMP_NONE)); + specs[count].cmp_type = (or_andcm ? CMP_OR : + (and_orcm ? CMP_AND : + (and ? CMP_AND : + (or ? CMP_OR : CMP_NONE)))); } if (p2 == 63 && (idesc->operands[1] == IA64_OPND_P1 || idesc->operands[1] == IA64_OPND_P2)) { specs[count] = tmpl; - specs[count++].cmp_type = - (or_andcm ? CMP_AND : (and_orcm ? CMP_OR : CMP_NONE)); + specs[count].cmp_type = (or_andcm ? CMP_AND : + (and_orcm ? CMP_OR : + (and ? CMP_AND : + (or ? CMP_OR : CMP_NONE)))); } } else
The same patch is at http://sourceware.org/ml/binutils/2007-02/msg00035.html
This looks right to me. The bug is curious, but apparently we only handle or.andcm and and.orcm because these are the only parallel compares that gcc is smart enough to emit. So when we added support for these parallel compare types to gcc, we only extended gas to handle these, and forgot to handle the others at the same time. The code could maybe be a bit more efficient. We have 4 strstr calls, then a conditional expression with 4 ? tests. This isn't a reason to refuse it though. There is one important consideration here about copyright assignments. This was originally sent from an in.ibm.com address, and then from a freenet.de address. I need to be sure about who wrote the patch, and that they have a valid copyright assignment. If this was written by an IBM employee, then it presumably falls under the IBM corporate assignment.
The patch is written by IBM employee. My alternate email id is kchowkse_at_in_ibm_com