The motivation behind this proposal is to make it possible to
propagate TBAA information through scalarizing transformations,
such as SROA, that rewrite accesses to aggregates, e.g., memcpy()
calls, into accesses to scalars, that is, load and store
Currently, we decorate instructions that initialize and copy
aggregates with !tbaa.struct tags that generally cannot be
transformed to !tbaa tags. For this reason every time we
scalarize an aggregate, we leave resulting loads and stores
undecorated, meaning optimization of such instructions cannot
benefit from TBAA.
Furthermore, our analysis indicates that the only place where
!tbaa.struct tags may potentially impact code generation is
simplification of memcpy() and memmove() calls, see
SimplifyMemTransfer() in InstCombineCalls.cpp. Ironically, what
the code that makes that sole use of such tags is trying to do is
to construct a !tbaa tag from the information encoded in the
given !tbaa.struct tag. Note that it can only do that if the
!tbaa.struct tag describes a structure with a single member of a
Here's how we propose to resolve the issue in terms of specific
1. Extend the TBAA facilities in clang to support aggregate types
as final access types. This patch:
\[CodeGen\] Propagate may\-alias'ness of lvalues with TBAA info https://reviews.llvm.org/D39008 implements this for the needs of fixing issues with propagation of TBAA information, which in turn is necessary to support TBAA for unions\. So once this patch is committed, this step is done\.
2. Generate !tbaa tags in addition to !tbaa.struct tags for
3. Fix the TBAA analysis to support aggregate accesses as
explained in this proposal:
RFC: Resolving TBAA issues http://lists.llvm.org/pipermail/llvm-dev/2017-August/116652.html
4. Switch the code that simplifies memcpy() and memmove() calls
to !tbaa tags.
5. Remove the support for !tbaa.struct tags.
I guess we would want to remove all code which only purpose is to generate such tags, but I'm not sure what we should do with the MD\_tbaa\_struct enumerator\. Some possible options: a\) Leave it as is, just don't use it\. b\) Rename to something like MD\_unused\. c\) Remove, but do not change the values of other MD\_\* enumerators\. d\) Remove and adjust values of other MD\_\* enumerators respectively\. Or, maybe we want some multi\-stage plan here?
Further steps are supposed to include things like fixing SROA to
propagate TBAA information.
Any feedback is highly appreciated.