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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
