Question: llvm-link type merge behaviour of c++ classes

Hi LLVM community,

I'd like to ask a question regarding the behavior of llvm-link:

My code contains Classes which are structurally equivalent but they are totally unrelated and distinct on a c++ point of view.
However, if the compiled IR gets processed by llvm-link, these types are merged together.
My question is: Is this expected behavior or a bug?

To explain it more in detail, a reduced example follows:

IR code before llvm-link:

%class.Bakery = type { i32, i32 }
%class.Container = type { i8 }
%class.Rectangle = type <{ %class.Shape, i8, [3 x i8] }>
%class.Shape = type { i32, i32 }
define linkonce_odr dso_local void @_ZN9Container6insertEP5Shape(%class.Container*, %class.Shape*) #1 comdat align 2 { ... }

IR code after llvm-link:

%class.Bakery = type { i32, i32 }
%class.Container = type { i8 }
%class.Rectangle = type <{ %class.Bakery, i8, [3 x i8] }>
define linkonce_odr dso_local void @_ZN9Container6insertEP5Shape(%class.Container*, %class.Bakery*) #1 comdat align 2 { ... }

In this example the `Bakery` and `Shape` types get merged. The type definition of `Rectangle` reflects this change, too, but from my intuition, they should stay distinct. I've fond an article from Chris[1] where the new type system is described. There he states that the name gets part of the type. "This means that LLVM 3.0 doesn't exhibit the previous confusing behavior where two seemingly different structs would be printed with the same name."

So, if the name is part of the type and the "confusing behavior" is removed, why get these types merged? Is this the intended behavior?

My use-case and reason for all this comes from writing an analysis tool for IR code which gets stuck in finding matching calls for function pointers. The changing and merging in these types messes up the current logic of finding matching candidates.

To reproduce this code, find the c++ code below and use the following invocations:

clang++-9 -S -emit-llvm -o before_link.ll
llvm-link-9 -S before_link.ll -o after_link.ll

// #include "shapes.h"
// shapes.h content follows
class Shape {
    int width, height;

class Rectangle : public Shape {
    bool is_square;

class Container {
    void insert(Shape* s){};

// end shapes.h

// #include "bakery.h"
// bakery.h content follows:
class Bakery {
    int num_ovens, num_employees;
// end bakery.h

// some instances
Bakery b;

Container c;
Rectangle r;

void do_stuff() { c.insert(&r); }

void bake(Bakery* bakery) {}

My system:

clang++-9 --version
clang version 9.0.1-12
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

llvm-link-9 --version
  LLVM version 9.0.1
  Optimized build.
  Default target: x86_64-pc-linux-gnu
  Host CPU: skylake

Thanks in advance

[1] LLVM 3.0 Type System Rewrite - The LLVM Project Blog

Hi Björn,

I’m not particularly knowledgeable about the implementation of the llvm-link, but my guess is that the merging is intended there.
I had a very similar problem recently: basically the loss of information caused by IRLinker (the implementation behind llvm-link). I tried to dig into it to find if it’s possible to change the behavior, but stuck pretty quickly since the code there is not very intuitive (IMHO, of course).

I recall reading somewhere that the intention to merge structurally equivalent types was to get rid of “duplicated” types, i.e.:

You have a module A and a module B, both include a header with the same type resulting in the following bitcode:

; Module A
%struct.Shape = type { … }

; Module B
%struct.Shape = type { … }

However, when the modules are loaded in the same LLVM context you will see something like this:

; Module A
%struct.Shape = type { … }

; Module B
%struct.Shape.1 = type { … }

So in the end if you link them together you'll get:

; Module A+B merged
%struct.Shape = type { … }

Which is desired.
What is not desired, IMO, is the situation that you describe, i.e.: “different” types being merged regardless of their name.

So, in the end we decided not to use IRLinker at all and merge the types on our own, you can read more on the approach here: Type Equality in LLVM - Low Level Bits

I’m not sure if that helps at all, but you are definitely not the only one out there who is confused by the implementation :slight_smile:

Yeah, this is intentional (see the "The Linker "links" types and
retypes IR objects" part of the original 3.0 type rewrite post linked
in your email, Bjorn).

In general, don't rely on type information in LLVM IR for carrying any
semantic information from the source code beyond the practical
semantics of what to load from what offsets, alignment, etc. Those are
the semantics that are part of the IR and must be preserved through
optimizations, etc.


thanks for the clarification. I already read the "The Linker "links" types and retypes IR objects" part, but my understanding in combination with "Where type names were kept as an "on the side" hash table before, they are now an intrinsic part of a type, and the only types that can be named are identified structs." was that those types don't get merged as the name is contained somehow as an hash or something.

As Alex writes, even if this behavior is intended, it is a bit counter intuitive for me.
But nevertheless, it seems I have to work around without trusting in LLVM type information.