<div dir="ltr"><div><div><div>I don't understand the long-term practical implications of this. One of these operations is kind of important to me so I'll ask about it specifically.<br></div>The shufflevector with undef elements in the shuffle mask seems to me like quite a useful thing. We certainly make use of it in the PPC back end. It seems reasonable to me that if I want the result to have a few elements of the input vectors in specific element indices, that those should have well defined values. For those that I don't care about, the back end should be allowed to put any element there (and decision for which should be up to the back end - i.e. which shuffle can be handled efficiently). On PPC, we have a number of instructions that can perform a shuffle with a single instruction - others are handled with a constant-pool load and a generic shuffle instruction. We detect masks we can handle and utilize undef as a "this certainly matches" type of value for any index.<br><br></div><div>So my question is whether any of this would change and if so, how it would change.<br><br></div><div>N<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 6, 2017 at 11:11 AM, Nuno Lopes via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Lately we have come to realize how undef makes our life complicated..<br>
Therefore in this email we propose to change the behavior of a few<br>
instruction to yield poison instead of undef in error cases.  This follows<br>
the suggestion of Eli in <a href="https://reviews.llvm.org/D33654" rel="noreferrer" target="_blank">https://reviews.llvm.org/D3365<wbr>4</a>.<br>
<br>
Why is undef so bad?<br>
- I believe it's not possible to make newgvn correct with undef. See for<br>
example the discussion here: <a href="https://bugs.llvm.org/show_bug.cgi?id=33165" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug<wbr>.cgi?id=33165</a><br>
- A bunch of optimizations are correct with poison but not with undef (see<br>
John's blog posts, my talk at LLVM conf last year, our recent paper on PLDI,<br>
etc)<br>
<br>
This proposal is not very radical; it's just to change a few error behaviors<br>
to poison and shouldn't have any practical effect for the time being. (so<br>
the change is documentation only)<br>
Later we can continue the work until we have completely removed undef.  Even<br>
if we don't go there, it's generally a good idea to reduce the usage of<br>
undef and replace it with posion whenever possible.<br>
<br>
So we propose to change the following from undef to poison:<br>
- insertelement/extractelement (element index out of range)<br>
- shufflevector (undef elements in shuffle mask)<br>
- alloca (allocating zero bytes) ?<br>
- load (load value with different type from written value)<br>
- GEP inrange<br>
- fptrunc/fptoui/fptosi/uitofp/s<wbr>itofp (overflow) ?<br>
- llvm.ctlz.* and friends (is_zero_undef) ?<br>
<br>
Some of these are no brainers, others may need a bit of discussion.<br>
<br>
Please let us know if you have thoughts and/or concerns about this.<br>
<br>
Thanks,<br>
Nuno <br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div>