From dce1d353bf8994220618d53d32455791631096c3 Mon Sep 17 00:00:00 2001 From: Tim Foley Date: Tue, 28 Jul 2020 07:55:41 -0700 Subject: Fix support for nested generic intrinsics (#1462) The logic that detects intrinsic functions during emit was not able to properly detect an intrinsic generic method nested in a generic type. The basic problem was that this led to a `specialize(specialize(...), ...)` in the IR, which wasn't being handled (only one level of `specialize` was handled). The fix is local and simple. The larger issue was that the author of this commit had thought our IR ruled out nested generics like this, when in fact that is precisely how we handle nested generics throughout the IR. This oversight/misunderstanding means that we might have broken passes in other places that assume nested generics cannot happen. This change doesn't pretend to fix that other issue, but we should pay attention to it. --- source/slang/slang-emit-c-like.cpp | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'source') diff --git a/source/slang/slang-emit-c-like.cpp b/source/slang/slang-emit-c-like.cpp index a3b11a908..ce3dc8957 100644 --- a/source/slang/slang-emit-c-like.cpp +++ b/source/slang/slang-emit-c-like.cpp @@ -3206,6 +3206,17 @@ void CLikeSourceEmitter::emitParamTypeImpl(IRType* type, String const& name) IRInst* CLikeSourceEmitter::getSpecializedValue(IRSpecialize* specInst) { auto base = specInst->getBase(); + + // It is possible to have a `specialize(...)` where the first + // operand is also a `specialize(...)`, so that we need to + // look at what declaration is being specialized at the inner + // step to find the one being specialized at the outer step. + // + while(auto baseSpecialize = as(base)) + { + base = getSpecializedValue(baseSpecialize); + } + auto baseGeneric = as(base); if (!baseGeneric) return base; -- cgit v1.2.3