[llvm-bugs] [Bug 49524] New: [llvm-mca][in-order processors] Missing RCU checks, and issues with how OoO instructions are tracked.

[via llvm-bugs]

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

            Bug ID: 49524
           Summary: [llvm-mca][in-order processors] Missing RCU checks,
                    and issues with how OoO instructions are tracked.
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          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

In-order processor like cortex-a55 allow out-of-order execution of a few
FP/NEON instructions to avoid compulsory stalls due to their long latency.
In particular, the scheduling model for cortex-a55 declares a reorder buffer
with 64 entries.

```
def A55RCU : RetireControlUnit<64, 0>; 
```

When issuing instructions, the new InOrderIssueStage doesn't perform any checks
on the availability of the RCU. We should always check whether the RCU is
available before attempting to issue a new instruction. If the RCU is
unavailable, then we should stall the issue logic until RCU slots become
available again.

--

I might be wrong, but I think that there is another important issue with how
the RCU is currently simulated for in-order processors.

The way how it works now, is a bit counter-intuitive (at least in my opinion).
Basically, the RCU only seem to track instructions that CANNOT execute
out-of-order.
We probably don't need to do that (unless we want to limit the number of
instructions in-flight).

I don't have a cortex-a55 to do some tests, but my opinion is that the RCU
should probably _only_ track instructions that are executed OoO, to ensure that
writes are always architecturally committed in program order.

By construction, normal instructions that cannot execute OoO, are guaranteed to
issue and retire in program order. I left a comment in
https://bugs.llvm.org/show_bug.cgi?id=41796 explaining how I think there is a
bug due to the lack of checks for structural hazards which would be normally
required to prevent reaching the write-back stage out-of-order.

-- 
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/20210310/310057c0/attachment.html>