<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 - [MCA][MCSchedModel] Add a optional DelayCycles vector for SchedWriteRes."
href="https://bugs.llvm.org/show_bug.cgi?id=45873">45873</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[MCA][MCSchedModel] Add a optional DelayCycles vector for SchedWriteRes.
</td>
</tr>
<tr>
<th>Product</th>
<td>tools
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</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>llvm-mca
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>andrea.dibiagio@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>andrea.dibiagio@gmail.com, llvm-bugs@lists.llvm.org, matthew.davis@sony.com
</td>
</tr></table>
<p>
<div>
<pre>This was suggested by Andy in
<a href="https://lists.llvm.org/pipermail/llvm-dev/2020-May/141487.html">https://lists.llvm.org/pipermail/llvm-dev/2020-May/141487.html</a>
The idea is to add a DelayCycles vector to SchedWriteRes to indicate the
relative start cycle for each reserved resource. That would effectively model
dependent uOps.
At the moment, it is not possible to delay the consumption of specific hardware
resources. The expectation is that resource consumption always starts at
relative cycle #0 (i.e. relative to the instruction issue cycle).
A vector of DelayCycles (if present) would contain unsigned integer values
(ideally one per each processor resource consumed by a write), and those values
would be offsets in cycles relative to the issue cycle.
The absence of a DelayCycles vector would be semantically equivalent to a
all-zeroes DelayCycles vector.
This would require a mostly mechanical change in tablegen to teach how to parse
and semantically analyze this new concept. The subtarget-emitter would
eventually generate information about those delay-cycles in a table.
A more complicated change would be needed for the bookkeping logic in mca
(HardwareUnits/ResourceManager.cpp).
Most x86 processor models would probably benefit from this change. SchedWrite
definitions which might benefit from this change are writes for horizontal
operations. On most x86 processors, horizontal add/sub is usually decoded into
a pair of shuffles uOPs followed by a single (data-dependent) vector ADD uOP.
The ADD uOP doesn't execute immediately because it needs to wait for the other
two shuffle uOPs. So the ALU pipe is still available at relative cycle #0, and
it is only consumed by the horizontal operation starting from relative cycle
#1.
This was just an example. There are probably various write descriptors (not
just writes for microcoded instructions) which would benefit from this change.
This will also solve a number of known problems with the descriptors in
Haswell/Broadwell. Last but not least it would allow us to simplify the
bookkeping logic in llvm-mca and get rid of the not-so-nice "reserved" bit for
processor resource groups. More details about those two issues can be found in
the above mentioned llvmdev thread.</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>