[llvm-bugs] [Bug 44797] New: [MCA][CodeGenSchedule] Better handling of instructions with zero NumMicroOpcodes.

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=44797

            Bug ID: 44797
           Summary: [MCA][CodeGenSchedule] Better handling of instructions
                    with zero NumMicroOpcodes.
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llvm-mca
          Assignee: unassignedbugs at nondot.org
          Reporter: andrea.dibiagio at gmail.com
                CC: andrea.dibiagio at gmail.com, llvm-bugs at lists.llvm.org,
                    matthew.davis at sony.com

Field NumMicroOpcodes is currently used by mca to model the number of uOPs
dispatched from the uOp-Queue to the out of order backend.
>From a 'dispatch' point of view, an instruction with zero opcodes is still
valid; it simply doesn't consume any dispatch group slots.

However, mca doesn't expect an instruction with zero uOPs to consume pipeline
resources because it is seen as a contradiction.
In practice, it only makes sense if the instruction is eliminated and never
really executed. It may be that mca is being too conservative here. However I
believe that mca is right, and we should probably check that inconsistency in
CodeGenSchedule.cpp (when we also verify scheduling classes in general).

In the short term I plan to remove the check for MayLoad and MayStore in mca.
That check is probably too conservative: we already check if a zero-uops
instruction consumes any processor resources. Also, instructions with
unmodelled side-effects tend to also set the MayLoad/MayStore flags even if -
theoretically speaking - they might not even consume any hw resources in
practice.

In future we may want to implement different checks (possibly outside of mca)
and potentially revisit the logic in mca that verifies instructions.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200205/081b1267/attachment.html>