<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 12/7/20 7:52 AM, Florian Hahn via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0B1D3A77-E798-4AF0-985E-DC445FFA954D@apple.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Hi,<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Dec 7, 2020, at 13:25, Sjoerd Meijer via
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org"
class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta charset="UTF-8" class="">
<div style="font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; text-decoration: none;
font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt;" class="">Hello,</div>
<div style="font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; text-decoration: none;
font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt;" class=""><br class="">
</div>
<div style="font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; text-decoration: none;
font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt;" class="">I would like to restrict LICM
in the number of memory operations it hoists out of a
loop. Blindly hoisting out all instructions out could
result in a lot of spilling/reloading, which is what I'd
like to avoid. We see this for example on (inner)loops
with small constant bounds that are unrolled. I am
drafting something in<span class="Apple-converted-space"> </span><a
href="https://reviews.llvm.org/D92488" id="LPlnk301063"
class="" moz-do-not-send="true">https://reviews.llvm.org/D92488</a>,
which contains a reduced version of my motivating example.</div>
<div style="font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; text-decoration: none;
font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt;" class="">It was brought to my attention
that LICM might not have any restrictions by design
because hoisting out all instructions could be some sort
of canonical form that other passes depend on, so sinking
back defs closer to their user(s) might be a back-end
problem. I was wondering if there are any opinions on
this.<br class="">
</div>
<div style="font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; text-decoration: none;
font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt;" class=""><br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>I think one key benefit of hoisting as much as possible is
that it enables/simplifies subsequent optimizations in the
middle-end (especially for memory operations). Limiting
hoisting is likely to have a bad knock-on effect on other
transformations.</div>
<div><br class="">
</div>
<div>Accurately estimating the number of spills in LICM is
probably going to be tricky and/or brittle. Another thing to
consider is that there are plenty of other transformations
that extend live-ranges of values, so they would also need to
also need updating.</div>
<div><br class="">
</div>
<div>Sinking in the backend would catch those cases naturally,
while making our lives easier in the middle-end. We already
have plenty of infrastructure to reason about register
pressure & co in CodeGen. As <span class="">Bardia
mentioned, currently there is limited support for
re-materialzing instructions.</span></div>
<div><span class=""><br class="">
</span></div>
<div><span class="">Besides that, I </span>don’t think there are
dedicated passes to move defs to uses to reduce register
pressure, beside the MachineScheduler. But the
MachineScheduler currently only operates on sub-regions of
basic blocks.</div>
<div><br class="">
</div>
<div>I think there would be potential for having a dedicated
pass to move defs across basic blocks to reduce register
pressure. I think we have most building blocks
(RegisterPressureTracker, MachineTraceMetrics for selecting a
likely trace through the function). But reasoning about moving
memory operations is probably going to be more difficult in
the backend than in the middle-end though unfortunately.</div>
</div>
</blockquote>
<p>I'd explored the notion of doing a register pressure aware global
code motion a while back. There's a bunch of hard cases, but
there's also a bunch of obvious profitable stuff too. I think
this is entirely realistic if someone wanted to devote to time.</p>
<p>I doubt this would solve the triggering case for this thread
though. Despite the framing as being about LICM, the transform
actually involved was store promotion. I suspect the issue is
that we simply haven't considered undoing store promotion in
MachineLICM. (I haven't looked, so this may be a false
statement.)</p>
<p>Philip<br>
</p>
</body>
</html>