[llvm-dev] Dereferenceable load semantics & LICM

Sanjoy Das via llvm-dev llvm-dev at lists.llvm.org
Thu Apr 6 14:47:55 PDT 2017


Hi Piotr,

On April 6, 2017 at 9:28:58 AM, Piotr Padlewski
(piotr.padlewski at gmail.com) wrote:
> Hi Sanjoy,
> My point is that this it is exactly the same way as normal !dereferenceable
> introduces UB.
>
> ptr = load i8*, i8** %ptrptr, !dereferenceable !{i64 8}
> if (false) {
> int val = *ptr;
> }

These are two different things.

In the above example, your original program executes a load that was
supposed to produce a dereferenceable value, but it did not.  This
means the original program is undefined, so we can optimize it to do
whatever we want.

OTOH, look at this program:

void main() {
  if (false) {
    // ptrptr does not contain a dereferenceable pointer, but is
itself dereferenceable
    ptr = load i8*, i8** %ptrptr, !dereferenceable !{i64 8}, !global
    int val = *ptr;
  }
}

What is the behavior of the above program?  It better be well defined,
since it does nothing!

However, if we follow your rules, we can first xform it to

void main() {
  ptr = load i8*, i8** %ptrptr, !dereferenceable !{i64 8}, !global
  if (false) {
    int val = *ptr;
  }
}

and then to

void main() {
  ptr = load i8*, i8** %ptrptr, !dereferenceable !{i64 8}, !global
  int val = *ptr;
  if (false) {
  }
}

which introduces UB into a program that was well defined to begin
with.

> If frontend says that something is dereferenceable, which is not actually
> dereferenceable, then it is UB and everything can happen - like the
> execution of dead instruction.
> This is exactly the same with the global properties - we are giving a
> guarantee that pointer it is dereferenceable even if we would hoist or sink
> it, and if it is not true then it is UB.

But then you're saying dead code (code that would not actually execute
in the original program) can affect program behavior, and: "if (false)
X;" is not a no-op for some values of X.  It is in this respect that
your proposal is similar to the speculatable proposal.

-- Sanjoy


More information about the llvm-dev mailing list