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
