diff options
| author | Tim Foley <tfoleyNV@users.noreply.github.com> | 2020-02-27 14:29:00 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-02-27 14:29:00 -0800 |
| commit | 5e31e9f074ea0bb795b50272f904aebc520d3714 (patch) | |
| tree | bbf09db9e6fffe80e364882b8927a12d674af848 /source/core | |
| parent | b0f65ba386c92af2bbbe0f3fd7dbd503df3d69f2 (diff) | |
Fix some IR logic around load from a rate-qualified pointer (#1248)
We currently represent the `groupshared` qualifier as a kind of "rate" at the IR level (where a rate can qualify a type to indicate the frequency/rate at which a value is stored and/or computed). This means that when computing the type that a pointer points to, we need to handle both, e.g., `Ptr<Int>` and `@GroupShared Ptr<Int>`.
The logic that was trying to handle the rate-qualified case when deducing the "pointee" type of a pointer was somehow written incorrectly, and was querying `getDataType()` on an `IRRateQualifiedType` which is asking for the type of the type itself (null in this case), rather than `getValueType()` which gets the `T` part from a rate-qualified type `@R T`.
Somehow none of our tests were hitting this case, and I'm not immediately clear on how to write a targeted reproducer for this, since the problem arose as a debug-only assertion failure in a user shader with thousands of lines.
Diffstat (limited to 'source/core')
0 files changed, 0 insertions, 0 deletions
