[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