GCC编译器能否使用nVidia GPU加速编译和/或链接？

我正在研究使用nvptx卸载的gcc（特别是在Windows/MinGW-w64上），我想知道gcc本身是否可以利用这一点，因此它有更多的处理能力来更快地编译/链接

或者这个问题没有什么意义，因为这些过程在本质上还不够数学化

还有一个事实是，gcc有一些本质上的数学依赖性（mpfr、gmp、mpc、isl），所以他们可能可以利用卸载，使用GPU使gcc更快？

“可以…？”：不，不能；否则会出现在手册中：-）

“可能…？”：可能不会；编译主要是遍历数据结构，不执行并行算术运算，并且除了在非常高的级别上之外，显然不是并行的。一个过程需要由前一个过程创建的状态，因此存在严格的顺序，并且您不能轻松地并行执行多个过程。（每个过程都在更新代码的单个表示形式）

---

当前的方法是使用

make-j8

或类似工具同时编译多个文件，但即使在那里，您也不可能有足够的并行性来保持GPU繁忙。

我宁愿猜测这些问题在本质上是不够并行的。即使其中有一部分是，也必须减去数据传输时间。但我不是编译器专家，所以我很好奇别人会怎么说。@Paul：现实世界的编译是令人尴尬的并行，因为大多数程序都是由许多独立的翻译单元组成的。链接是最难的部分，在很大程度上这是一个系统设计问题-有一种非常古老的设计模式，链接器使用磁盘上的文件，而不直接与编译器对话。@m只要没有成千上万的翻译单元，就可以进行长距离的转换这对于GPU来说不够并行。答案似乎和我的论点相同。@Paul:这更像是阿姆达尔定律适用的论点。在每个翻译单元中可能会发现更多的并行性，但是链接中的串行瓶颈仍然存在。@MSalters链接和Amdahl定律在答案中甚至没有提到。但更重要的是，我想知道如何找到足够的并行性？我的意思是，我猜不同的函数可以简单地并行编译，但是与优化相关的所有需要知道上下文的东西都需要按顺序运行，还是不？也许那才是把阿姆达尔定律引入其中的好地方。特别是因为在我的经验中，链接（即使是LTO）似乎并没有支配编译时间（可能对于足够大的项目有足够的GPU并行性）。