Naming and linkage for LLVM IR anonymous globals

While investigating https://github.com/llvm/llvm-project/issues/54813 I found that…

@0 = global i64 1

… when compiled with llc -o - testcase.ll, generates:

        .globl  __unnamed_1
__unnamed_1:

Which is an external linkage symbol. Should we be generating an internal symbol instead? E.g.

.L__unnamed_1:

If we did emit an internal symbol we would lose the ability to link anonymous globals across objects. On the other hand that seems fragile, and like something we probably want to discourage anyway.

Should we emit internal symbols for anonymous globals?
Is anyone aware of any use-cases for the existing behavior?

@dblaikie @arsenm

I don’t like the argument to use the name of the unnamed global to link it across object because it is a very edge case if people relying on that. On the other hand, it is very easy to break from any code change (like adding a new unnamed global can cause symbol name change, adding a new unnamed global from another module will create duplicated symbol).

I prefer the suggestion @dblaikie from Discord which is to add a verifier to force unnamed global to be private linkage with an upgrader to fix linkage from previous LLVM versions. I prefer this than using the local label because it is much easier to reason about the semantics of the unnamed global from LLVM IR level.

I prefer this than using the local label because it is much easier to reason about the semantics of the unnamed global from LLVM IR level.

We’ll have to lower these to local labels under either proposal, right? You’re just suggesting that we should verify that the llvm::GlobalValue instance’s linkage is private or internal if the name is empty?

For consistency, should we also require private linkage on symbols with linker-private prefixes?