[llvm-dev] RFC: Killing undef and spreading poison

[Sanjoy Das via llvm-dev]

Hi Alexandre,

On Wed, Oct 19, 2016 at 6:27 PM, Alexandre Isoard
<alexandre.isoard at gmail.com> wrote:
> Really interesting read. I am perplexed now, and am not even sure what is
> the meaning of undef anymore.

Welcome aboard. :)

> Example (unrelated to your blog post, but still weird):
> %x = sext i1 undef to i2
>
> I understand that I can replace it by either of:
> %x = i2 0
> %x = i2 -1
>
> But can I replace it by:
> %x = i2 undef
>
> I would have said no, at first sight, because -2 and 1 should not be
> possible values.
> But if I look at each bit, independently, each one can be either 0 or 1.
> Then, if we
> forget their "entanglement" (like we do shamelessly with xor %x, %x), and
> then
> concatenate them back together, we get the i2 undef...

Yes.

If your definition of sext is:

sext(x):
  if x == 0 then 0 else -1

then things are fine.  However, if your definition of sext is something like:

sext(x):
  t = zext x
  result = 0
  for i = 0 to bitwidth:
    result |= t << i;
  return result

then sext(undef) is, in fact, undef for the reason you highlighted.
In general, you cannot increase the number of uses of undef and
preserve semantics.

You could say that the "zext x" above is "either 0 or 1" (i.e. it
implicitly freezes its input), but then e.g. (in todays scheme)
"trunc(zext(x))" cannot be replaced by "x".

-- Sanjoy