<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 05/26/2017 04:27 PM, Matthias Braun
wrote:<br>
</div>
<blockquote
cite="mid:F9B6B751-10AE-4569-B41F-1BA1D31C7728@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On May 26, 2017, at 2:02 PM, Hal Finkel <<a
moz-do-not-send="true" href="mailto:hfinkel@anl.gov"
class="">hfinkel@anl.gov</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<p class=""><br class="">
</p>
<div class="moz-cite-prefix">On 05/26/2017 03:02 PM,
Matthias Braun wrote:<br class="">
</div>
<blockquote
cite="mid:DD8591B3-E4F1-47B3-A49B-79BEE1472F85@apple.com"
type="cite" class=""> <span style="font-family:
Calibri, sans-serif; font-size: 11pt;" class=""> </span><br
class="">
<div class="">
<blockquote type="cite" class="">
<div class="WordSection1" style="page: WordSection1;
font-family: Helvetica; font-size: 12px;
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;">
<div style="margin: 0cm 0cm 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;"
class=""><span style="font-size: 11pt;
font-family: Calibri, sans-serif;" class="">Regarding
SDAG, and given that poison is already there,
we would need to adopt a similar solution to
the IR. Maybe right now we can get away with
it because nsw is not exploited significantly
(as you say). Just because there</span><span
style="font-size: 11pt;" class="">’</span><span
style="font-size: 11pt; font-family: Calibri,
sans-serif;" class="">s no explicit poison in
SDAG, just having nsw is sufficient to cause
miscompilations when combined with other
transformations.<o:p class=""></o:p></span></div>
<div style="margin: 0cm 0cm 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;"
class=""><span style="font-size: 11pt;
font-family: Calibri, sans-serif;" class="">See,
for example, this bug report for InstCombine
regarding select+nsw:<span
class="Apple-converted-space"> </span><font
class="" color="#800080"><u class=""><a
moz-do-not-send="true"
href="https://bugs.llvm.org/show_bug.cgi?id=31633"
class="">https://bugs.llvm.org/show_bug.cgi?id=31633</a></u></font></span></div>
</div>
</blockquote>
<div class=""><br class="">
</div>
Poison/Undef at the CodeGen level is a very
interesting discussion! I don't think there is any
documentation about posion/undef at the CodeGen level
and I haven't discussed this much with others, so I'd
like to hear further feedback:</div>
<div class=""><br class="">
</div>
<div class="">- I think we should not introduce a notion
of poison (which I would call "delayed UB") at the
SelectionDAG/CodeGen level[1]</div>
<div class="">- Instructions either produce UB
immediately, so while there are nsw/nuw flags on
SelectionDAG arithmetic operatiosn I think we can only
assume that they produce a target specific value on
overflow, but not arbitrary behavior. Instructions
that can produce UB should marked "hasSideEffect" and
code motion around it be limited.</div>
</blockquote>
<br class="">
You mean like every integer division? Having arbitrary
side effects seems too strong.<br class="">
</div>
</div>
</blockquote>
<div>If we can model it more precise sure. But in principle if
you divide by zero many CPUs will trap immediately.</div>
</div>
</blockquote>
<br>
We don't want to limit our ability to move memory references around
integer division (for scheduling, etc.).<br>
<br>
<blockquote
cite="mid:F9B6B751-10AE-4569-B41F-1BA1D31C7728@apple.com"
type="cite">
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class=""> <br
class="">
<blockquote
cite="mid:DD8591B3-E4F1-47B3-A49B-79BEE1472F85@apple.com"
type="cite" class="">
<div class="">- Typical optimization scenarios like
establishing loop trip count bounds for which
poison/UB is helpful should not matter for CodeGen.</div>
<div class="">- I don't have any evidence that
optimizations in CodeGen require a model of poison to
work. If someone can given me a counter example then
I'd be hard pressed to disable the optimization in MI
and push it towards the IR level.</div>
</blockquote>
<br class="">
I'm not sure it is always possible to push these
optimizations to the IR level, at least not without adding
more Value* ties to instructions (e.g. what we do with
MMOs). I have some experience, for example, taking
optimizations taking advantage of hardware-counter-based
loops and moving into the IR level (so that we can take
advantage of ScalarEvolution), and it works to some
extent, but is also fairly hacky (the legality-checking
part of lib/Target/PowerPC/PPCCTRLoops.cpp, for example,
needs to understand what legalization will later do - it's
the best we can do right now, but it's a mess). If we had
better loop analysis at the MI level, this would be much
better. We already have some interesting MI-level passes
that do interesting things with loops
(lib/CodeGen/MachinePipeliner.cpp, for example).<br
class="">
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><br class="">
I think that we should have the same semantics here on
both the IR level and the MI level (whatever they are).
Having different semantics in this regard is going to be
confusing (and lead to subtle bugs because optimizations
valid in one part of the pipeline will be invalid in other
parts). These issues often come up around speculative
execution, for example, and I definitely think we need to
be able to deal with speculative execution at the MI level
(because speculation opportunities often come from
legalization/isel and pseudo-instruction expansion and
because the modeling is better at the MI level).<br
class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Does that mean a vreg (or even a physreg) can conceptually
hold a poison value? Given that failed to capture the
semantics at the IR level I have bad feelings about getting
this right at the MI level with all the additional machine
specific semantics. Reasoning about optimisations definitely
gets easier without poison and I'd really like to see some
good example first to motivate the maintenance burden.</div>
<div><br class="">
</div>
<div>A notion of unknown/unspecified value should be enough to
enable hoisting, we shouldn't need poison for that.</div>
</div>
</blockquote>
<br>
I think that we should get this right once, and when we do, we
should use these self-consistent semantics everywhere. I don't see
why machine-specific semantics make this harder or easier in general
(there are certainly instructions that won't have UB even when their
corresponding IR-level counterparts do, which might make things
easier, and instructions can have more dependencies to track, which
might make things harder).<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:F9B6B751-10AE-4569-B41F-1BA1D31C7728@apple.com"
type="cite">
<div>
<div><br class="">
</div>
<div>- Matthias</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>