[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