当在llvm绑定中将函数作为形式参数传递时，上下文缩减堆栈溢出

如何解决当在llvm绑定中将函数作为形式参数传递时，上下文缩减堆栈溢出

| 我正在尝试解决使用Haskell llvm绑定时发生的编译时错误。代码：

-- Line 14 follows
type Acc = Int32 -> Int32 -> IO Int32
type Sig = Int32 -> Ptr Int32 -> Function Acc-> IO Int32

-- [...]

-- Line 31 follows
mSum :: CodeGenModule (Function Sig)
mSum = createNamedFunction ExternalLinkage \"sum\" $ \\l ptr_x fn ->  do
    r <- forLoop (valueOf 0) l (valueOf (0::Int32)) $ \\i sum -> do
      xi <- getIndex ptr_x i
      x <- load xi
      call fn sum x
    ret r

注释：mSum是一个单子函数，它为llvm函数生成一个叮码。生成的函数旨在采用三个参数：l：整数数组的长度； “ 3”指向整数数组的指针；和“ 4”个功能。（第32行）生成的函数将使用和称为sum的累加器循环遍历数组的元素。对于每个值，x，sum和x将被传递给函数fn。该函数的结果将在下一次循环中变为sum的值。 sum的最终值将作为生成函数的值返回。错误：

