我目前正在试验Halide，初步测试显示了非常有前途的性能改进。
我现在想知道分发Halide代码的最佳策略是什么。要求用户安装Halide在这个时间点似乎是一个很大的障碍（因为没有自动安装选项）。
一种选择是使用compile_to_c，在存储库中添加生成的C代码，并为这样的C代码分发编译脚本。 scikit-learn对Cython生成的代码使用了类似的策略。对于Halide来说，这似乎是不行的，因为生成的C代码失去了所有的优化，从而破坏了Halide的目的。
我目前的想法是使用compile_to_bitcode，将生成的bitcode与调用llc的编译脚本一起分发，以生成所需的机器代码。用户的唯一要求是安装llc（即llvm）。
有没有人有这个问题的经验？ 我分发bitcode的想法有什么利弊？ 你会推荐什么？
有关软件分发类型的一些细节会有所帮助。问题意味着源代码分发，但是程序员可能需要与细粒度级别的Halide生成的代码进行交互的库与使用Halide在很大程度上对最终用户不可见的应用程序之间存在很大差异。目标只是让它建立。
分发bitcode是可行但有问题的。为了便携，你必须使用类似PNaCl后端的东西。 （PNaCl非常接近通用LLVM bitcode表示。）如果您定位特定体系结构，则无法保证bitcode将在任何其他体系结构上编译或运行。 （例如，Halide可以降低到体系结构特定的内在函数。）LLVM社区不鼓励使用bitcode作为分发格式，但如果它是源代码形式（.ll，而不是.bc），它可能相当稳定，并且似乎没有比运输更差装配文件的长期稳定性。
Halide在生成的输出中包含OS特定的运行时，因此即使使用bitcode，结果也包含许多特定于目标的依赖项。
通常，最终会得到一种设计，该设计在运行时根据所使用的处理器的实际类型选择多个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提供自动安装可能很有用。）