@@ -0,0 +1,494 @@
+//===-- RISCVSchedGenericOOO.td - Generic O3 Processor -*- tablegen
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,494 @@
+//===-- RISCVSchedGenericOOO.td - Generic O3 Processor -*- tablegen
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/dtcxzyw approved this pull request.
LG
https://github.com/llvm/llvm-project/pull/125880
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/127525
>From d931667e3b7e18f8ba6f054405ffc5fe2fac36b4 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 18 Feb 2025 01:26:26 +0800
Subject: [PATCH 1/3] [Clang][CodeGen] Bail out on constexpr unknown values in
Co
dtcxzyw wrote:
> Does it even make sense for evaluateValue to return a constexpr-unknown
> value? If I'm following correctly, we can't actually do anything useful with
> such a result: we don't actually know what the value is. It would make things
> simpler if we kept such APValues as an inter
https://github.com/dtcxzyw created
https://github.com/llvm/llvm-project/pull/128409
It is an alternative to https://github.com/llvm/llvm-project/pull/127525.
Close https://github.com/llvm/llvm-project/issues/127475.
>From 83248eb164ff53442ad6d0c9d1be20027519bac1 Mon Sep 17 00:00:00 2001
From:
@@ -122,9 +122,9 @@ namespace CaseStatements {
}
extern int &Recurse1;
-int &Recurse2 = Recurse1; // expected-note {{declared here}}
+int &Recurse2 = Recurse1; // pre-cxx23-note {{declared here}}
dtcxzyw wrote:
This is a regression.
https://github.com/llvm/l
dtcxzyw wrote:
> > Clang rejects the following case after modifying evaluateValue to treat
> > constexpr-unknown value as invalid
>
> I don't see the connection. At least, there isn't any obvious connection: the
> testcase doesn't require constexpr-unknown. Maybe you need to "reject" the
> va
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/128409
>From 83248eb164ff53442ad6d0c9d1be20027519bac1 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 18 Feb 2025 01:26:26 +0800
Subject: [PATCH 1/5] [Clang][CodeGen] Bail out on constexpr unknown values in
Co
https://github.com/dtcxzyw ready_for_review
https://github.com/llvm/llvm-project/pull/128409
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -17000,6 +16998,18 @@ bool Expr::EvaluateAsInitializer(APValue &Value, const
ASTContext &Ctx,
if (!Info.discardCleanups())
llvm_unreachable("Unhandled cleanup; missing full expression marker?");
+
+if (Value.allowConstexprUnknown()) {
+ assert(Value.isLV
https://github.com/dtcxzyw edited
https://github.com/llvm/llvm-project/pull/128409
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dtcxzyw wrote:
> Should the other Expr::Evaluate* entry points have the same bailout? Do you
> want to do that in this patch, or a followup?
Sorry I don't have enough bandwidth to work on other potential
constexpr-unknown-related issues. I just want to close
https://github.com/llvm/llvm-proje
https://github.com/dtcxzyw created
https://github.com/llvm/llvm-project/pull/127525
Close https://github.com/llvm/llvm-project/issues/127475
>From d931667e3b7e18f8ba6f054405ffc5fe2fac36b4 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 18 Feb 2025 01:26:26 +0800
Subject: [PATCH] [Clang
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/127525
>From d931667e3b7e18f8ba6f054405ffc5fe2fac36b4 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 18 Feb 2025 01:26:26 +0800
Subject: [PATCH 1/2] [Clang][CodeGen] Bail out on constexpr unknown values in
Co
https://github.com/dtcxzyw ready_for_review
https://github.com/llvm/llvm-project/pull/127525
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw edited
https://github.com/llvm/llvm-project/pull/127525
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw closed
https://github.com/llvm/llvm-project/pull/127525
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dtcxzyw wrote:
Closed in favor of https://github.com/llvm/llvm-project/pull/128409
https://github.com/llvm/llvm-project/pull/127525
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw closed
https://github.com/llvm/llvm-project/pull/128409
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw approved this pull request.
LGTM. Thank you!
https://github.com/llvm/llvm-project/pull/129868
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw edited
https://github.com/llvm/llvm-project/pull/130734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw created
https://github.com/llvm/llvm-project/pull/130734
In the LLVM middle-end we want to fold `gep inbounds null, idx -> null`:
https://alive2.llvm.org/ce/z/5ZkPx-
This pattern is common in real-world programs. Generally, it exists in some
(actually) unreachable bl
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/128409
>From 83248eb164ff53442ad6d0c9d1be20027519bac1 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 18 Feb 2025 01:26:26 +0800
Subject: [PATCH 1/6] [Clang][CodeGen] Bail out on constexpr unknown values in
Co
@@ -17000,6 +16998,18 @@ bool Expr::EvaluateAsInitializer(APValue &Value, const
ASTContext &Ctx,
if (!Info.discardCleanups())
llvm_unreachable("Unhandled cleanup; missing full expression marker?");
+
+if (Value.allowConstexprUnknown()) {
+ assert(Value.isLV
dtcxzyw wrote:
> If I am reading the code correctly there should be some constexpr cases that
> generate a diagnostic, can we verify that with a test?
It has been tested by the following case:
```
extern int &Recurse1;
int &Recurse2 = Recurse1;
int &Recurse1 = Recurse2;
constexpr int &Recurse3
@@ -93,7 +93,7 @@ LLVMState::LLVMState(std::unique_ptr TM,
std::unique_ptr LLVMState::createTargetMachine() const {
return std::unique_ptr(
TheTargetMachine->getTarget().createTargetMachine(
- TheTargetMachine->getTargetTriple().normalize(),
+ Triple(T
dtcxzyw wrote:
> I'd still prefer to get this right for all address-spaces, so we don't need
> to revisit later.
Sentinel pointer value support for non-0 address spaces is still work in
progress: https://github.com/llvm/llvm-project/pull/83109
I am ok to add a helper like `Address::isConstant
@@ -189,8 +190,10 @@ class LLVM_ABI Module {
std::string ModuleID; ///< Human readable identifier for the module
std::string SourceFileName; ///< Original source file name for module,
///< recorded in bitcode.
- std::string T
dtcxzyw wrote:
Please fix MLIR build failure.
https://github.com/llvm/llvm-project/pull/129868
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -79,7 +79,7 @@ SPIRVTranslate(Module *M, std::string &SpirvObj, std::string
&ErrMsg,
if (TargetTriple.getTriple().empty()) {
TargetTriple.setTriple(DefaultTriple);
-M->setTargetTriple(DefaultTriple);
+M->setTargetTriple(Triple(DefaultTriple));
---
@@ -139,7 +139,7 @@ class Lint : public InstVisitor {
Lint(Module *Mod, const DataLayout *DL, AliasAnalysis *AA,
AssumptionCache *AC, DominatorTree *DT, TargetLibraryInfo *TLI)
- : Mod(Mod), TT(Triple::normalize(Mod->getTargetTriple())), DL(DL),
AA(AA),
+ :
@@ -91,7 +91,7 @@ extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data,
size_t Size) {
}
// Set up the module to build for our target.
- M->setTargetTriple(TM->getTargetTriple().normalize());
+ M->setTargetTriple(Triple(TM->getTargetTriple().normalize()));
@@ -124,7 +124,7 @@ extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data,
size_t Size) {
// Set up target dependant options
//
- M->setTargetTriple(TM->getTargetTriple().normalize());
+ M->setTargetTriple(Triple(TM->getTargetTriple().normalize()));
@@ -114,7 +114,8 @@ std::unique_ptr llvm::parseInputFile(StringRef
Filename,
TargetTriple.setTriple(TheTriple.getTriple());
}
- Result->setTargetTriple(TargetTriple.getTriple()); // override the triple
+ // override the triple
+ Result->setTargetTriple(Triple(TargetT
@@ -515,12 +515,13 @@ static void splitCodeGen(const Config &C, TargetMachine
*TM,
static Expected initAndLookupTarget(const Config &C,
Module &Mod) {
if (!C.OverrideTriple.empty())
-Mod.setTargetTriple(C.OverrideTriple
@@ -200,7 +200,7 @@ LTOModule::makeLTOModule(MemoryBufferRef Buffer, const
TargetOptions &options,
return EC;
std::unique_ptr &M = *MOrErr;
- std::string TripleStr = M->getTargetTriple();
+ std::string TripleStr = M->getTargetTriple().str();
dtcxzyw w
@@ -153,7 +153,7 @@ struct VerifierSupport {
bool TreatBrokenDebugInfoAsError = true;
explicit VerifierSupport(raw_ostream *OS, const Module &M)
- : OS(OS), M(M), MST(&M), TT(Triple::normalize(M.getTargetTriple())),
+ : OS(OS), M(M), MST(&M), TT(M.getTargetTriple
https://github.com/dtcxzyw created
https://github.com/llvm/llvm-project/pull/130990
Closes https://github.com/llvm/llvm-project/issues/130093.
>From ea0d82d48d7a28467dc4e945314b57bc2b63085c Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Thu, 13 Mar 2025 00:39:09 +0800
Subject: [PATCH 1/2]
https://github.com/dtcxzyw approved this pull request.
https://github.com/llvm/llvm-project/pull/130940
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw approved this pull request.
LGTM. Thank you!
https://github.com/llvm/llvm-project/pull/130504
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw created
https://github.com/llvm/llvm-project/pull/130952
See also https://github.com/llvm/llvm-project/pull/130734 for the original
motivation.
This pattern (`container_of`) is also widely used by real-world programs.
Examples:
https://github.com/llvm/llvm-project/bl
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/130990
>From ea0d82d48d7a28467dc4e945314b57bc2b63085c Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Thu, 13 Mar 2025 00:39:09 +0800
Subject: [PATCH 1/3] [Clang][CodeGen][UBSan] Add pre-commit tests. NFC.
---
cla
dtcxzyw wrote:
> this check needs to happen at a higher level. And at that level, you should
> have an Expr*, not just an Address.
I tried to use `Expr::isNullPointerConstant` in
`CodeGenFunction::EmitMemberExpr`:
https://github.com/llvm/llvm-project/blob/59fd2878fce470f02058f43d4b818ed68ce040
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/130734
>From 02065e86c63ab3fbdefd2ce6e963ffeec96e6a24 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 11 Mar 2025 16:20:08 +0800
Subject: [PATCH 1/3] [Clang][CodeGen] Do not set inbounds flag for struct GEP
wi
https://github.com/dtcxzyw created
https://github.com/llvm/llvm-project/pull/131750
Closes https://github.com/llvm/llvm-project/issues/130958.
>From 0320afe33963e063915e53e05459566e7be8bc35 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 18 Mar 2025 15:52:32 +0800
Subject: [PATCH] [Cl
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/130734
>From b9876822acdca4eaea6496a1d6471e2c0f4ad2e1 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 11 Mar 2025 16:20:08 +0800
Subject: [PATCH 1/7] [Clang][CodeGen] Do not set inbounds flag for struct GEP
wi
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/130734
>From b9876822acdca4eaea6496a1d6471e2c0f4ad2e1 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 11 Mar 2025 16:20:08 +0800
Subject: [PATCH 1/6] [Clang][CodeGen] Do not set inbounds flag for struct GEP
wi
dtcxzyw wrote:
@efriedma-quic Any more comments?
https://github.com/llvm/llvm-project/pull/130734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/130990
>From 48f8e2591c317f90eff6f1d0a4ecdf27e19a1b01 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Thu, 13 Mar 2025 00:39:09 +0800
Subject: [PATCH 1/4] [Clang][CodeGen][UBSan] Add pre-commit tests. NFC.
---
cla
https://github.com/dtcxzyw edited
https://github.com/llvm/llvm-project/pull/130990
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw ready_for_review
https://github.com/llvm/llvm-project/pull/130990
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/130734
>From b9876822acdca4eaea6496a1d6471e2c0f4ad2e1 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 11 Mar 2025 16:20:08 +0800
Subject: [PATCH 1/9] [Clang][CodeGen] Do not set inbounds flag for struct GEP
wi
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/130734
>From 173ba1595cef80e2affd3ed57feabb2feb0856a7 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 11 Mar 2025 16:20:08 +0800
Subject: [PATCH 01/11] [Clang][CodeGen] Do not set inbounds flag for struct
GEP
@@ -64,21 +64,27 @@ class CGBuilderTy : public CGBuilderBaseTy {
Address createConstGEP2_32(Address Addr, unsigned Idx0, unsigned Idx1,
const llvm::Twine &Name) {
const llvm::DataLayout &DL = BB->getDataLayout();
-llvm::GetElementPtrInst *
https://github.com/dtcxzyw created
https://github.com/llvm/llvm-project/pull/134221
If `CreateConstInBoundsGEP2_32` returns a constant null/gep, the cast to
GetElementPtrInst will fail.
This patch uses two static helpers
`GEPOperator::accumulateConstantOffset/GetElementPtrInst::getIndexedType`
dtcxzyw wrote:
> Usually we'd want to also insert `-fsanitize=pointer-overflow`
> instrumentation in places where we respect `-fwrapv-pointer`. I'm not
> entirely sure whether we want to do this here, as it will probably blow up
> the amount of inserted instrumentation for little benefit...
A
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/130734
>From b9876822acdca4eaea6496a1d6471e2c0f4ad2e1 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 11 Mar 2025 16:20:08 +0800
Subject: [PATCH 1/8] [Clang][CodeGen] Do not set inbounds flag for struct GEP
wi
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/130990
>From 48f8e2591c317f90eff6f1d0a4ecdf27e19a1b01 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Thu, 13 Mar 2025 00:39:09 +0800
Subject: [PATCH 1/3] [Clang][CodeGen][UBSan] Add pre-commit tests. NFC.
---
cla
https://github.com/dtcxzyw created
https://github.com/llvm/llvm-project/pull/134269
This patch turns off inbounds/nuw flags for member accesses when
`-fwrapv-pointer` is set.
Note: There are many calls to `CGBuilderTy::CreateStructGEP`, and most of them
are safe. So I think it is probably over
https://github.com/dtcxzyw edited
https://github.com/llvm/llvm-project/pull/134221
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw closed
https://github.com/llvm/llvm-project/pull/134221
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dtcxzyw wrote:
> > most of them are safe
>
> What's the distinguishing factor here? Do you consider it "safe" to mark
> inbounds if the pointer is immediately dereferenced? Or does the pointer have
> to refer to a known successful allocation? Or something else?
Other calls to `CGBuilderTy::Cr
https://github.com/dtcxzyw edited
https://github.com/llvm/llvm-project/pull/130990
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dtcxzyw wrote:
> > The ubsan handler cannot be eliminated because inaccessiblemem: readwrite
> > indicates that it has externally observable side effects.
>
> That is not how things work. For example:
>
> ```
> $ echo "declare void @g() define void @f() nounwind { call void @g()
> memory(argm
https://github.com/dtcxzyw edited
https://github.com/llvm/llvm-project/pull/130990
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -42,6 +42,11 @@ Potentially Breaking Changes
C/C++ Language Potentially Breaking Changes
---
+- Some old-style offsetof idioms like ``((int)(&(((struct S *)0)->field)))``
are treated
dtcxzyw wrote:
> then describes
https://github.com/dtcxzyw edited
https://github.com/llvm/llvm-project/pull/130990
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dtcxzyw wrote:
> willreturn means we eliminate the call
The ubsan handler cannot be eliminated because `inaccessiblemem: readwrite`
indicates that it has externally observable side effects.
BTW, I just worry that some risky instructions (e.g., divided by zero) may be
moved before the handler
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/130990
>From 48f8e2591c317f90eff6f1d0a4ecdf27e19a1b01 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Thu, 13 Mar 2025 00:39:09 +0800
Subject: [PATCH 1/5] [Clang][CodeGen][UBSan] Add pre-commit tests. NFC.
---
cla
@@ -64,21 +64,27 @@ class CGBuilderTy : public CGBuilderBaseTy {
Address createConstGEP2_32(Address Addr, unsigned Idx0, unsigned Idx1,
const llvm::Twine &Name) {
const llvm::DataLayout &DL = BB->getDataLayout();
-llvm::GetElementPtrInst *
@@ -42,6 +42,11 @@ Potentially Breaking Changes
C/C++ Language Potentially Breaking Changes
---
+- Some old-style offsetof idioms like ``((int)(&(((struct S *)0)->field)))``
are treated
dtcxzyw wrote:
I think it is jus
501 - 572 of 572 matches
Mail list logo
