Describe the bug
The output produced by the printRaw function of various TypeOp subclasses is ambiguous. For example, either INT_LESS, INT_SLESS or FLOAT_LESS could have produced the line u0x10000012:1(0x800fb41c:61) = r3(0x800fb40c:19) < #0x0. This can be observed when using the decomp_dbg binary.

To Reproduce
Steps to reproduce the behavior:

1. Compile decomp_dbg:
   1. Go to SLEIGHHOME/Ghidra/Features/Decompiler/src/decompile/cpp
   2. Run make decomp_dbg
2. Extract example.xml from example.zip and save it somewhere
3. Start the decomp_dbg program
4. restore <path_to_example_xml>
5. load function main
6. print raw
7. See that the same line is printed 3 times, and it is impossible to tell from this output alone what comparison is INT_LESS, INT_SLESS and FLOAT_LESS.

Expected behavior
I expected to quickly see the difference between INT_LESS, INT_SLESS and FLOAT_LESS, perhaps using <, s< and f< respectively.

Observed behavior
The output of print raw, with all unrelated PCode operations removed. The first < is FLOAT_LESS, the second is INT_SLESS, and the third is INT_LESS. While it might be possible to infer that the first < is FLOAT_LESS based on the name of the inputs, it is much harder (impossible?) to differentiate between the latter two.

0
Basic Block 0 0x00101139-0x001011ca
...
0x00101177:2f:    u0x00018a80:1(0x00101177:2f) = XMM0_Da(free) < XMM1_Da(free)
...
0x00101189:44:    CF(0x00101189:44) = EDX(free) < EAX(free)
...
0x00101189:47:    SF(0x00101189:47) = u0x00029800:4(free) < #0x0:4
...

Attachments
The source code of the example program is attached, as well as the xml obtained from compiling it with gcc, opening it in Ghidra and clicking "Debug Function Decompilation". These files are zipped into example.zip.

Environment:

• Ghidra Version: 10.2.3
• Ghidra Origin: locally built

Additional context
This ambiguity occurs several times. It seems that the issue of ambiguous printRaw output was detected previously, which caused INT_RIGHT and INT_SRIGHT to be represented by different symbols (>> and s>> respectively). As such, I think that a similar solution could be implemented for the remaining ambiguities. For example: INT_LESS could use <, INT_SLESS could use s< and FLOAT_LESS could use f<.

To find all ambiguities, I went through all classes defined in typeop.hh and described their printRaw representation. The resulting table is shown below. This table shows that there are 10 ambiguous symbols: (unary)-, ==, !=, <, <=, +, (binary)-, *, / and %. These ambiguities always come from PCode operations that only differ on whether the operation is signed or unsigned, or whether it is an operation on integers or floating point numbers.