asan coverage

Project Infrastructure LLVM Dev List Archives
41

I'm surprised too, but it makes some sense.

  - Most functions in the implementation details of the STL have long enough mangled
    names (and little enough control flow) that the names would dominate the size
    overhead.

  - Many class member functions will have this property, too, like getters, setters,
    and typical constructors, copy/move operators, and destructors.

There's likely a way to emit these names more compactly using a tree (with links
to parent nodes).

Consider _ZN9Namespace5Class3fooEv, the mangled name for Namespace::Class::foo().
We could do something like this:

    %__llvm_profile_name = type {i8*, %__llvm_profile_name*}

    @__llvm_profile_str__ZN = linkonce constant [4 x i8] c"_ZN\00"
    @__llvm_profile_name__ZN = linkonce constant %__llvm_profile_name {
      i8* getelementptr ([4 x i8]* @__llvm_profile_str__ZN, i32 0, i32 0),
      %__llvm_profile_name* null }

    @__llvm_profile_str_9Namespace = linkonce constant [11 x i8] c"9Namespace\00"
    @__llvm_profile_name__ZN9Namespace = linkonce constant %__llvm_profile_name {
      i8* getelementptr ([11 x i8]* @__llvm_profile_str_9Namespace, i32 0, i32 0),
      %__llvm_profile_name* @__llvm_profile_name__ZN }

    @__llvm_profile_str_5Class = linkonce constant [7 x i8] c"5Class\00"
    @__llvm_profile_name__ZN9Namespace5Class = linkonce constant
      %__llvm_profile_name {
      i8* getelementptr ([7 x i8]* @__llvm_profile_str_5Class, i32 0, i32 0),
      %__llvm_profile_name* @__llvm_profile_name__ZN9Namespace }

    @__llvm_profile_str_3fooEv = linkonce constant [7 x i8] c"3fooEv\00"
    @__llvm_profile_name__ZN9Namespace5Class3fooEv = linkonce constant
      %__llvm_profile_name {
      i8* getelementptr ([7 x i8]* @__llvm_profile_str_3fooEv, i32 0, i32 0),
      %__llvm_profile_name* @__llvm_profile_name__ZN9Namespace5Class }

Then _ZN9Namespace5Class3barEv (Namespace::Class::bar()) would be cheap.

    @__llvm_profile_str_3barEv = linkonce constant [7 x i8] c"3barEv\00"
    @__llvm_profile_name__ZN9Namespace5Class3barEv = linkonce constant
      %__llvm_profile_name {
      i8* getelementptr ([7 x i8]* @__llvm_profile_str_3barEv, i32 0, i32 0),
      %__llvm_profile_name* @__llvm_profile_name__ZN9Namespace5Class }

These would merge cleanly even between object files generated from different
translation units.

Doing it like that requires understanding the mangling and wouldn't compact common
prefixes in C. We could do something similar with a heuristic (split every 8
characters), or split on common prefixes per translation unit (and hope they line up
between translation units).