TBAA for struct fields

Project Infrastructure LLVM Dev List Archives
1

Hi,

Following issue is observed with Type Based Alias Analysis(TBAA).

2

This is happening because there is undefined behaviour in your example. In C, a struct P* must point to the start of a struct P, so the compiler can assume references to two different members do not alias. In your example, you’ve constructed p2 to point to the second member of the struct, which is not correct.

Clang reports this as a warning:

3

[AMD Public Use]

Hi Oliver,

I get rid of the warnings by explicitly type-casting it to struct*, and still get similar results.

4

I get rid of the warnings by explicitly type-casting it to struct*, and still get similar results.

Adding the explicit cast suppresses the warning, but the behaviour of the code is still undefined according to the C (and C++) standard.

Shouldn’t any alias analysis(including TBAA) be conservative in interprocedural context, and consider all aliasing possibilities between different fields?

TBAA doesn’t have to consider overlap between different fields, because different fields are not allowed to overlap.

For Clang, O1 onwards results are wrong!

Since the behaviour of the source code is undefined, a compiler can generate any code it wants to, and be correct.

If you really want to write code like this (though I’d strongly advise you not to, since it’s not correct portable C), you can disable type-based alias analysis with the -fno-strict-aliasing clang option.

Oliver

5

[AMD Public Use]

Hi Oliver,

Thanks for the clarification, but please consider the following:

For your point “TBAA doesn’t have to consider overlap between different fields, because different fields are not allowed to overlap”. Basically, TBBA

is aggressive in ignoring alias between different field types of a struct. Now, consider below:

6

I think that’s a limitation of LLVM’s current implementation of TBAA - it does not handle arrays inside structs, so must be conservative and return may-alias.

Oliver