[Webkit-unassigned] [Bug 188402] New: [WHLSL] Local variables should be statically allocated

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=188402

            Bug ID: 188402
           Summary: [WHLSL] Local variables should be statically allocated
           Product: WebKit
           Version: Other
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebGPU
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: tdenney at apple.com

The interpreter conforms to the spec; the Metal compiler doesn't (necessarily). For example, a call to foo() should return 1:

    thread int* bar(bool flag)
    {
        int x = 0;
        if (flag)
            x = 1;
        return &x;
    }

    int foo()
    {
        thread int* x = bar(false);
        thread int* y = bar(true);
        return (*x) * (*y);
    }

The interpreter gets this right; when a VariableDecl is visited in Evaluator.js it only allocates a buffer for that variable if there wasn't one already. The compiler doesn't get it right; local variables are emitted in local scope and therefore the Metal compiler *can* choose to store them however it likes. They could be independent, or another function bar2() could alias its local variables with bar() if bar and bar2 are never both called.

Metal Shading Language only permits constant variables to be static if they are declared in global scope. It doesn't permit statically declared variables in local scope.

When functions are inlined this isn't a problem; all variables can be "statically" allocated by having them as local variables declared at the top of a shader function. However, not all functions can be (efficiently) inlined in the MSL output if they don't have reducible control flow. An inefficient solution would "statically" allocate all variables in the main shading functions and pass references to them to non-inlined functions. This awful approach could be mitigated by conservatively finding local variables that references are never created for, but it is far from ideal.

It is worth noting that successive executions of the same function cannot rely on previous values stored at the same local variable because local variables are *always* zero-initialized when they are declared. The compiler and the interpreter behave correctly on the following program:

    thread int* bar(bool flag)
    {
        int x; // x is zero initialized twice
        if (flag)
            x = 1;
        return &x;
    }

    int foo()
    {
        thread int* x = bar(true);
        thread int* y = bar(false);
        return (*x) * (*y);
    }

The result of foo() should be 0.

Given that local variable values do not persist between calls, the largest benefit of statically allocating local variables is that references to local variables can be returned from a function, or passed out via "out" parameters. Many programming languages do not permit this, so a possible mitigation would be to disallow it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180808/f76f0107/attachment.html>