This is an archive of the discontinued LLVM Phabricator instance.

CodeGen: Allow annotations on globals in non-zero address space
ClosedPublic

Authored by nhaehnle on Dec 9 2019, 6:50 AM.

Details

Summary

Attribute annotations are recorded in a special global composite variable
that points to annotation strings and the annotated objects.

As a restriction of the LLVM IR type system, those pointers are all
pointers to address space 0, so let's insert an addrspacecast when the
annotated global is in a non-0 address space.

Since this addrspacecast is only reachable from the global annotations
object, this should allow us to represent annotations on all globals
regardless of which addrspacecasts are usually legal for the target.

Diff Detail

Event Timeline

nhaehnle created this revision.Dec 9 2019, 6:50 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 9 2019, 6:50 AM

Build result: pass - 60628 tests passed, 0 failed and 726 were skipped.

Log files: console-log.txt, CMakeCache.txt

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
  • whether this will interfere with someday having an invariant that addrspacecast is only used to do legal conversions.

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...

  • 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...

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.

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?

Annotations don't seem to be used for much at the moment in the first place. They're definitely not emitted in the resulting binary by default. Also, the only testcase in LLVM proper that has @llvm.global.annotations also happens to have addrspacecasts in there, so at least at some point in the past somebody thought it's okay to allow those casts there.

Also: what's the alternative?

rjmccall accepted this revision.Dec 10 2019, 9:46 PM

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?

Annotations don't seem to be used for much at the moment in the first place. They're definitely not emitted in the resulting binary by default. Also, the only testcase in LLVM proper that has @llvm.global.annotations also happens to have addrspacecasts in there, so at least at some point in the past somebody thought it's okay to allow those casts there.

Alright, I relent. This looks okay to me.

This revision is now accepted and ready to land.Dec 10 2019, 9:46 PM
This revision was automatically updated to reflect the committed changes.