[PATCH] D71208: CodeGen: Allow annotations on globals in non-zero address space
John McCall via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Dec 9 23:39:37 PST 2019
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
More information about the cfe-commits
mailing list