jhuber6 added a comment. In D130096#3850628 <https://reviews.llvm.org/D130096#3850628>, @arsenm wrote:
> In D130096#3850550 <https://reviews.llvm.org/D130096#3850550>, @b-sumner > wrote: > >> There's the "small matter" of implementing the new device library functions. >> Why is all that more likeable than two kinds of control constants? > > Different functions providing different behaviors can be handled at link time > like any other function, instead of the same functions providing different > behaviors per translation unit and requires cloning. The current scheme > transfers complexity from the device library build system into the driver and > user binaries Another benefit of this would be that linking could be done only once in a sound manner rather than requiring an instance of the ROCm device libraries to be included for each TU. Although we would probably still need the attribute propagation that `-mlink-builtin-bitcode` offers, so it wouldn't be quite as easy that throwing the device libs into the `lld` invocation. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D130096/new/ https://reviews.llvm.org/D130096 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
