[llvm-dev] RFC: Generate plain !tbaa tags in place of !tbaa.struct ones

[Ivan Kosarev via llvm-dev]

In short, the problem with !tbaa.struct is that in most cases it cannot 
be converted to !tbaa. For transformations like SROA this means they 
cannot propagate !tbaa.struct tags for aggregate-accessing instructions 
like memcpy() calls to the resulting loads and stores.


On 31/10/17 05:11, Hal Finkel wrote:
>
> On 10/18/2017 05:49 AM, Ivan Kosarev via llvm-dev wrote:
>> Hello,
>>
>> 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
>> instructions.
>>
>> 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.
>
> I understand that we'd like to improve TBAA in a number of different 
> ways, and that probably involves replacing !tbaa.struct with an 
> enhanced !tbaa representation, but I don't understand the point of 
> this proposal. As you state, there are lots of places that could use 
> !tbaa.struct information, such as SROA, but don't. Is the current 
> !tbaa.struct missing some information that is essential for that purpose?
>
>  -Hal
>
>>
>> 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
>> scalar type.
>>
>> Here's how we propose to resolve the issue in terms of specific
>> steps:
>>
>> 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
>>    aggregate accesses.
>>
>> 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.
>>
>> Thanks,
>>
>