efriedma-quic wrote:
> IIUC you're suggesting movint the TBAA data origination from CodeGen into
> (probably) Sema and/or TargetInfo and then deriving the LLVM info in CodeGen
> from that. I.e. keep once source of truth, but move where it is?
Right; move the core computation to AST, and then t
urnathan wrote:
> On the LLVM side, there's very little interesting logic; it's basically just
> walking the tree of metadata nodes generated by clang. See
> https://llvm.org/docs/LangRef.html#tbaa-node-semantics . The hard part of the
> refactoring would just be adding an abstraction for the
efriedma-quic wrote:
> > Making Sema pull the TBAA info out of clang/lib/CodeGen is a layering
> > violation (and probably breaks if we aren't actually generating code). If
> > we need some notion of "aliasing" in Sema, we should pull the relevant code
> > into clang/lib/AST.
>
> That's unfor
urnathan wrote:
> > > FWIW the GCC doc is
> > > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstrict-aliasing_003dn
> > > It says for Level 3 "If optimization is enabled, it also runs in the
> > > back end, where it deals with multiple statement cases using
> > > flow-sensiti
@@ -498,3 +498,137 @@
CodeGenTBAA::mergeTBAAInfoForMemoryTransfer(TBAAAccessInfo DestInfo,
// access type regardless of their base types.
return TBAAAccessInfo::getMayAliasInfo();
}
+
+// Determine the aliasing kind bit-converting from type Src to type Dst.
+CodeGenTBAA::A
@@ -37,6 +38,27 @@ class ASTConsumer {
friend class SemaConsumer;
+public:
+ /// Allow type-based aliasing information to be interrogated by the AST
+ /// producer (for diagnostics).
+ class TypeAliasing {
urnathan wrote:
Oh, we also endup deriving from
@@ -0,0 +1,192 @@
+// RUN: %clang_cc1 %s -O0 -Wstrict-aliasing -S -o %t -verify=quiet
+// RUN: %clang_cc1 %s -O2 -Wstrict-aliasing=0 -S -o %t -verify=quiet
+// RUN: %clang_cc1 %s -O2 -Wno-strict-aliasing -S -o %t -verify=quiet
+// RUN: %clang_cc1 %s -O2 -Wstrict-aliasing=1 -S -o %
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/74155
>From 89c05618bb75fd073343046f3b54bde5f2254719 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Wed, 15 Nov 2023 15:27:16 -0500
Subject: [PATCH 1/6] [clang] Strict aliasing warning ala GCC [PR50066]
This imp
@@ -128,6 +128,10 @@ class DiagnosticOptions : public
RefCountedBase{
/// whether -Wsystem-headers is enabled on a per-module basis.
std::vector SystemHeaderWarningsModules;
+ /// Level of scrutiny reinterpret_casts get for type-unsafe aliasing
+ /// checks. Requires an
@@ -498,3 +498,137 @@
CodeGenTBAA::mergeTBAAInfoForMemoryTransfer(TBAAAccessInfo DestInfo,
// access type regardless of their base types.
return TBAAAccessInfo::getMayAliasInfo();
}
+
+// Determine the aliasing kind bit-converting from type Src to type Dst.
+CodeGenTBAA::A
@@ -37,6 +38,27 @@ class ASTConsumer {
friend class SemaConsumer;
+public:
+ /// Allow type-based aliasing information to be interrogated by the AST
+ /// producer (for diagnostics).
+ class TypeAliasing {
Endilll wrote:
Sorry I didn't make myself clear
@@ -498,3 +498,137 @@
CodeGenTBAA::mergeTBAAInfoForMemoryTransfer(TBAAAccessInfo DestInfo,
// access type regardless of their base types.
return TBAAAccessInfo::getMayAliasInfo();
}
+
+// Determine the aliasing kind bit-converting from type Src to type Dst.
+CodeGenTBAA::A
AaronBallman wrote:
> > FWIW the GCC doc is
> > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstrict-aliasing_003dn
> > It says for Level 3 "If optimization is enabled, it also runs in the back
> > end, where it deals with multiple statement cases using flow-sensitive
> > poi
https://github.com/urnathan edited
https://github.com/llvm/llvm-project/pull/74155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
> Thank you for your efforts! I scratched the surface a bit; not qualified to
> do an in-depth review. Can you also add a release note?
Thanks for your comments. A release note is added.
https://github.com/llvm/llvm-project/pull/74155
__
urnathan wrote:
> FWIW the GCC doc is
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstrict-aliasing_003dn
> It says for Level 3 "If optimization is enabled, it also runs in the back
> end, where it deals with multiple statement cases using flow-sensitive
> points-to informa
urnathan wrote:
> Making Sema pull the TBAA info out of clang/lib/CodeGen is a layering
> violation (and probably breaks if we aren't actually generating code). If we
> need some notion of "aliasing" in Sema, we should pull the relevant code into
> clang/lib/AST.
That's unfortunate. The code
@@ -2026,6 +2027,137 @@ static TryCastResult TryConstCast(Sema &Self,
ExprResult &SrcExpr,
return TC_Success;
}
+// We're dereferencing E, either by turning into an RValue, or by dereferencing
+// it. Check whether it's a deref of a reinterpret cast that has aliasing
+// is
@@ -498,3 +498,137 @@
CodeGenTBAA::mergeTBAAInfoForMemoryTransfer(TBAAAccessInfo DestInfo,
// access type regardless of their base types.
return TBAAAccessInfo::getMayAliasInfo();
}
+
+// Determine the aliasing kind bit-converting from type Src to type Dst.
+CodeGenTBAA::A
@@ -498,3 +498,137 @@
CodeGenTBAA::mergeTBAAInfoForMemoryTransfer(TBAAAccessInfo DestInfo,
// access type regardless of their base types.
return TBAAAccessInfo::getMayAliasInfo();
}
+
+// Determine the aliasing kind bit-converting from type Src to type Dst.
+CodeGenTBAA::A
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/74155
>From 89c05618bb75fd073343046f3b54bde5f2254719 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Wed, 15 Nov 2023 15:27:16 -0500
Subject: [PATCH 1/5] [clang] Strict aliasing warning ala GCC [PR50066]
This imp
MaskRay wrote:
Add @shafik who authors
https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8 ("Although
clang allows these flags it apparently does not actually implement the
warnings")
> [*] I implemented what turned into GCC's level=1 way back when.
Cool!
FWIW the GCC doc is
ht
@@ -0,0 +1,192 @@
+// RUN: %clang_cc1 %s -O0 -Wstrict-aliasing -S -o %t -verify=quiet
+// RUN: %clang_cc1 %s -O2 -Wstrict-aliasing=0 -S -o %t -verify=quiet
+// RUN: %clang_cc1 %s -O2 -Wno-strict-aliasing -S -o %t -verify=quiet
+// RUN: %clang_cc1 %s -O2 -Wstrict-aliasing=1 -S -o %
efriedma-quic wrote:
Making Sema pull the TBAA info out of clang/lib/CodeGen is a layering violation
(and probably breaks if we aren't actually generating code). If we need some
notion of "aliasing" in Sema, we should pull the relevant code into
clang/lib/AST.
I don't have any experience wit
@@ -128,6 +128,10 @@ class DiagnosticOptions : public
RefCountedBase{
/// whether -Wsystem-headers is enabled on a per-module basis.
std::vector SystemHeaderWarningsModules;
+ /// Level of scrutiny reinterpret_casts get for type-unsafe aliasing
+ /// checks. Requires an
@@ -498,3 +498,137 @@
CodeGenTBAA::mergeTBAAInfoForMemoryTransfer(TBAAAccessInfo DestInfo,
// access type regardless of their base types.
return TBAAAccessInfo::getMayAliasInfo();
}
+
+// Determine the aliasing kind bit-converting from type Src to type Dst.
+CodeGenTBAA::A
@@ -37,6 +38,27 @@ class ASTConsumer {
friend class SemaConsumer;
+public:
+ /// Allow type-based aliasing information to be interrogated by the AST
+ /// producer (for diagnostics).
+ class TypeAliasing {
Endilll wrote:
It seems to me that we'd be bett
@@ -2026,6 +2027,137 @@ static TryCastResult TryConstCast(Sema &Self,
ExprResult &SrcExpr,
return TC_Success;
}
+// We're dereferencing E, either by turning into an RValue, or by dereferencing
+// it. Check whether it's a deref of a reinterpret cast that has aliasing
+// is
@@ -498,3 +498,137 @@
CodeGenTBAA::mergeTBAAInfoForMemoryTransfer(TBAAAccessInfo DestInfo,
// access type regardless of their base types.
return TBAAAccessInfo::getMayAliasInfo();
}
+
+// Determine the aliasing kind bit-converting from type Src to type Dst.
+CodeGenTBAA::A
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/74155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Endilll commented:
Thank you for your efforts!
I scratched the surface a bit; not qualified to do an in-depth review.
Can you also add a release note?
https://github.com/llvm/llvm-project/pull/74155
___
cfe-commits mailing list
cfe-c
https://github.com/urnathan edited
https://github.com/llvm/llvm-project/pull/74155
___
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
@llvm/pr-subscribers-clang-codegen
Author: Nathan Sidwell (urnathan)
Changes
This implements -Wstrict-aliasing(=[123])? along the same lines as GCC. It's
not 100% the same for reasons expanded on below. The default is level 3, and I
have verified
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/74155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/74155
This implements -Wstrict-aliasing(=[123])? along the same lines as GCC. It's
not 100% the same for reasons expanded on below. The default is level 3, and I
have verified that bootstrapping does not trigger any
35 matches
Mail list logo
