@@ -196,6 +196,9 @@ C Language Changes
number of elements in the flexible array member. This information can improve
the results of the array bound sanitizer and the
``__builtin_dynamic_object_size`` builtin.
+- Enums will now be represented in TBAA metadata using their a
@@ -6376,13 +6376,26 @@ aliases a memory access with an access tag ``(BaseTy2,
AccessTy2,
Offset2)`` if either ``(BaseTy1, Offset1)`` is reachable from ``(Base2,
Offset2)`` via the ``Parent`` relation or vice versa.
+In C an enum will be compatible with an underlying integer
@@ -196,6 +196,9 @@ C Language Changes
number of elements in the flexible array member. This information can improve
the results of the array bound sanitizer and the
``__builtin_dynamic_object_size`` builtin.
+- Enums will now be represented in TBAA metadata using their a
https://github.com/paulwalker-arm approved this pull request.
This looks broadly good to me. I suggest reverting the LangRef change because
it doesn't add any new information relevant to LLVM IR.
https://github.com/llvm/llvm-project/pull/73326
___
cf
https://github.com/david-arm updated
https://github.com/llvm/llvm-project/pull/73326
>From af76f6b6b3469fd0f5f24427c5a175c8d9d7c83a Mon Sep 17 00:00:00 2001
From: David Sherwood
Date: Fri, 24 Nov 2023 13:20:23 +
Subject: [PATCH 1/4] [Clang] Emit TBAA info for enums in C
When emitting TBAA
momchil-velikov wrote:
I thought the suggestion was to add a few lines to
https://github.com/llvm/llvm-project/blob/main/clang/docs/ReleaseNotes.rst
https://github.com/llvm/llvm-project/pull/73326
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
david-arm wrote:
> Do you think it's worth adding something to the Clang release note?
Done. Hope the documentation I added makes sense!
https://github.com/llvm/llvm-project/pull/73326
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://li
https://github.com/david-arm updated
https://github.com/llvm/llvm-project/pull/73326
>From af76f6b6b3469fd0f5f24427c5a175c8d9d7c83a Mon Sep 17 00:00:00 2001
From: David Sherwood
Date: Fri, 24 Nov 2023 13:20:23 +
Subject: [PATCH 1/3] [Clang] Emit TBAA info for enums in C
When emitting TBAA
AaronBallman wrote:
> Do you think it's worth adding something to the Clang release note?
Yes, please!
https://github.com/llvm/llvm-project/pull/73326
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
paulwalker-arm wrote:
Do you think it's worth adding something to the Clang release note?
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-commit
rjmccall wrote:
This seems conservatively correct, yeah. My reading is that we could also use
the underlying type as a parent type for the TBAA metadata: enums are
compatible with their underlying type, but two enums with the same underlying
type are not compatible with each other. But this
efriedma-quic wrote:
The C notion of "compatibility" with regard to enums is a bit weird... clang
and gcc disagree whether `enum e : int; enum e2: int; enum e x; int x; enum e2
x;` is valid because 6.2.7 doesn't actually define what's supposed to happen.
Probably this should be illegal, but t
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
AaronBallman wrote:
> enums should be treated as 'int' types unless explicitly specified (C23) or
> if 'int' would not be large enough to hold all the enumerated values. In the
> latter case the compiler is free to choose a suitable integer that would hold
> all such values.
In C23, the enume
david-arm wrote:
Gentle ping!
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
@@ -196,11 +196,14 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
// Enum types are distinct types. In C++ they have "underlying types",
// however they aren't related for TBAA.
if (const EnumType *ETy = dyn_cast(Ty)) {
+if (!Features.CPlusPlus)
+
https://github.com/david-arm updated
https://github.com/llvm/llvm-project/pull/73326
>From af76f6b6b3469fd0f5f24427c5a175c8d9d7c83a Mon Sep 17 00:00:00 2001
From: David Sherwood
Date: Fri, 24 Nov 2023 13:20:23 +
Subject: [PATCH 1/2] [Clang] Emit TBAA info for enums in C
When emitting TBAA
@@ -196,11 +196,14 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
// Enum types are distinct types. In C++ they have "underlying types",
// however they aren't related for TBAA.
if (const EnumType *ETy = dyn_cast(Ty)) {
+if (!Features.CPlusPlus)
+
@@ -196,11 +196,14 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
// Enum types are distinct types. In C++ they have "underlying types",
// however they aren't related for TBAA.
if (const EnumType *ETy = dyn_cast(Ty)) {
+if (!Features.CPlusPlus)
+
https://github.com/david-arm edited
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
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: David Sherwood (david-arm)
Changes
When emitting TBAA information for enums in C code we currently just treat the
data as an 'omnipotent char'. However, with C strict aliasing this means we
fail to optimise certain cases. For example, in
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
Author: David Sherwood (david-arm)
Changes
When emitting TBAA information for enums in C code we currently just treat the
data as an 'omnipotent char'. However, with C strict aliasing this means we
fail to optimise certain cases. For exam
https://github.com/david-arm created
https://github.com/llvm/llvm-project/pull/73326
When emitting TBAA information for enums in C code we currently just treat the
data as an 'omnipotent char'. However, with C strict aliasing this means we
fail to optimise certain cases. For example, in the SP
23 matches
Mail list logo
