cor3ntin wrote:
I think this is nice, thanks!
I'd like to wait a few weeks before we land it, I'm afraid these changes (which
do contain some small white spaces-only changes too) might disrupt the release
process as lot of cherry-picking between main and the llvm18 branch are
happening and we
Endilll wrote:
I find `llvm::Bitfield` API with all its explicit setters with explicit storage
parameter clunky compared to language bit-fields. But that's minor. My major
issue with this patch is that `uint64_t Storage;` is as opaque for debuggers as
it gets. It would take so much work to cor
https://github.com/jonathonpenix created
https://github.com/llvm/llvm-project/pull/79372
The GlobalMerge pass was enabled for RISC-V in [1] and left off by default. My
understanding from [2] is that the concern around enabling the pass by default
stemmed primarily from GlobalMerge preventing G
https://github.com/spaits updated
https://github.com/llvm/llvm-project/pull/79371
From d4ca5c2fcb87f424be23efc4513df491403c3811 Mon Sep 17 00:00:00 2001
From: Gabor Spaits
Date: Wed, 24 Jan 2024 21:21:26 +0100
Subject: [PATCH 1/2] [Sema]Substitue template parameter packs when deduced
from func
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Jonathon Penix (jonathonpenix)
Changes
The GlobalMerge pass was enabled for RISC-V in [1] and left off by default. My
understanding from [2] is that the concern around enabling the pass by default
stemmed primarily from GlobalMerge preven
https://github.com/AtariDreams updated
https://github.com/llvm/llvm-project/pull/79191
>From 65194f1090ccca096eba280b1ddb7d9374d47a12 Mon Sep 17 00:00:00 2001
From: Rose <83477269+ataridre...@users.noreply.github.com>
Date: Tue, 23 Jan 2024 13:59:05 -0500
Subject: [PATCH] [Objective-C] Defer to
https://github.com/AtariDreams edited
https://github.com/llvm/llvm-project/pull/79191
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AtariDreams edited
https://github.com/llvm/llvm-project/pull/79191
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/79373
Summary:
We support `--target=nvptx64-nvidia-cuda` as a way to target the NVPTX
architecture from standard CPU. This patch simply uses the existing
support for handling `--offload-arch=native` to also apply to the
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: Joseph Huber (jhuber6)
Changes
Summary:
We support `--target=nvptx64-nvidia-cuda` as a way to target the NVPTX
architecture from standard CPU. This patch simply uses the existing
support for handling `--offload-arch=native` to also a
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Joseph Huber (jhuber6)
Changes
Summary:
We support `--target=nvptx64-nvidia-cuda` as a way to target the NVPTX
architecture from standard CPU. This patch simply uses the existing
support for handling `--offload-arch=native` to also apply to
https://github.com/AtariDreams updated
https://github.com/llvm/llvm-project/pull/79191
>From c34406a8fc9ecf0029fdf96883a4dce4e74e647a Mon Sep 17 00:00:00 2001
From: Rose <83477269+ataridre...@users.noreply.github.com>
Date: Tue, 23 Jan 2024 13:59:05 -0500
Subject: [PATCH] [ObjC] Defer to the LLV
jonathonpenix wrote:
Also few misc. notes:
1. Please let me know if this needs to be discussed elsewhere and I'd be happy
to do so! I was originally thinking to ping https://reviews.llvm.org/D130481 /
https://reviews.llvm.org/D129178 to check if this made sense, but they are
read-only now IIU
Author: erichkeane
Date: 2024-01-24T13:43:32-08:00
New Revision: 62a384ca66993b449c5accedbebf7af191fbe52c
URL:
https://github.com/llvm/llvm-project/commit/62a384ca66993b449c5accedbebf7af191fbe52c
DIFF:
https://github.com/llvm/llvm-project/commit/62a384ca66993b449c5accedbebf7af191fbe52c.diff
LO
@@ -2129,6 +2129,16 @@ void Clang::AddRISCVTargetArgs(const ArgList &Args,
<< A->getSpelling() << Val;
}
}
+
+ // Forward the -mglobal-merge option for explicit control over the pass.
+ if (Arg *A = Args.getLastArg(options::OPT_mglobal_merge,
+
gulfemsavrun wrote:
We started seeing a test failure in our Clang toolchain builders for Mac:
```
FAIL: Clang :: Driver/unsupported-option-gpu.c (10452 of 19269)
TEST 'Clang :: Driver/unsupported-option-gpu.c' FAILED
Exit Code: 1
Command Output (stderr)
jhuber6 wrote:
Maybe need to specify `--target=x86_64-unknown-linux-gnu` in the test?
https://github.com/llvm/llvm-project/pull/79222
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -21471,6 +21471,53 @@ bool isHalvingTruncateOfLegalScalableType(EVT SrcVT,
EVT DstVT) {
(SrcVT == MVT::nxv2i64 && DstVT == MVT::nxv2i32);
}
+// Combine store (trunc X to <3 x i8>) to sequence of ST1.b.
+static SDValue combineI8TruncStore(StoreSDNode *ST, Selection
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/73511
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
What's the expected interaction here with LTO? Modifying TargetOptions has no
effect if we're generating a bitcode file.
https://github.com/llvm/llvm-project/pull/79256
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
https://github.com/Bryce-MW updated
https://github.com/llvm/llvm-project/pull/77964
>From d4c312b9dbf447d0a53dda0e6cdc482bd908430b Mon Sep 17 00:00:00 2001
From: Bryce Wilson
Date: Fri, 12 Jan 2024 16:01:32 -0600
Subject: [PATCH 01/13] [X86] Use RORX over SHR imm
---
llvm/lib/Target/X86/X86In
@@ -2422,59 +2342,226 @@ void SampleProfileMatcher::runStaleProfileMatching(
}
}
-void SampleProfileMatcher::runOnFunction(const Function &F) {
- // We need to use flattened function samples for matching.
- // Unlike IR, which includes all callsites from the source code, t
@@ -2422,59 +2342,226 @@ void SampleProfileMatcher::runStaleProfileMatching(
}
}
-void SampleProfileMatcher::runOnFunction(const Function &F) {
- // We need to use flattened function samples for matching.
- // Unlike IR, which includes all callsites from the source code, t
@@ -433,12 +433,19 @@ using CandidateQueue =
PriorityQueue,
CandidateComparer>;
+using IRAnchorMap = std::map;
+using ProfileAnchorMap = std::map>;
WenleiHe wrote:
Also move this inside class `SampleProfileMatcher` since these types are
@@ -2422,59 +2342,226 @@ void SampleProfileMatcher::runStaleProfileMatching(
}
}
-void SampleProfileMatcher::runOnFunction(const Function &F) {
- // We need to use flattened function samples for matching.
- // Unlike IR, which includes all callsites from the source code, t
@@ -2422,59 +2342,226 @@ void SampleProfileMatcher::runStaleProfileMatching(
}
}
-void SampleProfileMatcher::runOnFunction(const Function &F) {
- // We need to use flattened function samples for matching.
- // Unlike IR, which includes all callsites from the source code, t
@@ -2422,59 +2342,226 @@ void SampleProfileMatcher::runStaleProfileMatching(
}
}
-void SampleProfileMatcher::runOnFunction(const Function &F) {
- // We need to use flattened function samples for matching.
- // Unlike IR, which includes all callsites from the source code, t
@@ -2190,7 +2196,8 @@ void SampleProfileMatcher::findIRAnchors(
}
}
-void SampleProfileMatcher::countMismatchedSamples(const FunctionSamples &FS) {
+void SampleProfileMatcher::countMismatchedHashSamples(
WenleiHe wrote:
Why is the renaming? I can find the n
@@ -2487,29 +2574,42 @@ void SampleProfileMatcher::runOnModule() {
errs() << "(" << NumMismatchedCallsites << "/" << TotalProfiledCallsites
<< ")"
<< " of callsites' profile are invalid and "
- << "(" << MismatchedCallsiteSamples << "/" << To
@@ -2422,59 +2342,226 @@ void SampleProfileMatcher::runStaleProfileMatching(
}
}
-void SampleProfileMatcher::runOnFunction(const Function &F) {
- // We need to use flattened function samples for matching.
- // Unlike IR, which includes all callsites from the source code, t
@@ -2422,59 +2342,226 @@ void SampleProfileMatcher::runStaleProfileMatching(
}
}
-void SampleProfileMatcher::runOnFunction(const Function &F) {
- // We need to use flattened function samples for matching.
- // Unlike IR, which includes all callsites from the source code, t
@@ -433,12 +433,19 @@ using CandidateQueue =
PriorityQueue,
CandidateComparer>;
+using IRAnchorMap = std::map;
+using ProfileAnchorMap = std::map>;
WenleiHe wrote:
As standalone types, add a comment explaining the key/value of the maps?
WenleiHe wrote:
> Compute and report the staleness metrics after stale profile matching
Staleness is characteristic associated with a given profile and IR. There is no
post-matching staleness. We can say the success rate of matching or renaming
unmatched callsites/samples, but we don't want t
efriedma-quic wrote:
For the question about querying module flags, we do that in a few different
places in codegen; grep for "getModuleFlag". Not sure if there's anything
specifically in TargetLowering.
https://github.com/llvm/llvm-project/pull/76558
__
https://github.com/llvm-beanz created
https://github.com/llvm/llvm-project/pull/79382
In HLSL function parameters are passed by value, including array parameters.
This change introduces a new AST node to represent array temporary expressions.
They behave as lvalues to temporary arrays and deca
llvmbot wrote:
@llvm/pr-subscribers-clang-static-analyzer-1
@llvm/pr-subscribers-clang-modules
Author: Chris B (llvm-beanz)
Changes
In HLSL function parameters are passed by value, including array parameters.
This change introduces a new AST node to represent array temporary expressions.
llvmbot wrote:
@llvm/pr-subscribers-hlsl
Author: Chris B (llvm-beanz)
Changes
In HLSL function parameters are passed by value, including array parameters.
This change introduces a new AST node to represent array temporary expressions.
They behave as lvalues to temporary arrays and decay
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
Author: Chris B (llvm-beanz)
Changes
In HLSL function parameters are passed by value, including array parameters.
This change introduces a new AST node to represent array temporary expressions.
They behave as lvalues to temporary arrays a
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 6e4930c67508a90bdfd756f6e45417b5253cd741
d01d3dd8de6e955ad19a0ad8399547dbc59f7a52 --
https://github.com/Bryce-MW updated
https://github.com/llvm/llvm-project/pull/77964
>From d4c312b9dbf447d0a53dda0e6cdc482bd908430b Mon Sep 17 00:00:00 2001
From: Bryce Wilson
Date: Fri, 12 Jan 2024 16:01:32 -0600
Subject: [PATCH 01/14] [X86] Use RORX over SHR imm
---
llvm/lib/Target/X86/X86In
https://github.com/ayalz edited https://github.com/llvm/llvm-project/pull/78113
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -230,7 +230,11 @@ Type *VPTypeAnalysis::inferScalarType(const VPValue *V) {
return V->getUnderlyingValue()->getType();
})
.Case(
- [](const VPWidenCastRecipe *R) { return R->getResultType(); });
+ [](const VPWidenCast
https://github.com/ayalz commented:
Nice reuse and clean-up! Title and commit message deserve an update.
https://github.com/llvm/llvm-project/pull/78113
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
@@ -1469,6 +1461,52 @@ void VPReplicateRecipe::print(raw_ostream &O, const
Twine &Indent,
}
#endif
+static bool isUniformAcrossVFsAndUFs(VPScalarCastRecipe *C) {
+ return C->isDefinedOutsideVectorRegions() ||
+ isa(C->getOperand(0)) ||
+ isa(C->getOperand(0))
@@ -1469,6 +1461,52 @@ void VPReplicateRecipe::print(raw_ostream &O, const
Twine &Indent,
}
#endif
+static bool isUniformAcrossVFsAndUFs(VPScalarCastRecipe *C) {
ayalz wrote:
Worth documenting, potentially leaving behind a note that uniformity should
essent
@@ -498,10 +498,34 @@ static VPValue *createScalarIVSteps(VPlan &Plan, const
InductionDescriptor &ID,
VPCanonicalIVPHIRecipe *CanonicalIV = Plan.getCanonicalIV();
Type *TruncTy = TruncI ? TruncI->getType() : IVTy;
VPValue *BaseIV = CanonicalIV;
ayalz wro
https://github.com/mrexodia created
https://github.com/llvm/llvm-project/pull/79390
This was previously marked as `FIXME` in `LTOBackend.cpp`.
List of changes:
- Removed the unused `lto::Config.MllvmArgs` field
- Add a new `lto::Config.EmbedCmdArgs` field (`\0`-separated list, since that's
how
github-actions[bot] wrote:
Thank you for submitting a Pull Request (PR) to the LLVM Project!
This PR will be automatically labeled and the relevant teams will be
notified.
If you wish to, you can add reviewers by using the "Reviewers" section on this
page.
If this is not working for you, it i
https://github.com/mrexodia edited
https://github.com/llvm/llvm-project/pull/79390
___
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-codegen
@llvm/pr-subscribers-lld
Author: Duncan Ogilvie (mrexodia)
Changes
This was previously marked as `FIXME` in `LTOBackend.cpp`.
List of changes:
- Removed the unused `lto::Config.MllvmArgs` field (this field was only
assigned, never actuall
@@ -259,10 +259,13 @@ class InputFunction : public InputChunk {
file->codeSection->Content.slice(inputSectionOffset, function->Size);
debugName = function->DebugName;
comdat = function->Comdat;
+assert(s.Kind != WasmSignature::Placeholder);
@@ -2422,59 +2342,226 @@ void SampleProfileMatcher::runStaleProfileMatching(
}
}
-void SampleProfileMatcher::runOnFunction(const Function &F) {
- // We need to use flattened function samples for matching.
- // Unlike IR, which includes all callsites from the source code, t
@@ -2422,59 +2342,226 @@ void SampleProfileMatcher::runStaleProfileMatching(
}
}
-void SampleProfileMatcher::runOnFunction(const Function &F) {
- // We need to use flattened function samples for matching.
- // Unlike IR, which includes all callsites from the source code, t
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 2e81ac25b4e2bfdc71aac19a911525a7f35680be
5a7c330982873c9198ef8c6f90d10f3ccb9ac5d9 --
@@ -2422,59 +2342,226 @@ void SampleProfileMatcher::runStaleProfileMatching(
}
}
-void SampleProfileMatcher::runOnFunction(const Function &F) {
- // We need to use flattened function samples for matching.
- // Unlike IR, which includes all callsites from the source code, t
https://github.com/mrexodia updated
https://github.com/llvm/llvm-project/pull/79390
>From d60c2ad5bc88d6b64d7b3d6b179e303e3eeb936c Mon Sep 17 00:00:00 2001
From: Duncan Ogilvie
Date: Thu, 25 Jan 2024 00:08:49 +0100
Subject: [PATCH] Embed the command line arguments during LTO
---
clang/lib/Cod
wlei-llvm wrote:
Thanks so much for the feedback. Answering some high-level questions, will
address others later.
https://github.com/llvm/llvm-project/pull/79090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
https://github.com/wlei-llvm edited
https://github.com/llvm/llvm-project/pull/79090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -40,6 +41,7 @@ using namespace llvm;
namespace lld::wasm {
static std::unique_ptr createLTO() {
lto::Config c;
+ c.EmbedCmdArgs = commonContext().cmdArgs;
sbc100 wrote:
It looks like `commonContext()` is not actually used elsewhere in lld, and this
shou
@@ -40,6 +41,7 @@ using namespace llvm;
namespace lld::wasm {
static std::unique_ptr createLTO() {
lto::Config c;
+ c.EmbedCmdArgs = commonContext().cmdArgs;
mrexodia wrote:
Thanks for the comment! I don't think it makes a difference, except that
`context(
https://github.com/jonathonpenix updated
https://github.com/llvm/llvm-project/pull/79372
>From 37cf78919afbfb6eb4e1bc36a3d8fbb678ffd821 Mon Sep 17 00:00:00 2001
From: Jonathon Penix
Date: Tue, 23 Jan 2024 15:10:50 -0800
Subject: [PATCH 1/2] [clang][Driver][RISCV] Honor -m[no-]global-merge for
@@ -3569,6 +3569,7 @@ bool Expr::HasSideEffects(const ASTContext &Ctx,
case ConceptSpecializationExprClass:
case RequiresExprClass:
case SYCLUniqueStableNameExprClass:
+ case HLSLArrayTemporaryExprClass:
efriedma-quic wrote:
This looks wrong; I think yo
@@ -10524,6 +10524,11 @@ Sema::PerformCopyInitialization(const
InitializedEntity &Entity,
Expr *InitE = Init.get();
assert(InitE && "No initialization expression?");
+ if (LangOpts.HLSL)
+if (auto AdjTy = dyn_cast(Entity.getType()))
+ if (AdjTy->getOriginalType(
@@ -40,6 +41,7 @@ using namespace llvm;
namespace lld::wasm {
static std::unique_ptr createLTO() {
lto::Config c;
+ c.EmbedCmdArgs = commonContext().cmdArgs;
sbc100 wrote:
How about adding a helper like the existing ones `CommonLinkerContext.h`:
```
inline
@@ -40,6 +41,7 @@ using namespace llvm;
namespace lld::wasm {
static std::unique_ptr createLTO() {
lto::Config c;
+ c.EmbedCmdArgs = commonContext().cmdArgs;
sbc100 wrote:
(I'm not sure why `context()` needs to take a template param, and it looks like
its
https://github.com/mrexodia updated
https://github.com/llvm/llvm-project/pull/79390
>From 9ca7af3aa2401daeecc50772ebbd58f14d2fa3e9 Mon Sep 17 00:00:00 2001
From: Duncan Ogilvie
Date: Thu, 25 Jan 2024 00:08:49 +0100
Subject: [PATCH] Embed the command line arguments during LTO
---
clang/lib/Cod
https://github.com/mrexodia edited
https://github.com/llvm/llvm-project/pull/79390
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2129,6 +2129,16 @@ void Clang::AddRISCVTargetArgs(const ArgList &Args,
<< A->getSpelling() << Val;
}
}
+
+ // Forward the -mglobal-merge option for explicit control over the pass.
+ if (Arg *A = Args.getLastArg(options::OPT_mglobal_merge,
+
bwendling wrote:
> I'd like to wait a few weeks before we land it, I'm afraid these changes
> (which do contain some small white spaces-only changes too) might disrupt the
> release process as lot of cherry-picking between main and the llvm18 branch
> are happening and we should minimize the o
@@ -40,6 +41,7 @@ using namespace llvm;
namespace lld::wasm {
static std::unique_ptr createLTO() {
lto::Config c;
+ c.EmbedCmdArgs = commonContext().cmdArgs;
mrexodia wrote:
For most drivers (except ELF) I can access the specialized context directly.
But w
@@ -2110,6 +2214,29 @@ def : Pat<(seteq Int1Regs:$a, Int1Regs:$b),
def : Pat<(setueq Int1Regs:$a, Int1Regs:$b),
(NOT1 (XORb1rr Int1Regs:$a, Int1Regs:$b))>;
+// comparisons of i8 extracted with BFE as i32
+def: Pat<(setgt (sext_inreg (trunc Int32Regs:$a), i8), (sext_i
bwendling wrote:
It shouldn't be necessary to analyze `uint64_t Storage` directly through a
debugger. It's handled via the `Bitfield` getters and setters. Is that not
sufficient for debugging purposes?
My sinister reason for wanting to do this is that many of the
`const_cast(...)` constructs
https://github.com/Benjins updated
https://github.com/llvm/llvm-project/pull/77390
>From 43db89c2bc2a42ff1e88deb99b7214e3e37e317c Mon Sep 17 00:00:00 2001
From: Benji Smith <6193112+benj...@users.noreply.github.com>
Date: Sun, 7 Jan 2024 20:16:25 -0500
Subject: [PATCH 1/2] Refactor llvm-c-test t
https://github.com/jkorous-apple created
https://github.com/llvm/llvm-project/pull/79392
We are not interested in nonpointers being added to.
>From afda86d399dbb277d2fa3b0134a9724c206919fb Mon Sep 17 00:00:00 2001
From: Jan Korous
Date: Wed, 24 Jan 2024 15:02:55 -0800
Subject: [PATCH] [-Wunsaf
llvmbot wrote:
@llvm/pr-subscribers-clang-analysis
Author: None (jkorous-apple)
Changes
We are not interested in nonpointers being added to.
---
Full diff: https://github.com/llvm/llvm-project/pull/79392.diff
1 Files Affected:
- (modified) clang/lib/Analysis/UnsafeBufferUsage.cpp (+6-1
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff bb6a4850553dd4140a5bd63187ec1b14d0b731f9
afda86d399dbb277d2fa3b0134a9724c206919fb --
https://github.com/jkorous-apple updated
https://github.com/llvm/llvm-project/pull/79392
>From dcc2b0c07681b57dbd5a82ce83f5166bb3b9ee09 Mon Sep 17 00:00:00 2001
From: Jan Korous
Date: Wed, 24 Jan 2024 15:02:55 -0800
Subject: [PATCH] [-Wunsafe-buffer-usage] Fix AST matcher of UUCAddAssignGadget
@@ -2561,6 +2567,70 @@ bool SIMemoryLegalizer::expandAtomicCmpxchgOrRmw(const
SIMemOpInfo &MOI,
return Changed;
}
+bool SIMemoryLegalizer::GFX9InsertWaitcntForPreciseMem(MachineFunction &MF) {
+ const GCNSubtarget &ST = MF.getSubtarget();
+ const SIInstrInfo *TII = ST.get
cjacek wrote:
Thanks!
FWIW, I tested and reviewed the new version and it works and looks good to me.
https://github.com/llvm/llvm-project/pull/79067
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
@@ -471,6 +471,66 @@ ProfileGenerator::getTopLevelFunctionProfile(FunctionId
FuncName) {
return ProfileMap.Create(Context);
}
+// Use a heuristic to determine probe order by checking callsite insertion
+// position relative to the BB probes. Sort all the BB probes is in a l
@@ -471,6 +471,66 @@ ProfileGenerator::getTopLevelFunctionProfile(FunctionId
FuncName) {
return ProfileMap.Create(Context);
}
+// Use a heuristic to determine probe order by checking callsite insertion
+// position relative to the BB probes. Sort all the BB probes is in a l
@@ -2112,6 +2112,14 @@ bool SampleProfileLoader::doInitialization(Module &M,
DS_Warning));
return false;
}
+
+if (!FunctionSamples::ProfileIsMixedProbeOrder) {
+ const char *Msg =
+ "Pseudo-probe-based p
@@ -471,6 +471,66 @@ ProfileGenerator::getTopLevelFunctionProfile(FunctionId
FuncName) {
return ProfileMap.Create(Context);
}
+// Use a heuristic to determine probe order by checking callsite insertion
+// position relative to the BB probes. Sort all the BB probes is in a l
darkfeline wrote:
@kirillbobyrev I have gotten no responses from anyone that uses
`clang-rename.el` or cares about its deletion, take that as you will.
https://github.com/llvm/llvm-project/pull/76110
___
cfe-commits mailing list
cfe-commits@lists.llvm
MaskRay wrote:
> What's the expected interaction here with LTO? Modifying TargetOptions has no
> effect if we're generating a bitcode file.
Thanks for reminding me this. There seems no motivation to mix trad/desc, so I
think we can do it the `-ffunction-sections`/`-femulated-tls` way by passin
bwendling wrote:
> > maybe we could add the subtype as part of the llvm.objectsize intrinsic and
> > use that instead of grappling with the whole object's type
>
> I'm not sure I follow; if you know the object's type, doesn't that mean you
> also know its size?
Not necessarily. If you have so
@@ -40,6 +41,7 @@ using namespace llvm;
namespace lld::wasm {
static std::unique_ptr createLTO() {
lto::Config c;
+ c.EmbedCmdArgs = commonContext().cmdArgs;
sbc100 wrote:
I think it might be the other way around. It looks like only COFF currently
support
@@ -259,10 +259,13 @@ class InputFunction : public InputChunk {
file->codeSection->Content.slice(inputSectionOffset, function->Size);
debugName = function->DebugName;
comdat = function->Comdat;
+assert(s.Kind != WasmSignature::Placeholder);
@@ -259,10 +259,13 @@ class InputFunction : public InputChunk {
file->codeSection->Content.slice(inputSectionOffset, function->Size);
debugName = function->DebugName;
comdat = function->Comdat;
+assert(s.Kind != WasmSignature::Placeholder);
anlunx wrote:
Also need to be updated:
https://github.com/llvm/llvm-project/blob/bb6a4850553dd4140a5bd63187ec1b14d0b731f9/llvm/lib/Target/AMDGPU/SMInstructions.td#L14
https://github.com/llvm/llvm-project/pull/77795
___
cfe-commits mailing list
cfe-c
sott0n wrote:
@matthias-springer Could you land it? I don't have commit access.
https://github.com/llvm/llvm-project/pull/79098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nathanchance wrote:
For what it's worth, this test appears to fail when
`LLVM_DEFAULT_TARGET_TRIPLE` is changed (my script sets it to the output of my
Linux distribution's `clang -print-target-triple`)
```
error: PCH file was compiled for the target 'x86_64-pc-linux-gnu' but the
current trans
Author: Ben Shi
Date: 2024-01-25T09:23:40+08:00
New Revision: b7f986d987edd50f8b16ae90d38358b01f0272ac
URL:
https://github.com/llvm/llvm-project/commit/b7f986d987edd50f8b16ae90d38358b01f0272ac
DIFF:
https://github.com/llvm/llvm-project/commit/b7f986d987edd50f8b16ae90d38358b01f0272ac.diff
LOG:
https://github.com/benshi001 closed
https://github.com/llvm/llvm-project/pull/78930
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> ```c
> struct x {
> int a;
> char foo[2][40];
> int b;
> int c;
> };
>
> size_t f(struct x *p, int idx) {
> return __builtin_dynamic_object_size(&p->foo[idx], 1);
> }
> ```
If I'm following correctly, the return here is 0, 40, or 80, depending on the
https://github.com/dschuff updated
https://github.com/llvm/llvm-project/pull/79235
>From 976c98f631e5ed48bb18accbe59c9babd354a924 Mon Sep 17 00:00:00 2001
From: Derek Schuff
Date: Wed, 3 Jan 2024 09:06:37 -0800
Subject: [PATCH 01/12] parse types
---
llvm/include/llvm/BinaryFormat/Wasm.h | 8
@@ -259,10 +259,13 @@ class InputFunction : public InputChunk {
file->codeSection->Content.slice(inputSectionOffset, function->Size);
debugName = function->DebugName;
comdat = function->Comdat;
+assert(s.Kind != WasmSignature::Placeholder);
@@ -10524,6 +10524,11 @@ Sema::PerformCopyInitialization(const
InitializedEntity &Entity,
Expr *InitE = Init.get();
assert(InitE && "No initialization expression?");
+ if (LangOpts.HLSL)
+if (auto AdjTy = dyn_cast(Entity.getType()))
+ if (AdjTy->getOriginalType(
Artem-B wrote:
This option may not as well as one would hope.
Problem #1 is that it will drastically slow down compilation for some users.
NVIDIA GPU drivers are loaded on demand, and the process takes a while
(O(second), depending on the kind and number of GPUs). If you build on a
headless m
jhuber6 wrote:
Some interesting points, I'll try to clarify some things.
> This option may not as well as one would hope.
>
> Problem #1 is that it will drastically slow down compilation for some users.
> NVIDIA GPU drivers are loaded on demand, and the process takes a while
> (O(second), dep
301 - 400 of 506 matches
Mail list logo
