diff options
| author | Theresa Foley <10618364+tangent-vector@users.noreply.github.com> | 2023-01-14 15:31:31 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-01-14 15:31:31 -0800 |
| commit | 14fab67c5edd8eb697ffb10dbcc0467678521eef (patch) | |
| tree | 88c82d8fd29d496a5a44ff51bc9a0f4f2ab2905f /source/slang/slang-ir-ssa.cpp | |
| parent | 4adc64f2a033ec141df6a16e65131612b30fb23b (diff) | |
Fixes for crash when inlining at global scope (#2593)
* Fixes for crash when inlining at global scope
Recent changes to the way inlining is implemented in the Slang compiler
have broken certain scenarios involving `static const` declarations.
The basic problem is that the initial-value expression for a `static const`
gets lowered into IR code at the global scope of a module, and if
that code includes `call`s to stdlib operations marked `forceInlineEarly`,
then we end up trying to apply inlining to code at module scope.
The current inlining operation assumes that all `call`s are in basic
blocks, and that the correct way to do inlining involves splitting
those blocks.
This change adds logic to detect when the callee at a call site to
be inlined consists of a single basic block ending in a `return`,
and in that case it invokes specialized inlining logic that doesn't
split basic blocks and doesn't need to care if the original `call`
is in a basic block.
Thus we are able to inline calls to single-basic-block `forceInlineEarly`
functions called as part of the initialization for global-scope
`static const` variables.
This logic does *not* solve the problem of calls to multi-block
`forceInlineEarly` functions from the global scope. Such calls cannot
really be inlined.
A secondary problem that arises when inlining such calls is that the
callee might include local temporaries (`var` instructions) that are
read and written (`load`s and `store`s), and none of those instructions
should be allowed at the global scope.
In the case of the functions being inlined here, the `load`/`store`
operations are superfluous, and should be cleaned up by our SSA pass.
The only reason that they seem to *not* be getting cleaned up in the
case that was been triggering crashes is that the callee is a generic.
The current logic for the SSA pass was skipping the bodies of generic
functions, so they would not be cleaned up. This change enables the SSA
pass to apply to the bodies of generic functions, and also ensures that
SSA cleanups are applied *before* any `forceInlineEarly` functions get
inlined.
* fixup: liveness test outputs
Diffstat (limited to 'source/slang/slang-ir-ssa.cpp')
| -rw-r--r-- | source/slang/slang-ir-ssa.cpp | 20 |
1 files changed, 20 insertions, 0 deletions
diff --git a/source/slang/slang-ir-ssa.cpp b/source/slang/slang-ir-ssa.cpp index 2415f1388..0bd5c6e9f 100644 --- a/source/slang/slang-ir-ssa.cpp +++ b/source/slang/slang-ir-ssa.cpp @@ -1221,6 +1221,26 @@ bool constructSSA(IRModule* module, IRInst* globalVal) case kIROp_GlobalVar: return constructSSA(module, (IRGlobalValueWithCode*)globalVal); + case kIROp_Generic: + { + // The above cases handle the actual code-bearing declarations + // that can contian basic blocks with local variables, but + // we would also like to perform SSA simplifications on + // *generic* functions, and so we will also process any + // instruction that is produced by an `IRGeneric`. + // + // TODO: At some point we may simply want to apply this pass + // recursively to *all* instructions, in order to make it + // robust to the presence of nested functions in general. + + auto generic = cast<IRGeneric>(globalVal); + auto returnVal = findInnerMostGenericReturnVal(generic); + if(!returnVal) + return false; + + return constructSSA(module, returnVal); + } + default: break; } |
