rjmccall added a comment. In D71208#1776633 <https://reviews.llvm.org/D71208#1776633>, @nhaehnle wrote:
> In D71208#1776202 <https://reviews.llvm.org/D71208#1776202>, @rjmccall wrote: > > > The questions I'd like to have answered before I can approve this are: > > > > - whether there are clients of `@llvm.global.annotations` that will have > > problems with non-0 address spaces and > > > Yes, that's where this patch is ultimately coming from. I have some > work-in-progress code to generate IRBuilder-using C++ code from LLVM IR, > which we're currently using internally (with plans to upstream later next > year) for an AMDGPU frontend, where non-0 address spaces are used. Using > annotations is the least-invasive way I've found to attach required > additional data to LLVM IR generated from C... My concern is that there's something that's going to blow up or miscompile if we start passing in constants that aren't in a regular address space. Aren't there kinds of annotations which get persisted into the emitted code? >> - whether this will interfere with someday having an invariant that >> `addrspacecast` is only used to do legal conversions. > > That could potentially be a problem at some point, but this patch isn't > making the situation any worse. Without this patch, Clang just > unconditionally crashes (hits an assertion) when there's an annotation on a > non-0 address space variable. With this patch, in the worst case the > crash/assertion comes later... Well, it's making it worse in the sense that this global-annotations list would become a blocker for tightening the representation. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71208/new/ https://reviews.llvm.org/D71208 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
