<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 26, 2017, at 2:02 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" class="">hfinkel@anl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" 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="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" 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><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><br class=""></div><div>- Matthias</div></div></body></html>