[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

[Bruno De Fraine via cfe-commits]

brunodf-snps wrote:

> I'm surprised we need all this. Since we don't distinguish arrays from their elements in TBAA, is it not sufficient to just make sure that array subscript expressions produce an l-value with the same TBAA metadata as their base l-value?

The code is written after [this logic](https://github.com/brunodf-snps/llvm-project/blob/bba5ee5ed17af062f91604d3185d733df944df67/clang/lib/CodeGen/CGExpr.cpp#L5093-L5126) from EmitLValueForField. After investigation, I agree not all of it is needed. An array type is not a valid TBAA base type, so I've removed those lines now. But the rest I would keep though:
- In `ArrayLV.getTBAAInfo()`, the TBAA access info from the base l-value, we at least have to update the access size (an element is smaller than the entire array).
- Except when the access info is `MayAlias`, then we should just stay at `MayAlias`. Note: this triggers for an array like:
  ```
  typedef int __attribute__((may_alias)) aliasing_array[10];
  aliasing_array arr;
  ```
- When the array access info is `Incomplete`, the access to the element is nonetheless ordinary. So we have to handle this specifically.
- Despite that we represent arrays as their elements in TBAA, I found a case where also the access type from the array access info is not correct.
  ```
  typedef int __attribute__((may_alias)) aliasing_int;
  aliasing_int arr[10];
  ```
  When the TBAA access info is computed for the array, its type will be canonicalized [here](https://github.com/brunodf-snps/llvm-project/blob/bba5ee5ed17af062f91604d3185d733df944df67/clang/lib/CodeGen/CodeGenTBAA.cpp#L381) into `int[10]`, so we end up with the MDNode for "int" as the access type. While if we reset the access type from the element type `aliasing_int`, it will be the correct MDNode of "omnipotent char".

https://github.com/llvm/llvm-project/pull/137719