[llvm-dev] Dereferenceable load semantics & LICM (original) (raw)

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