llvm3.hs:32:8:
Context reduction stack overflow; size = 21
Use -fcontext-stack=N to increase stack size to N
  $dFunctionArgs :: FunctionArgs
                      (Function Acc -> b17)
                      (Value (Ptr (Int32 -> Int32 -> IO Int32)) -> b\'17)
                      r18
  $dFunctionArgs :: FunctionArgs
                      (Ptr (Int32 -> Int32 -> IO Int32) -> b16)
                      (Value (Function Acc) -> b\'16)
                      r17

  -- [ ... ]

  $dFunctionArgs :: FunctionArgs
                      (Ptr (Int32 -> Int32 -> IO Int32) -> b4)
                      (Value (Function Acc) -> b\'4)
                      r5
  $dFunctionArgs :: FunctionArgs
                      (Function Acc -> b3)
                      (Value (Ptr (Int32 -> Int32 -> IO Int32)) -> b\'3)
                      r4
  $dFunctionArgs :: FunctionArgs
                      (Ptr (Int32 -> Int32 -> IO Int32) -> b2)
                      (Value (Function Acc) -> b\'2)
                      r3
  $dFunctionArgs :: FunctionArgs
                      (Function Acc -> IO Int32)
                      (Function (Int32 -> Int32 -> IO Int32)
                       -> CodeGenFunction r Terminate)
                      (CodeGenFunction r0 ())
  $dFunctionArgs :: FunctionArgs
                      (Ptr a0 -> b1) (Value (Ptr Int32) -> b\'1) r2
  $dFunctionArgs :: FunctionArgs
                      (Ptr Int32 -> Function Acc -> IO Int32)
                      (Value (Ptr a0)
                       -> Function (Int32 -> a0 -> IO Int32)
                       -> CodeGenFunction r Terminate)
                      (CodeGenFunction r0 ())
  $dFunctionArgs :: FunctionArgs (i0 -> b) (Value Int32 -> b\') r1
  $dFunctionArgs :: FunctionArgs
                      Sig
                      (Value i0
                       -> Value (Ptr a0)
                       -> Function f0
                       -> CodeGenFunction r19 Terminate)
                      (CodeGenFunction r0 ())
In the expression: createNamedFunction ExternalLinkage \"sum\"
In the expression:
    createNamedFunction ExternalLinkage \"sum\"
  $ \\ l ptr_x fn
      -> do { r <- forLoop (valueOf 0) l (valueOf (0 :: Int32))
                 $ \\ i sum -> ...;
              ret r }
In an equation for `mSum\':
    mSum
      = createNamedFunction ExternalLinkage \"sum\"
      $ \\ l ptr_x fn
          -> do { r <- forLoop (valueOf 0) l (valueOf (0 :: Int32)) $ ...;
                  .... }

问题：有两个可能的问题：如果我没有正确传递函数，那么如何在LLVM中传递指向函数的指针？否则我需要做什么才能满足类型检查器的要求？另外：我不太了解Haskell的工作原理，无法理解为什么会出现此错误。我也不了解createNamedFunction上的类型签名：

(IsFunction f,FunctionArgs f g (CodeGenFunction r ()))  
=> Linkage   
-> String    
-> g    -- Function body.
-> CodeGenModule (Function f)

解决方法

哦，真可悲。是的，您可能遇到某种类型的错误。这里的库使用ѭ14来执行一些奇特的类型级逻辑，其中“ fancy \”表示“如果不走运，将使类型检查器进入无限循环”。您可能会猜到您现在有多幸运。不幸的是，尽管由此产生的严重错误告诉我们循环发生在哪里，但它却不像人们想的那样丰富。另外，请注意，完全不理解为什么会收到此错误是完全合理的。杂乱而混乱。以下是一些粗略的解释，以及我对缩小原因的看法：首先，计算calculating15ѭ时显然发生了循环。考虑类的定义：

class FunctionArgs f g r | f -> g r,g r -> f where
    ...

ѭ17之后的部分是功能依赖项，指定某些参数唯一地确定其他参数。在这种情况下，f和g和r的组合相互决定，因此它是一种双向函数，可以在任一方向上进行计算。您的函数为mSum :: CodeGenModule (Function Sig)，统一以createNamedFunction的签名使我们以Sig作为f参数，而r和g目前未知。类型同义词Sig扩展为Int32 -> Ptr Int32 -> Function Acc-> IO Int32。现在我们看一下ѭ15的实例列表，看看这能给我们带来什么。运算符优先级为我们提供了最左边的函数箭头作为Sig的最外层类型构造函数，因此我们找到了匹配的实例：FunctionArgs b b\' r => FunctionArgs (a -> b) (Value a -> b\') r。我们可以替换类型，根据需要进行统一，然后重复：

FunctionArgs (Ptr Int32 -> Function Acc-> IO Int32) b\' r => FunctionArgs (Int32 -> (Ptr Int32 -> Function Acc-> IO Int32)) (Value Int32 -> b\') r

FunctionArgs (Function Acc-> IO Int32) b\' r => FunctionArgs (Ptr Int32 -> (Function Acc-> IO Int32)) (Value (Ptr Int32) -> b\') r

您应该能够将这些步骤与堆栈跟踪相匹配，以解决所得到的错误。一件有趣的事情是，堆栈跟踪中还有其他步骤，我不确定其原因-我想这与它根据功能依赖关系填充类型有关。看起来，它首先基于(->)类型构造函数选择实例，然后为g参数填充Value a -> b类型构造函数，然后执行递归步骤（在上下文中），然后返回以统一其余类型。现在，我们知道这是错误的时间；这可以从堆栈溢出的通用原理推论得出，这是问题出在堆栈跟踪开始重复重复相同模式之前的某个地方。对于下一个归约，f用Function Acc-> IO Int32实例化，而g和r至今尚未确定（尽管我们知道它们必须由f唯一确定）。这时最好看一下Function的定义：:43ѭ FunctionArgs (Value (Ptr Acc) -> IO Int32) g r 同样，我们选择带有功能箭头的实例：FunctionArgs b b\' r => FunctionArgs (a -> b) (Value a -> b\') r ...这就是发生混乱的地方，因为如果比较上面的堆栈跟踪，则参数g会显示(Function (...) -> ...)。从技术上讲，这与上面给出的Function的定义相匹配，因为我们期望有Value，它是Function类型同义词的最外层构造函数。不幸的是，我们对于f参数也有(Function (...) -> ...)，这是不一致的，因为g参数应该有一个额外的Value构造函数。填写了不正确的结构后，它将继续停留在应填写其余类型变量的步骤上；似乎双向功能依赖性导致它来回反弹，反复尝试将a与Value a统一。因此，随着类型同义词的扩展，我们得到以下信息： FunctionArgs (Value (Ptr Acc) -> b) (Value (Ptr Acc) -> b\') r FunctionArgs (Ptr Acc -> b) (Value (Value (Ptr Acc)) -> b\') r ...无限在这一点上，我真的不确定是什么原因导致了这种冲突。我希望结果是一致的实例选择FunctionArgs (Value (Ptr Acc) -> b) (Value (Value (Ptr Acc)) -> b\') r，但我不能真正说出它为什么会卡住。编辑：等等，我很傻。首先，我会误读您的代码-很明显，它是从lambda表达式的推断类型中得到了不正确类型的某些部分，我认为它实际上比实际的多态性。特别是，参数fn作为函数call :: CallArgs f g => Function f -> g的参数给出，函数function61 above在上面创建了不一致的类型。我仍然不知道为什么它会陷入无限循环，但这至少可以解释这种冲突。假设由call得出的推断类型正确，,19ѭ参数的类型应为Value Int32 -> Value (Ptr Int32) -> Function Acc-> CodeGenFunction Int32 ()，这意味着f应为Int32 -> Ptr Int32 -> Ptr Acc-> IO Int32，而不是您的Sig类型。可以理解的是，如果您查看也应用于f的IsFunction类，它期望函数参数是基本类型的原始类型，例如Int32或Ptr，而不是Value，这是Function扩展到的类型。所以毕竟，我认为您的问题只是您的Sig类型略有错误。 ...很高兴好吧。

当在llvm绑定中将函数作为形式参数传递时，上下文缩减堆栈溢出

如何解决当在llvm绑定中将函数作为形式参数传递时，上下文缩减堆栈溢出

解决方法

相关推荐