UBSan blacklist workaround for bot timeouts

[vlad.tsyrklevich]

Summary

Workaround for PR37929

[eugenis]

This looks very brittle. Any change to function signature, and good luck finding out why compilation is suddenly 5x slower.

WDYT about modifying the code generator to add no_sanitize attribute to the function?

[vitalybuka]

+1 for no_sanitize attribute

[eugenis]

I guess, adding a few wildcards to the suppression to match only the function and/or class name would also be acceptable.

[vlad.tsyrklevich]

In D48566#1142778, @eugenis wrote:

I guess, adding a few wildcards to the suppression to match only the function and/or class name would also be acceptable.

The reason I prefer the blacklist approach is that it doesn't bleed an aarch64-specific ubsan failure into common code generation routines.

[vlad.tsyrklevich]

• Make blacklist entry more generic

llvm/trunk/utils/sanitizers/ubsan_blacklist.txt

 # This blacklist should be applied when LLVM is built
 # with -fsanitize=undefined instrumentation. It exists
 # because libstdc++ has some undefined behavior issues
 # in some of the headers, in particular, stl_tree.h.
 
 # upcast of address with insufficient space for an object of type std::_Rb_tree_node<...>
 src:*bits/stl_tree.h
 
 # libstdc++ 4.8 creates a null reference when calling
 # data() on an empty vector: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59829
 src:*bits/stl_iterator.h
 src:*bits/stl_vector.h
+
+# These auto-generated functions compile down to ~50k basic blocks with inlining
+# and UBSan enabled, causing long builds that lead to bot timeouts.
+# https://bugs.llvm.org/show_bug.cgi?id=37929
+fun:*AArch64*InstPrinter*printAliasInstr*