This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] Fix generation of TBAA tags for may-alias accesses
ClosedPublic

Authored by kosarev on Jan 22 2018, 5:45 AM.

Details

Summary

This patch fixes creating TBAA access descriptors for may_alias-marked access types. Currently, for such types we generate ordinary descriptors with char as its access type. The patch changes this to produce proper may-alias descriptors.

Diff Detail

Repository
rC Clang

Event Timeline

kosarev created this revision.Jan 22 2018, 5:45 AM
rjmccall added inline comments.Jan 22 2018, 9:09 AM
lib/CodeGen/CodeGenTBAA.h
67

Hmm. I think you should talk this part over with Hal. If the size should be ignored then I think it's better to just leave this as 0; it's certainly easier to recognize 0 as a "size unknown" value.

kosarev added inline comments.Jan 29 2018, 7:42 AM
lib/CodeGen/CodeGenTBAA.h
67

Hal, in D41501 we use UINT64_MAX as the "unknown" size value. Should we do the same here?

Hal, will you please take a look?

Hal, a friendly ping.

John, the patch hangs for about a month now and Hal still seems to be extremely busy. Can we commit this with the constant to be whatever you think is most correct and the fix it as needed and if needed later? At this very moment we don't analyze the size fields of tags anyway, so the point of this patch is mostly to handle may-alias-marked types correctly.

kosarev updated this revision to Diff 134877.Feb 19 2018, 3:04 AM
kosarev edited the summary of this revision. (Show Details)

Do not change the size field of may-alias TBAA descriptors for now.

rjmccall accepted this revision.Feb 19 2018, 8:23 AM

I'm fine with that plan. LGTM.

This revision is now accepted and ready to land.Feb 19 2018, 8:23 AM
asl added a subscriber: asl.Feb 19 2018, 12:01 PM
This revision was automatically updated to reflect the committed changes.

I'm fine with that plan. LGTM.

Thanks.

We should probably discuss what we want to do with unknown-sized things. UINT64_MAX is the conservative answer, but maybe there's some value in just having 0 mean "unknown size" so we don't need to encode a bunch of UINT64_MAX values at the IR level.

I think zero would serve better as the unknown-size value. People who are not aware of TBAA internals would guess that since zero-sized accesses make no sense, they are likely to have some special meaning. Similarly, for code that is supposed to process the size fields of access descriptors zero would be an obvious "illegal size value". In contrast, UINT64_MAX is just a very large number that doesn't hint anything on its special purpose.

Either way, we should reflect the convention in the documentation, D40975.

I think zero would serve better as the unknown-size value. People who are not aware of TBAA internals would guess that since zero-sized accesses make no sense, they are likely to have some special meaning. Similarly, for code that is supposed to process the size fields of access descriptors zero would be an obvious "illegal size value". In contrast, UINT64_MAX is just a very large number that doesn't hint anything on its special purpose.

My thoughts exactly.

John.

I think zero would serve better as the unknown-size value. People who are not aware of TBAA internals would guess that since zero-sized accesses make no sense, they are likely to have some special meaning. Similarly, for code that is supposed to process the size fields of access descriptors zero would be an obvious "illegal size value". In contrast, UINT64_MAX is just a very large number that doesn't hint anything on its special purpose.

My thoughts exactly.

John.

SGTM. Let's do that.