[llvm-bugs] [Bug 39829] New: [llvm-mca] LSUnit: Consider using field `LoadLatency` from MCSchedModel to simulate the latency of load instructions.

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Nov 28 10:51:11 PST 2018


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

            Bug ID: 39829
           Summary: [llvm-mca] LSUnit: Consider using field `LoadLatency`
                    from MCSchedModel to simulate the latency of load
                    instructions.
           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

Class LSUnit doesn't know about the latency of load instructions. So, it
conservatively/pessimistically assumes that the latency of a load opcode
matches the instruction latency. 

In the absence of cache misses (i.e. L1I/L1D/iTLB/dTLB hits/misses),
and load/store conflicts, the latency of a load is determined by the depth
of the load pipeline. So, we could use field `LoadLatency` in the
MCSchedModel to model that latency.
Field `LoadLatency` often matches the so-called 'load-to-use' latency from
L1D, and it usually already accounts for any extra latency due to data
forwarding.
When doing throughput analysis, `LoadLatency` is likely to
be a better predictor of load latency than instruction latency. This is
particularly true when simulating code with temporal/spatial locality of
memory accesses.
Using `LoadLatency` (instead of the instruction latency) is also expected
to improve the load queue allocation for long latency instructions with
folded memory operands.

-- 
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/20181128/9d329920/attachment.html>


More information about the llvm-bugs mailing list