[llvm-dev] LangRef semantics for shufflevector with undef mask is incorrect
Doerfert, Johannes via llvm-dev
llvm-dev at lists.llvm.org
Wed Nov 27 13:05:30 PST 2019
On 11/27, Simon Moll via llvm-dev wrote:
> On 11/27/19 2:10 AM, Eli Friedman via llvm-dev wrote:
>
> 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.
>
> 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:
>
> %x = phi i32 [ 0, A ], [ undef, B ]
>
> into
>
> %x = phi i32 [ 0, A ], [ 1, B ]
>
> which arguing by the intended semantics of phi nodes should be an illegal transformation but isn't in LLVM.
>
> 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.
>
> 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.
Similar problems appears in other contexts as well:
https://reviews.llvm.org/D70749#1761120
Might also be interesting to take a look
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191127/2f73ea75/attachment.sig>
More information about the llvm-dev
mailing list