我目前正在试验Halide，最初的测试显示出相当有希望的性能改进。
我现在想知道分发卤化物代码的最佳策略是什么。目前，要求用户安装 Halide 似乎是一个沉重的障碍（因为没有自动安装选项）。
一种选择是使用compile_to_c，将生成的 C 代码添加到存储库中，然后分发此类 C 代码的编译脚本。scikit-learn对 Cython 生成的代码使用了类似的策略。对于 Halide 来说，这似乎是不行的，因为生成的 C 代码失去了所有的优化，违背了 Halide 的目的。
我目前的想法是使用
compile_to_bitcode ，将生成的位码与调用llc的编译脚本一起分发以生成所需的机器代码。对用户的唯一要求是安装llc（即llvm）。
有没有人有这个问题的经验？
我分发比特码的想法的优缺点是什么？
你会推荐什么？
有关软件分发类型的一些详细信息会有所帮助。这个问题暗示了源代码分发，但是程序员可能需要在细粒度级别与 Halide 生成的代码进行交互的库与最终用户和最终用户基本上不可见使用 Halide 的应用程序之间存在很大差异。目标只是让它建立。
分发位码是可行的，但有问题。为了便于携带，您必须使用 PNaCl 后端之类的东西。（PNaCl 非常接近通用 LLVM 位码表示。）如果您针对特定架构，则无法保证位码将在任何其他架构上编译或运行。（例如，卤化物可以降低到特定于体系结构的内在函数。）LLVM 社区不鼓励使用位码作为分发格式，尽管如果它是源代码形式（.ll，而不是 .bc），它可能相当稳定，并且看起来并不比运输差多少装配文件在长期稳定性方面。
Halide 在生成的输出中包含特定于操作系统的运行时，因此即使使用位码，结果也会包含许多特定于目标的依赖项。
通常，最终设计会在运行时根据所使用的处理器的实际类型在多个卤化物输出之一之间进行选择。例如，使用 Halide 为 SSE2 和 AVX2 处理器编译具有两种不同调度的相同算法。在这个模型中，无论如何都会有很多目标文件，人们可以在构建时简单地选择要包含给给定架构和操作系统的目标文件。将对象分发为 .ll 文件而不是 .o 文件可能会起作用，但我不确定它会买多少。
我会努力提供完整的源代码，如果要从头开始编译，则需要 Halide，并寻找提供各种级别的二进制分发的方法。当然，对于最终用户软件，重点应该放在如何将完全构建的软件包交到用户手中。对于库，Halide 可用于向库的用户展示更高级别的编程模型，在这种情况下，无论如何都需要存在 Halide 编译器。
我们努力使 Halide 相当容易进入系统并且非常稳定，但还没有完全确定。我可能会尝试提供某种程度的回退，并且使用 C 后端生成通用 C 代码可能是一种不错的方法，无需直接用 C 重写所有内容。（如果从源代码构建，可以选择安装 Halide 或使用预构建的 C 代码。）这是 C 后端更好的用例之一。（从 Halide 生成 C 代码通常是一个非常边缘的想法，尽管起初它似乎是一个不错的想法。）
compile_to_c() 绝对不推荐，因为它生成的代码不是很优化；它主要用作调试/开发工具。
compile_to_bitcode() 听起来它可以工作，但我不知道有人使用它作为分发方法。
（为 Halide 提供自动安装可能会很有用。）