[naga msl-out] Unbounded loop workaround is not adequate

[jimblandy]

I'll provide more details later, but the LOOP_IS_REACHABLE kludge has been found to be insufficient at avoiding UB and security problems. Basically, even with the kludge applied, the loop is still infinite, and still reached, so it's just a matter of being clever.

• msl
• hlsl

[jimblandy]

Tint's latest iteration is here or here.

Suppose the user presents you with a loop like this, where i is a u32:

loop {
    if (i < 10) {
        a[i] = b[i];
        break;
    }
}

The Metal Shading Language compiler is allowed to assume that all loops terminate. (This is just another way of saying, "infinite loops are UB".)

For that to be the case, we must reach the break, so we know that i < 10 when we reach the if. Thus, the entire loop can be rewritten as:

a[i] = b[i];

Since i is a u32, the compiler infers that 0 <= i < 10 when the assignment is reached. This means that if a and b are arrays of length 10 or greater, the compiler knows that i is in bounds, and thus can discard bounds checks injected by Naga.

Again, the reason the existing LOOP_IS_REACHABLE kludge doesn't suffice is that it merely persuades MSL that, since there is a branch over the infinite loop, conditions sufficient to lead to that branch aren't necessarily true. But the infinite loop is still there, so MSL is still free to infer other things based on that.

[jimblandy]

The fix is to generate code like this:

while (true) {
    // body of loop
    {volatile bool VOLATILE_NAME = false; if (VOLATILE_NAME) break;}
}

This forces the MSL compiler to assume that the loop does terminate, thus preventing it from assuming that other conditions leading to other breaks must be true.

This will probably have even more of a performance impact than our current LOOP_IS_REACHABLE kludge, since it's inside the loop, not outside it.

[teoxoy]

This is interesting, so the fact that "The Metal Shading Language compiler is allowed to assume that all loops terminate." + the fact that "indexing out of bounds is UB" (presumably allowing the compiler to also assume it doesn't happen) allows for this sort of optimizations where the bounds checks we inject are thrown away.

I finally understand the situation. I didn't think that UB could mean "assume it never happens" but I guess that's valid. This is unfortunate as we have to cope with this sort of ramifications.

[teoxoy]

Thinking about this some more, I always thought of UB as strictly happening at runtime (ex: if you index out of bounds at runtime, here be dragons). If that were the case, the optimization happening here would have been a bug.

That's clearly not the case https://en.cppreference.com/w/cpp/language/ub.
I'm not sure how C++ developers deal with this.

[ErichDonGubler]

@teoxoy: It is with a certain dubious delight that I present this old classic for your reading: Undefined behavior can result in time travel

[teoxoy]

I wanted to see the effect of this for myself: https://shader-playground.timjones.io/b13aed3846180491656e076460d45bce

It looks like the bound check is still in the output of the Metal compiler, the loop is gone and the if became:

  %5 = icmp ult i32 %1, 10
  call void @llvm.assume(i1 %5)

@llvm.assume is documented as:

Allows the optimizer to assume that the provided condition is true. This information can then be used in simplifying other parts of the code.

And I'm guessing that the optimizer will see that i is at most 9 and will replace the bound check (metal::min(i, 15u - 1)) with i.

Adding

{volatile bool VOLATILE_NAME = false; if (VOLATILE_NAME) break;}

to the end of the loop or using a volatile bool as the loop condition fixes the issue; the current LOOP_IS_REACHABLE macro doesn't (the @llvm.assume is still in the output).

[teoxoy]

I was curious to see what DXC does: https://shader-playground.timjones.io/9eb4af3bb2082c18cbd216659849eea1

It seems like it removes the loop and the if altogether but makes no assumptions about the value of i. This will preserve the bounds checks but could be viewed as a bug from the perspective of a WGSL developer since code will get executed regardless of the value of i. The WGSL spec doesn't disallow infinite loops unless they are trivial.

It seems to me that all of these headaches would be solved if we'd add a generous upper bound (u32::MAX?u64::MAX?) on the number of loop iterations in the WGSL spec. It could be that by the time code reaches one of these upper bounds, the driver would lose the device anyway.

[teoxoy]

@magcius also mentioned in one of the chats that SPIR-V considers infinite loops UB but I couldn't find info on that. Jasper, do you have some links/references?