[AsmPrinter][ORE] use correct opcode name

[shchenz]

Summary

This is found on AIX when using opt-viewer.py.

On AIX, we have a pseudo instruction:

def BCTRL_LWZinto_toc:
  XLForm_2_ext_and_DForm_1<19, 528, 20, 0, 1, 32, (outs),
   (ins memri:$src), "bctrl\n\tlwz 2, $src", IIC_BrB,
   [(PPCbctrl_load_toc iaddr:$src)]>, Requires<[In32BitMode]>;

This pseudo instruction consists of two instructions: bctrl without any explicit operands and lwz with two operands 2 and $src.

getMnemonic introduced in D90040 returns a very strange opcode name for the above instruction, it is bctrl\n\tlwz 2, because AsmWriterInst::AsmWriterInst() treats $ as separator between opcode and operands.

So in the output YAML when generating remarks for asm-printer pass, we get:

- String:          "\n"
- String:          "bctrl\n\tlwz 2, "
- String:          ': '
- INST_bctrl
      lwz 2,: '1' 
- String:          "\n"

The invalid YAML will cause opt-viewer.py to work abnormally.

Seems AsmWriterInst::AsmWriterInst() treating $ as the only separator for opcode name and operands is right, because \n or \t are both treated as a normal character in opcode name or operands name, and \n\t exists very common in instruction mnemonic on some targets. so we can not fix the issue there.

And using bctrl as the opcode name for the pseudo instruction BCTRL_LWZinto_toc also follows the current design, the base class for the instruction form indicates:

// Two joined instructions; used to emit two adjacent instructions as one.
// The itinerary from the first instruction is used for scheduling and
// classification.
class I2 {
}

[jsji]

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

1418

Can we just use getToken()?

-        auto Name = (Twine("INST_") + KV.first.trim()).str();
+        auto Name = (Twine("INST_") + getToken(KV.first).first.trim()).str();

[shchenz]

address comment

[shchenz]

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

1418

Yes, getToken() is simpiler

[shchenz]

delete the unnecessary default paramater

[fhahn]

llvm/test/CodeGen/PowerPC/instruction-mix-remarks-BCTRL_LWZinto_toc.ll

9

shouldn't this be 2 instructions and the count for tld is missing at the moment?

I am not very familiar with PPC instructions, but the description contains:

This pseudo instruction consists of two instructions: bctrl without any explicit operands and lwz with two operands 2 and $src.

[shchenz]

llvm/test/CodeGen/PowerPC/instruction-mix-remarks-BCTRL_LWZinto_toc.ll

9

This is a known limitation for this kind of pseudo instructions for scheduling/classification, and now one more, for opcode mnemonic if we want to get the name from getMnemonic

// Two joined instructions; used to emit two adjacent instructions as one.
// The itinerary from the first instruction is used for scheduling and
// classification.
class I2 {
}

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

if (CanDoExtraAnalysis) {
         if (A.second > B.second)
           return true;
         if (A.second == B.second)
           return StringRef(A.first) < StringRef(B.first);
         return false;
       });
       R << "BasicBlock: " << ore::NV("BasicBlock", MBB.getName()) << "\n";
       for (auto &KV : MnemonicVec) {
-        auto Name = (Twine("INST_") + KV.first.trim()).str();
+        auto Name = (Twine("INST_") + getToken(KV.first.trim()).first).str();
         R << KV.first << ": " << ore::NV(Name, KV.second) << "\n";
       }
       ORE->emit(R);
     }
   }
 
   EmittedInsts += NumInstsInFunction;
   MachineOptimizationRemarkAnalysis R(DEBUG_TYPE, "InstructionCount",

llvm/test/CodeGen/PowerPC/instruction-mix-remarks-BCTRL_LWZinto_toc.ll

 
 ; RUN: llc -verify-machineinstrs -mattr=-altivec -mtriple powerpc64-ibm-aix-xcoff \
 ; RUN:   -pass-remarks-output=%t -pass-remarks=asm-printer -mcpu=pwr4 -o - %s
 ; RUN: FileCheck --input-file=%t %s
 
 ; CHECK:  - String:          "\n"
 ; CHECK:  - String:          "bctrl\n\tld 2, "
 ; CHECK:  - String:          ': '
-; CHECK:  - INST_bctrl
-; CHECK:  ld 2,: '1'
+; CHECK:  - INST_bctrl:      '1'
 ; CHECK:  - String:          "\n"
 
 
 define void @callThroughPtrWithArgs(void (i32, i16, i64)* nocapture) {
   tail call void %0(i32 signext 1, i16 zeroext 2, i64 3)
   ret void
 }