[llvm-dev] llvm-ir: anonymous struct name mangling

[Florian Hahn via llvm-dev]

Hi,

> On Nov 10, 2020, at 11:08, Jeroen Dobbelaere via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> Nikita pointed me to an issue in the full restrict patches, related to name mangling used for llvm-ir functions (See [0, 3]).
> 

> 
> The problem is the following: Given:
> 
>  %0 = type { i32 }
>  %1 = type { i32 }
> 
> 
> Creating an intrinsic @llvm.FOO that accepts 'a pointer to %0' cannot be distinguished from the intrinsic accepting 'a pointer to %1':
>  ;For a %0* ptr0, %1* ptr1  
> 
>  call @llvm.FOO.p0s_s %0* %ptr0
>  call @llvm.FOO.p0s_s %1* %ptr1   ; assertion failure: same name produced, but %ptr1 is not compatible with '%0*'
> 
> It seems that the name mangling is not coping well with anonymous structs ?
> See: [1,2]: All anonymous structs get a 's_s' mangling. Still, %0 and %1 are treated as different types.
> 
> Any idea what the best way is to handle (or fix) this ?
> (My feeling is that the name mangling should be improved, but at the moment I have no clue what the right approach would be)

I’ve run into this issue in the past with PredicateInfo which inserts @llvm.ssa.copy calls. See https://bugs.llvm.org/show_bug.cgi?id=38117 for a bit more additional context.

PredicateInfo and the passes using it do not really care about the name suffix, as long as there are no clashes. As a workaround, PredicateInfo creates its own suffixes by including the type pointer addresses in the name. (https://github.com/llvm/llvm-project/commit/36d2e25d5a834fd9609c6f2fd54482438643ad7f#diff-e8b8656939fffd64a98989a09a2712a4e181ca3c57d98ad2b7a9b4ae5f5273b3)

The suffixes won’t be deterministic, but it seems to work fine in practice for PredicateInfo and its clients, because all inserted calls & declarations are removed by the clients that required PredicateInfo.

But this workaround is likely not sufficient for the full-restrict intrinsics unfortunately.

Cheers,
Florian