[llvm-dev] An ambiguity in TBAA info format

[Ivan Kosarev via llvm-dev]

On 31/10/17 10:37, Ivan Kosarev wrote:
>
>>> We know that, being interpreted as structure accesses, they still 
>>> should be considered no-alias. However, the least common type group 
>>> for these types is likely to be the "omnipotent char" node, but 
>>> certainly not the type of the field, which is "int".
>>
>> I'm not sure what "likely" means in this context. 
>> MDNode::getMostGenericTBAA does not currently seem to have a special 
>> case for the first member of structure types. Instead, it does not 
>> deal with them at all. MDNode::getMostGenericTBAA looks as the access 
>> type, which should be a scalar, and collects the paths from those 
>> types up to the root. Then it returns a scalar access tag for the 
>> type which is common, and most distant from the root, along those paths.
>>
>> Are you trying to extend this to do something else with the 
>> struct/member information on the accesses?
>
> Yes, sorry I didn't mention that MDNode::getMostGenericTBAA() 
> currently only considers final access types.
>
> This is supposed to get us closer to the support for aggregate 
> accesses, but at this moment I'm trying to fix 
> MDNode::getMostGenericTBAA() to handle struct-path accesses.

I think you are right, I can do this without changing the format. If 
neither of the accesses encloses the other, then we can determine the 
common group for the final access types and build a tag for it. This is 
what MDNode::getMostGenericTBAA() currently does and it seems to be the 
right thing to do. OK, will update the diff respectively and put it on 
review soon.

Still, the problem remains if we want to support aggregate final access 
types as they have no parent types. Furthermore, if we will ever decide 
that we want a new format for TBAA metadata, then we probably want 
consider adding information about sizes as mentioned in this patch:

https://reviews.llvm.org/D39455

Thanks,

--