<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 03:02 PM, Matthias Braun
wrote:<br>
</div>
<blockquote
cite="mid:DD8591B3-E4F1-47B3-A49B-79BEE1472F85@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<span style="font-family: Calibri, sans-serif; font-size: 11pt;"
class=""> </span><br class="">
<div>
<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><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><br class="">
</div>
<div>- I think we should not introduce a notion of poison (which I
would call "delayed UB") at the SelectionDAG/CodeGen level[1]</div>
<div>- 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>
You mean like every integer division? Having arbitrary side effects
seems too strong.<br>
<br>
<blockquote
cite="mid:DD8591B3-E4F1-47B3-A49B-79BEE1472F85@apple.com"
type="cite">
<div>- Typical optimization scenarios like establishing loop trip
count bounds for which poison/UB is helpful should not matter
for CodeGen.</div>
<div>- 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>
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>
<br>
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>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:DD8591B3-E4F1-47B3-A49B-79BEE1472F85@apple.com"
type="cite">
<div><br class="">
</div>
<div>- Matthias</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>