diff options
| author | Tim Foley <tfoley@nvidia.com> | 2017-09-22 08:24:14 -0700 |
|---|---|---|
| committer | Tim Foley <tfoley@nvidia.com> | 2017-09-22 14:18:44 -0700 |
| commit | 1972fa3616af55c223096e9b11465f580530d88f (patch) | |
| tree | 990e9f62c9ece4ec9996866480d6dd469c4f982f /tests/ir/loop.slang.expected | |
| parent | b206af702cbc8cc42c73052ad690d69984ecd7b7 (diff) | |
More work on IR-based lowering and cross-compilation
None of these changes are made "live" at the moment. I'm just trying to get them checked in to avoid divering too far from `master` at any point during development.
- Add basic emit logic to produce GLSL from the IR in a few cases (the existing IR emit logic was ad hoc and HLSL-specific)
- When lowering a function declaration, walk up its chain of parent declarations to collect additional parameters as needed
- When lowering a call, make sure to add generic arguments that come from the declaration reference being called
- Attach a "mangled name" to symbols when lowering, so that we can eventually use that name to resolve things for linkage.
- After the above work, I had to apply some fixups to make sure that generic arguments *don't* get added when the user is calling an `__intrinsic_op` function, since those should map 1-to-1 down to instructions with just their ordinary parameter list.
A big open question right now is whether I should continue to represent the generic arguments as just part of the ordinary argument list for a function, or split them out into separate `applyGeneric` and `apply` steps.
A strongly related question is whether a declaration with generic parameters should lower into a single declaration, or one declaration nested inside an outer generic declaration.
A good future step at this point would be to eliminate a lot of the `__intrinsic_op` stuff in favor of having the builtin functions include their own definitions, which might be in terms of a new expression-level construct for writing inline IR operations. This can't be done until the existing AST-to-AST path is no longer needed for cross-compilation purposes.
More immediate next steps here:
- We need a way to round-trip calls to external declaration that get handled by this mangled-name logic. Basically, if we are asked to output HLSL and we see a call to `_S...GetDimensions...(float4, t, a, ...)` we need to be able to walk the mangled name and get back to `t.getDimensions(a, ...)` without a whole lot of manual definitions to make things round-trip.
- In the other case, where a declaration isn't built-in for the chosen target, we need to be able to load a module of target-specific definitions (which will somehow map back to symbols with certain mangled names) and then look these up (by mangled name) and then load/link/inline them into the user's IR to satisfy requirements in their code.
Diffstat (limited to 'tests/ir/loop.slang.expected')
| -rw-r--r-- | tests/ir/loop.slang.expected | 122 |
1 files changed, 61 insertions, 61 deletions
diff --git a/tests/ir/loop.slang.expected b/tests/ir/loop.slang.expected index 2b8bff732..a0f8de432 100644 --- a/tests/ir/loop.slang.expected +++ b/tests/ir/loop.slang.expected @@ -3,76 +3,76 @@ standard error = { } standard output = { let %63 : Ptr<Array<Vec<Float32,4>,64>,1> = var() -let %90 : Ptr<StructuredBuffer<Vec<Float32,4>>,0> = var() -let %268 : Ptr<RWStructuredBuffer<Vec<Float32,4>>,0> = var() +let %96 : Ptr<StructuredBuffer<Vec<Float32,4>>,0> = var() +let %282 : Ptr<RWStructuredBuffer<Vec<Float32,4>>,0> = var() -func %1( - param %7 : UInt32, - param %18 : UInt32, - param %28 : UInt32) +func @_S04mainp3 : (Int32, Int32, Int32) -> Void { -block %4: - let %13 : Ptr<UInt32,0> = var() - store(%13, %7) - let %23 : Ptr<UInt32,0> = var() - store(%23, %18) - let %33 : Ptr<UInt32,0> = var() - store(%33, %28) - let %64 : UInt32 = load(%23) +block %14( param %15 : Int32, + param %24 : Int32, + param %32 : Int32) +: + let %21 : Ptr<Int32,0> = var() + store(%21, %15) + let %29 : Ptr<Int32,0> = var() + store(%29, %24) + let %37 : Ptr<Int32,0> = var() + store(%37, %32) + let %64 : Int32 = load(%29) let %69 : Ptr<Vec<Float32,4>,0> = getElementPtr(%63, %64) - let %91 : StructuredBuffer<Vec<Float32,4>> = load(%90) - let %94 : UInt32 = load(%13) - let %95 : Vec<Float32,4> = bufferLoad(%91, %94) - store(%69, %95) - let %104 : Ptr<UInt32,0> = var() - let %112 : UInt32 = construct(1) - store(%104, %112) - loop(%117, %123, %126) + let %97 : StructuredBuffer<Vec<Float32,4>> = load(%96) + let %100 : Int32 = load(%21) + let %101 : Vec<Float32,4> = bufferLoad(%97, %100) + store(%69, %101) + let %110 : Ptr<Int32,0> = var() + let %118 : Int32 = construct(1) + store(%110, %118) + loop(%123, %129, %132) -block %117: - let %133 : UInt32 = load(%104) - let %142 : UInt32 = construct(64) - let %143 : Bool = cmpLT(%133, %142) - loopTest(%143, %120, %123) +block %123: + let %139 : Int32 = load(%110) + let %148 : Int32 = construct(64) + let %149 : Bool = cmpLT(%139, %148) + loopTest(%149, %126, %129) -block %120: +block %126: GroupMemoryBarrierWithGroupSync() - let %166 : UInt32 = load(%23) - let %171 : Ptr<Vec<Float32,4>,0> = getElementPtr(%63, %166) - let %176 : Ptr<Vec<Float32,4>,0> = var() - let %177 : Vec<Float32,4> = load(%171) - store(%176, %177) - let %196 : UInt32 = load(%23) - let %199 : UInt32 = load(%104) - let %200 : UInt32 = sub(%196, %199) - let %205 : Ptr<Vec<Float32,4>,0> = getElementPtr(%63, %200) - let %206 : Vec<Float32,4> = load(%205) - let %207 : Vec<Float32,4> = load(%176) - let %208 : Vec<Float32,4> = add(%207, %206) - store(%176, %208) - let %211 : Vec<Float32,4> = load(%176) - store(%171, %211) - unconditionalBranch(%126) + let %174 : Int32 = load(%29) + let %179 : Ptr<Vec<Float32,4>,0> = getElementPtr(%63, %174) + let %184 : Ptr<Vec<Float32,4>,0> = var() + let %185 : Vec<Float32,4> = load(%179) + store(%184, %185) + let %204 : Int32 = load(%29) + let %207 : Int32 = load(%110) + let %208 : Int32 = sub(%204, %207) + let %213 : Ptr<Vec<Float32,4>,0> = getElementPtr(%63, %208) + let %214 : Vec<Float32,4> = load(%213) + let %215 : Vec<Float32,4> = load(%184) + let %216 : Vec<Float32,4> = add(%215, %214) + store(%184, %216) + let %219 : Vec<Float32,4> = load(%184) + store(%179, %219) + unconditionalBranch(%132) -block %126: - let %224 : Ptr<UInt32,0> = var() - let %225 : UInt32 = load(%104) - store(%224, %225) - let %236 : UInt32 = construct(1) - let %237 : UInt32 = load(%224) - let %238 : UInt32 = shl(%237, %236) - store(%224, %238) - let %241 : UInt32 = load(%224) - store(%104, %241) - unconditionalBranch(%117) +block %132: + let %232 : Ptr<Int32,0> = var() + let %233 : Int32 = load(%110) + store(%232, %233) + let %244 : Int32 = construct(1) + let %245 : Int32 = load(%232) + let %246 : Int32 = shl(%245, %244) + store(%232, %246) + let %249 : Int32 = load(%232) + store(%110, %249) + unconditionalBranch(%123) -block %123: +block %129: GroupMemoryBarrierWithGroupSync() - let %269 : RWStructuredBuffer<Vec<Float32,4>> = load(%268) - let %272 : UInt32 = load(%13) - let %286 : Ptr<Vec<Float32,4>,0> = getElementPtr(%63, 0) - let %287 : Vec<Float32,4> = load(%286) - bufferStore(%269, %272, %287) + let %283 : RWStructuredBuffer<Vec<Float32,4>> = load(%282) + let %286 : Int32 = load(%21) + let %300 : Ptr<Vec<Float32,4>,0> = getElementPtr(%63, 0) + let %301 : Vec<Float32,4> = load(%300) + bufferStore(%283, %286, %301) return_void() } } |
