<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div class="moz-cite-prefix">On 11/27/19 2:10 AM, Eli Friedman via llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:MWHPR02MB2479E68AFC95EEE2F2ABE6D4CA440@MWHPR02MB2479.namprd02.prod.outlook.com">
<pre class="moz-quote-pre" wrap="">The shuffle mask of a shufflevector is special: it's required to be a constant in a specific form. From LangRef: "The shuffle mask operand is required to be a constant vector with either constant integer or undef values." So really, we can resolve this any way we want; "undef" in this context doesn't have to mean the same thing as "undef" in other contexts. Formally, at the LangRef level, we can state that the shuffle mask is not an operand of a shufflevector; instead, it's not a value at all. It's just a description of the shuffle, defined with a grammar similar to a vector constant. Then we can talk about shuffle masks where an element is the string "undef", unrelated to the general notion of an undef value.</pre>
</blockquote>
<p>That is something that has been on my mind for a while now. You can ask the same why we use 'undef' for phi nodes. Eg it is legal to turn this:</p>
<p><font size="+2"><tt> %x = phi i32 [ 0, A ], [ undef, B ]</tt></font></p>
<p>into</p>
<p><font size="+2"><tt> %x = phi i32 [ 0, A ], [ 1, B ]</tt></font></p>
<p>which arguing by the intended semantics of phi nodes should be an illegal transformation but isn't in LLVM.</p>
<p>I think that we abuse the 'undef' (symbol) to mute instruction parameters whenever that parameter doesn't matter but we are shy of 'some' value handle to feed the operand slot.<br>
</p>
<p>IMHO for those cases, we need a proper '\bot' constant that denotes the absence of a concrete value as opposed to 'undef' (conceptually '\top'), which could be any value you'd like it to be.<br>
</p>
<p>- Simon<br>
</p>
<blockquote type="cite" cite="mid:MWHPR02MB2479E68AFC95EEE2F2ABE6D4CA440@MWHPR02MB2479.namprd02.prod.outlook.com">
<pre class="moz-quote-pre" wrap="">
In that context, the existing LangRef description of the result of shufflevector can be interpreted to mean exactly what it says. This would imply it's forbidden to transform the shuffle mask "<2 x i32> <i32 undef, i32 0>" to "<2 x i32> <i32 1, i32 0>" if the input might contain poison. (And this is the same logic that led to <a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D70246">https://reviews.llvm.org/D70246</a> .)
That said, long-term, we probably want to switch shufflevector to produce poison.
-Eli
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">-----Original Message-----
From: Nuno Lopes <a class="moz-txt-link-rfc2396E" href="mailto:nuno.lopes@ist.utl.pt"><nuno.lopes@ist.utl.pt></a>
Sent: Tuesday, November 26, 2019 3:20 PM
To: LLVMdev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:spatel@rotateright.com">spatel@rotateright.com</a>; Eli Friedman <a class="moz-txt-link-rfc2396E" href="mailto:efriedma@quicinc.com"><efriedma@quicinc.com></a>; Juneyoung
Lee <a class="moz-txt-link-rfc2396E" href="mailto:juneyoung.lee@sf.snu.ac.kr"><juneyoung.lee@sf.snu.ac.kr></a>; <a class="moz-txt-link-abbreviated" href="mailto:zhengyang-liu@hotmail.com">zhengyang-liu@hotmail.com</a>; John Regehr
<a class="moz-txt-link-rfc2396E" href="mailto:regehr@cs.utah.edu"><regehr@cs.utah.edu></a>
Subject: [EXT] LangRef semantics for shufflevector with undef mask is incorrect
Hi,
This is a follow up on a discussion around shufflevector with undef mask in
<a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D70641">https://reviews.llvm.org/D70641</a> and
<a class="moz-txt-link-freetext" href="https://bugs.llvm.org/show_bug.cgi?id=43958">https://bugs.llvm.org/show_bug.cgi?id=43958</a>.
The current semantics of shufflevector in
<a class="moz-txt-link-freetext" href="http://llvm.org/docs/LangRef.html#shufflevector-instruction">http://llvm.org/docs/LangRef.html#shufflevector-instruction</a> states:
"If the shuffle mask is undef, the result vector is undef. If any element of
the mask operand is undef, that element of the result is undef."
We found this semantics to be problematic. TL;DR: instructions can't detect
if an operand is undef.
Long story:
Undef can be replaced with any value at any time. It's valid to replace
undef with 0 or 1 or anything else.
A possible sequence of optimizations with sufflevector could be as follows:
%v = shufflevector <2 x float> %x, <2 x float> undef, <2 x i32> <i32 undef,
i32 0>
->
%v = shufflevector <2 x float> %x, <2 x float> undef, <2 x i32> <i32 2, i32
0>
->
%v = <undef, %x[0]>
So this respects the semantics in LangRef: the mask is undef, so the
resulting element is undef.
However, there's an alternative sequence of optimizations:
%v = shufflevector <2 x float> %x, <2 x float> undef, <2 x i32> <i32 undef,
i32 0>
->
%v = shufflevector <2 x float> %x, <2 x float> undef, <2 x i32> <i32 1, i32
0>
->
%v = <%x[1], %x[0]>
So now it depends on what the value of %x[1] is. If it's poison, we obtain:
%v = <poison, %x[0]>
This result contradicts the semantics in LangRef, even though no individual
transformation we did above is wrong.
In summary, an instruction cannot detect undef and have special semantics
for it.
AFAICT, the only way to fix the semantics of shufflevector is to say that if
the mask is out-of-bounds, we yield poison. That's correct because there's
nothing worse than poison.
Since we can replace undef with an OOB index, an undef mask can safely yield
poison. Or it would yield one of the input elements, which is poison in the
worst case. So we get poison in both cases.
I guess the issue to make this semantics a reality is that we would need to
introduce a poison value (which is a good thing IMHO). Otherwise we can't
continue doing some of the folds we have today since we don't have a poison
constant to replace undef when folding.
Any comments/suggestions appreciated!
Thanks,
Nuno
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
Click <a class="moz-txt-link-freetext" href="https://www.mailcontrol.com/sr/DTFn8g8lJpvGX2PQPOmvUqrlA1_9RTN2czBGo4QKb0koZUfpwhBgW61USUO2MCVrfSeJemAnwsVue2rhFpgg0Q==">https://www.mailcontrol.com/sr/DTFn8g8lJpvGX2PQPOmvUqrlA1_9RTN2czBGo4QKb0koZUfpwhBgW61USUO2MCVrfSeJemAnwsVue2rhFpgg0Q==</a> to report this email as spam.
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>