jdoerfert added a comment. In D93079#2451782 <https://reviews.llvm.org/D93079#2451782>, @JonChesterfield wrote:
> Is this for cases where we are compiling a subset of the target code, i.e. > without link time optimisation? Upstream cannot to LTO on any target code as of now :( > It's interesting that we might want a static function on the gpu and an > external one on the cpu. The user could presumably make it static and provide > a different, host-only function which calls it as a workaround. If they have control. Code in a header for example might not be changeable. Though I will add it to the remark description for sure. > I'm nervous about this one because it looks like a property the compiler > should already be able to derive (given LTO, anyway), and I don't see how we > can diagnose when the user annotation is inaccurate, e.g. because of changes > elsewhere in the codebase after it was added. This is always an issue with assumes/assertions/annotations/... Unsure what to say. I'd be fine with retiring this one as soon as we can do LTO upstream, and I am all in favor of making that the only/default mode then too. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D93079/new/ https://reviews.llvm.org/D93079 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
