With this patch in place, when a new-format TBAA tag is available for a memory-transfer intrinsic call, we prefer propagating that new-format tag. Otherwise, we fallback to the old approach where we try to construct a proper TBAA access tag from 'tbaa.struct' metadata.
Sure, I add you to reviewers of LLVM patches related the TBAA changes to make sure you are aware of the progress in this part of the work. If adding you to subscribers is preferable, I think that would work too. Just let me know. Thanks.
I applied this patch (target: i686-pc-windows-msvc) and run the test. No TBAA decorations present in the output. When running struct-assign-tbaa.ll from the same directory, the TBAA decorations are observed.
|42 ↗||(On Diff #128015)|
Pointer size depends on the platform. I would recommend you to add a target layout. See struct-assign-tbaa.ll for example.
TBAA decorations are still absent in the case of struct-assign-tbaa-new.ll, but it does not caused by this patch. The module returned by parseIRFile does not contain TBAA metadata in the case of this test, while struct-assign-tbaa.ll works as expected. Looks like an issue of loading new TBAA data from .ll file.
I used Visual Studio 2015 14.0.25425.01 Update 3. With it TBAA decorations do not appear in opt output. On the other host I installed a fresh copy of Visual Studio 2015, it has version 14.0.25431.01 Update 3. On that host the metadata appears and test passes.