david-arm wrote: Hi @AaronBallman, yes the problem I found with always choosing `char` as the alias type is that LLVM will just assume that enum types alias with absolutely everything. This is a conservative approach that works fine, but it does prevent important type-based alias optimisations from happening. GCC seems to take advantage of the fact that enums without any explicit type should be compatible with an `int` (or a suitable integer that the compiler is free to choose that can contain all enumerated values). Consequently it can be more aggressive in optimisations, which is why I started looking at the C specification to understand the rules. If my understanding is correct, I think the important thing is that the type-based alias information should match the actual underlying type we've chosen for the enum. It could be, for example that in the case of an enum like this:
``` enum Foo { A = 1, B = 0x100000000ull }; ``` gcc chooses a `long long` and clang chooses a `long` since there seems to be wiggle room in the specification. I think that's fine provided the compiler is self-consistent. In either case both `long` and `long long` would not alias with `int` or `short`, which is still an improvement on treating it as a `char` in TBAA info. https://github.com/llvm/llvm-project/pull/73326 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits