llvm dev - Jan 2020 - Question about struct vs scalar access tags

It seems that the latest version of TBAA access tags allow specifying that
one is accessing an entire struct in a single instruction.  However, I'd
then expect that it would detect that an access to some scalar that
conflicts with the struct would conflict with that instruction.  However,
that's not the case.  Consider:

  store [2 x i32] %10, [2 x i32]* %procgGP393__ga11, align 8, !tbaa !14

Where we have:

!14 = !{!15, !15, i64 0, i64 8}
!15 = !{!3, i64 8, !"c43204h__procgGP393__T7b#TN#AD", !16, i64 0, i64
4, !17, i64 4, i64 4}
!16 = !{!12, i64 4, !"integer#T6"}
!17 = !{!12, i64 4, !"integer#T7"}

So that store references a structure (in this case array) that has two
fields, both of which have parents of !12, which is:

!12 = !{!1, i64 4, !"integer#T2"}

We then have a store:

  store i32 %8, i32* %9, align 4, !tbaa !0

with:

!0 = !{!1, !1, i64 0, i64 4}

Shouldn't that access conflict with the first access?

It doesn't seem to because hasField in TypeBasedAliasAnalysis.cpp just
checks for an exact match or being recursively true.  But that seems to
me to be wrong: you have to test whether the other access "matches",
not
just is exactly the same tag.

In other words, I think that test should be the equivalent of:

     if (matchAccessTags(createAccessTag(T.getNode()),
                      createAccessTag(FieldType.getNode())))

I have a .ll file that's optimized wrong because of this that gets optimized
properly when I make the above change.  I don't think the above is the best
patch (and don't understand the code well enough to suggest a simpler one),
but would like to know whether this is a real bug (with that as the rough
fix) or if I'm misunderstanding something.