<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - X86II::getMemoryOperandNo misses somewhat common memory operands"
   href="https://bugs.llvm.org/show_bug.cgi?id=36138">36138</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>X86II::getMemoryOperandNo misses somewhat common memory operands
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>new-bugs
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>unspecified
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Linux
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>enhancement
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>new bugs
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>chandlerc@gmail.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>craig.topper@gmail.com, llvm-bugs@lists.llvm.org
          </td>
        </tr></table>
      <p>
        <div>
        <pre>I had cause to use this API, and my current primary use case makes it important
to look at what instructions it *doesn't* handle but do return `true` for
`MI.mayLoad()`.

Some are obvious and working as intended: MFENCE, TRAP.

Some were surprising. These are MI.dump() outputs from building the test suite
+ SPEC:

(lots of FP80 stuff)
WARNING: unable to sanitize loading instruction:   %59:rfp80 = LD_Fp80m
%44:gr64, 4, %28:gr64_nosp, 0, %noreg, implicit-def dead %fpsw, debug-location
!5941; mem:LD10[%uglygep105106](align=16)(tbaa=!2343)
WARNING: unable to sanitize loading instruction:   %53:rfp80 = DIV_Fp80m64
%2:rfp80, %stack.5, 1, %noreg, 0, %noreg, implicit-def dead %fpsw,
debug-location !42; mem:LD8[FixedStack5]
WARNING: unable to sanitize loading instruction:   %62:rfp80 = SUBR_Fp80m64
%14:rfp80, %stack.8, 1, %noreg, 0, %noreg, implicit-def dead %fpsw,
debug-location !53; mem:LD8[FixedStack8]
WARNING: unable to sanitize loading instruction:   %63:rfp80 = ILD_Fp64m80
%stack.0, 1, %noreg, 0, %noreg, implicit-def dead %fpsw, debug-location !3617;
mem:LD8[FixedStack0]
WARNING: unable to sanitize loading instruction:   %127:rfp80 = MUL_Fp80m32
killed %126:rfp80, %71:gr64, 1, %noreg, 0, %noreg, implicit-def dead %fpsw,
debug-location !1957; mem:LD4[%ptr.0.lcssa](tbaa=!1261)

(this one really surprised me)
WARNING: unable to sanitize loading instruction:   %38:gr8 = ACQUIRE_MOV8rm
%rip, 1, %noreg,
@_ZGVZNK16ParameterHandler3getERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEE12empty_stringB5cxx11,
%noreg, debug-location !5338; mem:Volatile LD1[bitcast (i64*
@_ZGVZNK16ParameterHandler3getERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEE12empty_stringB5cxx11
to i8*)](align=8)

WARNING: unable to sanitize loading instruction:   REP_MOVSQ_64 implicit-def
dead %rcx, implicit-def dead %rdi, implicit-def dead %rsi, implicit %rcx,
implicit %rdi, implicit %rsi, debug-location !138


All of these seem to have reasonable memory operands to point at...

There is also one where I'm not really sure whether we should point at the
memory operands or not:
WARNING: unable to sanitize loading instruction:   TCRETURNmi64 %0:gr64_tc, 1,
%noreg, 16, %noreg, 0, <regmask %bh %bl %bp %bpl %bx %ebp %ebx %rbp %rbx %r12
%r13 %r14 %r15 %r12b %r13b %r14b %r15b %r12d %r13d %r14d %r15d %r12w %r13w
%r14w %r15w>, implicit %rsp, implicit %ssp, implicit %rdi, debug-location !73;
mem:LD8[%output_message9](tbaa=!11)


Anyways, mentioned this to Craig and it seemed worth filing a bug to track.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>