This enables the LLVM optimizer to view accesses to distinct struct
members as independent, also for array members. For example, the
following two stores no longer alias:

    struct S { int a[10]; int b; };
    void test(S *p, int i) {
      p->a[i] = ...;
      p->b = ...;
    }

Array members were already added to TBAA struct type nodes in commit
57493e29. Here, we extend a path tag for an array subscript expression.

Commit 77d3f8a avoids distinct tags for any pointers where the ultimate
pointee type is `void`, to solve breakage in real-world code that uses
(indirections to) `void*` for polymorphism over different pointer types.

While this matches the TBAA implementation in GCC, this patch implements
a refinement that distinguishes void pointers by pointer depth, as
described in the "strict aliasing" documentation included in the
aforementioned commit:
> `void*` is permitted to alias any pointer type, `void**` is permitted
> to alias any pointer to pointer type, and so on.

For example, `void**` is no longer considered to alias `int*` in this
refinement, but it remains possible to use `void**` for polymorphism
over pointers to pointers.

While there are no special rules in the standards regarding void
pointers and strict aliasing, emitting distinct tags for void pointers
break some common idioms and there is no good alternative to re-write
the code without strict-aliasing violations. An example is to count the
entries in an array of pointers:

    int count_elements(void * values) {
      void **seq = values;
      int count;
      for (count = 0; seq && seq[count]; count++);
      return count;
    }

https://clang.godbolt.org/z/8dTv51v8W

An example in the wild is from
https://github.com/llvm/llvm-project/issues/119099

This patch avoids emitting distinct tags for void pointers, to avoid
those idioms causing mis-compiles for now.

Fixes https://github.com/llvm/llvm-project/issues/119099.
Fixes https://github.com/llvm/llvm-project/issues/122537.

PR: https://github.com/llvm/llvm-project/pull/122116

This patch introduces the Clang components of type sanitizer: a
sanitizer for type-based aliasing violations.

It is based on Hal Finkel's https://reviews.llvm.org/D32198.

The Clang changes are mostly formulaic, the one specific change being
that when the TBAA sanitizer is enabled, TBAA is always generated, even
at -O0.

It goes together with the corresponding LLVM changes
(https://github.com/llvm/llvm-project/pull/76259) and compiler-rt
changes (https://github.com/llvm/llvm-project/pull/76261)

PR: https://github.com/llvm/llvm-project/pull/76260

For unnamed structs or unions, C's compatible types rule applies. Two
compatible types in different compilation units can have different
mangled names, meaning the metadata emitted below would incorrectly mark
them as no-alias. Use AnyPtr for such types in both C and C++, as C and
C++ types may be visible when doing LTO.

PR: https://github.com/llvm/llvm-project/pull/116596

Be conservative if the type isn't a record type. Handling other types
may
require stripping const-qualifiers inside the type, e.g.
MemberPointerType.

Also look through array types same as through pointer types, to not
pessimize
arrays of pointers.

Without this, we assign different tags to the accesses for p an q in the
second test in cwg158.

PR: https://github.com/llvm/llvm-project/pull/116991

Identified with misc-include-cleaner.

Extend the logic added in 123c036bd361d
(https://github.com/llvm/llvm-project/pull/76612) to support pointers to
non-builtin types by using the mangled name of the canonical type.

PR: https://github.com/llvm/llvm-project/pull/110569

In incremental compilation clang works with multiple `llvm::Module`s.
Our current approach is to create a CodeGenModule entity for every new
module request (via StartModule). However, some of the state such as the
mangle context needs to be preserved to keep the original semantics in
the ever-growing TU.

Fixes: llvm/llvm-project#95581.

cc: @jeaye

The constructor initializes `*this` with `M->getDataLayout()`, which
is effectively the same as calling the copy constructor.
There does not seem to be a case where a copy would be necessary.

Pull Request: https://github.com/llvm/llvm-project/pull/102841