https://github.com/nikic milestoned
https://github.com/llvm/llvm-project/pull/141957
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/142039
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/142031
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -7170,16 +7165,31 @@ bool X86TTIImpl::isProfitableToSinkOperands(Instruction
*I,
II->getIntrinsicID() == Intrinsic::fshr)
ShiftAmountOpNum = 2;
}
-
if (ShiftAmountOpNum == -1)
return false;
+ auto *ShiftAmount = &I->getOperandUse(ShiftAmountOpNum);
nikic wrote:
@pcc I think using fsh should at least help to get a ror instead of the
shr+shl+or.
Actually getting the value duplicated+sunk into each block is typically done in
CGP, which has a bunch of related transforms. The most generic is probably
tryToSinkFreeOperands driven by TTI.isPro
@@ -33,8 +34,11 @@ PreservedAnalyses EmbedBitcodePass::run(Module &M,
ModuleAnalysisManager &AM) {
std::string Data;
raw_string_ostream OS(Data);
+ // Clone the module with with Thin LTO, since ThinLTOBitcodeWriterPass
changes
nikic wrote:
```suggestio
https://github.com/nikic approved this pull request.
Okay, let's go with this for now.
Compile-time impact of cloning the module is about 0.2% when building clang
with fat LTO:
https://llvm-compile-time-tracker.com/compare.php?from=11a01e851a06188ae946ace1140f866d7a667221&to=46e037d763e7997a83
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/13
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic milestoned
https://github.com/llvm/llvm-project/pull/141461
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic milestoned
https://github.com/llvm/llvm-project/pull/140060
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic milestoned
https://github.com/llvm/llvm-project/pull/140902
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic commented:
I'm not super clear on what it is you're trying to fix here.
Probably LowerTypeTests should be directly emitting a fshl/fshr instead of a
bit shift sequence to make matching to rotate more reliable. Would that help
you or not?
https://github.com/llvm/llvm-p
https://github.com/nikic requested changes to this pull request.
If you're using stacked pull requests, please link the other PRs from the
stack. It's impossible to understand the context otherwise. Based on just the
changes in this PR:
* The EarlyCSE and GVN changes do not make sense to me.
nikic wrote:
The LLVM 19 release is no longer supported. You'll have to apply this as a
local patch if you want to build and old LLVM 19 with a new libstdc++.
https://github.com/llvm/llvm-project/pull/138550
___
llvm-branch-commits mailing list
llvm-b
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/138550
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
nikic wrote:
@ilovepi Does it also work on the release branch? I'd mainly see the clone
module approach as something easily backportable for the release branch, but I
assume for main we'll want a different solution?
https://github.com/llvm/llvm-project/pull/13
_
https://github.com/nikic commented:
Didn't we switch away from cloning because it breaks blockaddress somehow?
https://github.com/llvm/llvm-project/pull/13
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.o
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/138676
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
nikic wrote:
I think this may have been noise. I reran this and there are no differences
over the significance threshold:
https://llvm-compile-time-tracker.com/compare.php?from=6c1bb48cc45396894597c8cb897c31205d1bdeb6&to=1837fe71fcfb4363fd2b66cdb9ff6a82b3f380fb&stat=instructions:u
https://gith
nikic wrote:
Closing this as https://github.com/llvm/llvm-project/pull/127751 has landed.
https://github.com/llvm/llvm-project/pull/127496
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/127496
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic milestoned
https://github.com/llvm/llvm-project/pull/139345
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -180,6 +180,10 @@ llvm::getKnowledgeForValue(const Value *V,
}
return RetainedKnowledge::none();
}
+
+ if (!V->hasUseList())
+return RetainedKnowledge::none();
nikic wrote:
As a followup, we should completely remove the non-AC code in this fu
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/138961
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/138737
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/138729
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/138638
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic commented:
Peculiarly, this has a negative effect on stage1 builds using gcc and a
positive effect on stage2 builds using clang:
https://llvm-compile-time-tracker.com/compare.php?from=420eca364b07bad78dc0a5d21da5980493798df0&to=00be79cbc7dea09fcd8a57ea51b3e800564fd986&s
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134794
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -73,28 +73,16 @@ static void rewriteFuncWithReturnType(Function &OldF, Value
*NewRetValue) {
}
}
- // Now prune any CFG edges we have to deal with.
- //
- // Use KeepOneInputPHIs in case the instruction we are using for the return
is
- // that phi.
- // TODO: C
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/134794
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -5096,6 +5097,23 @@ void Verifier::visitCallsiteMetadata(Instruction &I,
MDNode *MD) {
visitCallStackMetadata(MD);
}
+void Verifier::visitCalleeTypeMetadata(Instruction &I, MDNode *MD) {
+ Check(isa(I), "!callee_type metadata should only exist on calls",
+&I);
+
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/138142
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
nikic wrote:
Looks like something went wrong here?
https://github.com/llvm/llvm-project/pull/137702
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
nikic wrote:
> > I don't think there is a need to backport FMF propagation fixes.
>
> Is there a policy to judge whether or not to backport a miscompilation bug
> fix? Actually, it is unlikely to trigger this bug in real-world projects. But
> this fix is simple and safe to be backported.
Ther
https://github.com/nikic commented:
I don't think there is a need to backport FMF propagation fixes.
https://github.com/llvm/llvm-project/pull/137605
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/137606
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/137314
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -518,17 +509,8 @@ class Value {
/// This method should only be used by the Use class.
void addUse(Use &U) {
-if (hasUseList())
- U.addToList(Uses.List);
-else
- U.addToList(Uses.Count);
- }
-
- void removeUse(Use &U) {
-if (hasUseList())
- U
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/137314
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -85,10 +84,8 @@ class Use {
Use **Prev = nullptr;
User *Parent = nullptr;
- inline void addToList(unsigned &Count);
- inline void addToList(Use *&List);
- inline void removeFromList(unsigned &Count);
- inline void removeFromList(Use *&List);
+ inline void addToList
nikic wrote:
Compile-time for both PRs taken together looks good:
https://llvm-compile-time-tracker.com/compare.php?from=12a31658ea36cda74157c6b4e6b6c031e39a19c0&to=d769267079777e4fa4cf41188bfe2aab1b9361f1&stat=instructions%3Au
(For reference, this is for the first PR only:
https://llvm-compil
https://github.com/nikic commented:
The general approach here makes sense to me.
For reference, this is the diff for both PRs together, which is a bit clearer
as the second undoes half of the first:
https://github.com/llvm/llvm-project/compare/main...users/arsenm/ir/remove-constantdata-referen
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/137314
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic commented:
Looks like there are some polly assertion failures.
https://github.com/llvm/llvm-project/pull/137314
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
nikic wrote:
@shiltian I'm not entirely sure what you're asking here. As @arsenm said, the
alloca address space in the data layout is merely a hint on the address space
to use when materializing allocas "out of thin air". There are targets that use
multiple alloca address spaces, this just spe
https://github.com/nikic milestoned
https://github.com/llvm/llvm-project/pull/136589
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/136355
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/136356
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic milestoned
https://github.com/llvm/llvm-project/pull/136034
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic milestoned
https://github.com/llvm/llvm-project/pull/135666
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/135543
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic milestoned
https://github.com/llvm/llvm-project/pull/135615
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic created
https://github.com/llvm/llvm-project/pull/135615
Backport of 716b02d8c575afde7af1af13df145019659abca2, with conflicts in the
test resolved.
>From e385f5c5b9bd32f89754e8088c29f42a761f2880 Mon Sep 17 00:00:00 2001
From: Dominik Adamski
Date: Thu, 10 Apr 2025 12:
nikic wrote:
> @nikic what do you mean by ABI change in this case? It doesn't change ABI of
> generated code, moreover it doesn't even change PCM serialized format because
> it is in memory only filed and attribute.
It changes the ABI of libclang-cpp, by changing the layout of an exported type
@@ -1392,6 +1392,10 @@ class ASTReader
llvm::DenseMap DefinitionSource;
+ /// Friend functions that were defined but might have had their bodies
+ /// removed.
+ llvm::DenseSet ThisDeclarationWasADefinitionSet;
nikic wrote:
This is an ABI break.
https:
https://github.com/nikic requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/134232
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit
https://github.com/nikic milestoned
https://github.com/llvm/llvm-project/pull/134232
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic requested changes to this pull request.
Breaks LoopUtils.h ABI in obvious ways and FMF.h ABI in less obvious ways.
Can this be fixed in a more minimal way than backporting 18 commits that
include a lot of refactorings?
https://github.com/llvm/llvm-project/pull/135231
_
https://github.com/nikic milestoned
https://github.com/llvm/llvm-project/pull/135231
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic milestoned
https://github.com/llvm/llvm-project/pull/135549
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic commented:
Compile-time:
https://llvm-compile-time-tracker.com/compare.php?from=09588e93bbe486ce782de9fba604f5cd184ec446&to=54260021fd4ffa41b5f20994af7b34653b4d4d42&stat=instructions%3Au
It's possible that the wall-time picture may be different due to slightly less
mem
@@ -889,10 +919,50 @@ inline raw_ostream &operator<<(raw_ostream &OS, const
Value &V) {
return OS;
}
+inline Use::~Use() {
+ if (Val)
+Val->removeUse(*this);
+}
+
+void Use::addToList(unsigned &Count) {
+ assert(isa(Val) && "Only ConstantData is ref-counted");
+ ++Co
@@ -8857,6 +8857,8 @@ bool LLParser::parseMDNodeVector(SmallVectorImpl &Elts) {
//===--===//
bool LLParser::sortUseListOrder(Value *V, ArrayRef Indexes,
SMLoc Loc) {
+ if (isa(
@@ -437,7 +437,8 @@ static bool LinearizeExprTree(Instruction *I,
for (unsigned OpIdx = 0; OpIdx < I->getNumOperands(); ++OpIdx) { // Visit
operands.
Value *Op = I->getOperand(OpIdx);
LLVM_DEBUG(dbgs() << "OPERAND: " << *Op << " (" << Weight << ")\n");
- a
https://github.com/nikic approved this pull request.
I think this is okay to backport. We should do this properly on main, but this
is probably the more conservative fix.
https://github.com/llvm/llvm-project/pull/130580
___
llvm-branch-commits mailing
@@ -3086,13 +3086,47 @@ Instruction
*InstCombinerImpl::visitGetElementPtrInst(GetElementPtrInst &GEP) {
if (GEPType->isVectorTy())
return nullptr;
+ if (!GEP.isInBounds()) {
+unsigned IdxWidth =
+DL.getIndexSizeInBits(PtrOp->getType()->getPointerAddressSpac
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/135155
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -3086,13 +3086,47 @@ Instruction
*InstCombinerImpl::visitGetElementPtrInst(GetElementPtrInst &GEP) {
if (GEPType->isVectorTy())
return nullptr;
+ if (!GEP.isInBounds()) {
+unsigned IdxWidth =
+DL.getIndexSizeInBits(PtrOp->getType()->getPointerAddressSpac
https://github.com/nikic approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/135155
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-comm
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/135291
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -122,25 +122,23 @@ define ptr @gep_inbounds_nuwaddlike(ptr %ptr, i64 %a, i64
%b) {
ret ptr %gep
}
-; FIXME: Preserve "inbounds nuw".
define ptr @gep_inbounds_add_nuw(ptr %ptr, i64 %a, i64 %b) {
; CHECK-LABEL: define ptr @gep_inbounds_add_nuw(
; CHECK-SAME: ptr [[PTR:%
@@ -3086,13 +3086,51 @@ Instruction
*InstCombinerImpl::visitGetElementPtrInst(GetElementPtrInst &GEP) {
if (GEPType->isVectorTy())
return nullptr;
+ if (!GEP.isInBounds()) {
+unsigned IdxWidth =
+DL.getIndexSizeInBits(PtrOp->getType()->getPointerAddressSpac
@@ -3086,13 +3086,51 @@ Instruction
*InstCombinerImpl::visitGetElementPtrInst(GetElementPtrInst &GEP) {
if (GEPType->isVectorTy())
return nullptr;
+ if (!GEP.isInBounds()) {
+unsigned IdxWidth =
+DL.getIndexSizeInBits(PtrOp->getType()->getPointerAddressSpac
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134689
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
nikic wrote:
See also https://github.com/llvm/llvm-project/pull/76981.
https://github.com/llvm/llvm-project/pull/135156
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-
@@ -3087,12 +3087,22 @@ Instruction
*InstCombinerImpl::visitGetElementPtrInst(GetElementPtrInst &GEP) {
return nullptr;
if (GEP.getNumIndices() == 1) {
-// We can only preserve inbounds if the original gep is inbounds, the add
-// is nsw, and the add operands ar
@@ -3087,12 +3087,22 @@ Instruction
*InstCombinerImpl::visitGetElementPtrInst(GetElementPtrInst &GEP) {
return nullptr;
if (GEP.getNumIndices() == 1) {
-// We can only preserve inbounds if the original gep is inbounds, the add
-// is nsw, and the add operands ar
@@ -3087,12 +3087,22 @@ Instruction
*InstCombinerImpl::visitGetElementPtrInst(GetElementPtrInst &GEP) {
return nullptr;
if (GEP.getNumIndices() == 1) {
-// We can only preserve inbounds if the original gep is inbounds, the add
-// is nsw, and the add operands ar
nikic wrote:
Doesn't this break ABI by changing intrinsic / builtin numbers?
https://github.com/llvm/llvm-project/pull/133219
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-b
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134690
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -2294,10 +2294,14 @@ collectPromotionCandidates(MemorySSA *MSSA,
AliasAnalysis *AA, Loop *L) {
AliasSetTracker AST(BatchAA);
auto IsPotentiallyPromotable = [L](const Instruction *I) {
-if (const auto *SI = dyn_cast(I))
- return L->isLoopInvariant(SI->getPointe
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134688
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134691
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/134223
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic commented:
I'm somewhat skeptical that this really fits into llvm-reduce. Unless we make
the heuristic so narrow that it's likely useless in most cases, we'll hit cases
where inlining will reduce the size of the reduction.
The proper way to do a reduction that involves
nikic wrote:
I still don't think that using operand bundles for this is appropriate. If you
take a look at all the other operand bundles
(https://llvm.org/docs/LangRef.html#operand-bundles) they consistently have
some kind of impact on the semantics of the call. Also keep in mind that the
def
nikic wrote:
I'm not sure this is the right fix. I left a comment on the original PR:
https://github.com/llvm/llvm-project/pull/129914#pullrequestreview-2691932377
https://github.com/llvm/llvm-project/pull/130580
___
llvm-branch-commits mailing list
l
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/131568
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/130474
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
nikic wrote:
> @nikic Are you talking about the additions to the structures ?
Yes, the change to WasmLimits and the rename of WasmPageSize.
https://github.com/llvm/llvm-project/pull/129762
___
llvm-branch-commits mailing list
llvm-branch-commits@lists
https://github.com/nikic requested changes to this pull request.
This has multiple ABI and API breaking changes. I wonder why the ABI job
doesn't flag this.
https://github.com/llvm/llvm-project/pull/129762
___
llvm-branch-commits mailing list
llvm-bra
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/130964
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
nikic wrote:
> We can do this fold in InstSimplify: https://alive2.llvm.org/ce/z/Dm53TP
The transform is only valid if the freeze(poison) is one-use. And I don't think
that InstSimplify should be doing any use-based checks. So I think InstCombine
is the right place for it.
https://github.com/
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/129076
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
nikic wrote:
This needs to go into the main branch first, before it can be consider for
backport (to LLVM 20 only).
I'll close this PR due to the mass-subscribe.
https://github.com/llvm/llvm-project/pull/129076
___
llvm-branch-commits mailing list
ll
nikic wrote:
I think this is something that @fhahn as the LoopVectorize maintainer should
decide. I personally still don't see why this backport is necessary.
https://github.com/llvm/llvm-project/pull/128389
___
llvm-branch-commits mailing list
llvm-b
https://github.com/nikic approved this pull request.
Backporting crash fixes is fine at this point, especially if they're simple and
self-contained like this.
https://github.com/llvm/llvm-project/pull/128518
___
llvm-branch-commits mailing list
llvm-b
nikic wrote:
There is a test failure.
Why is it important for this change to be part of the LLVM 20 release?
https://github.com/llvm/llvm-project/pull/128389
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.or
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/127294
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
1 - 100 of 505 matches
Mail list logo
