[llvm-branch-commits] [clang] [llvm] release/18.x: [AArch64] Backport Ampere1B support (#81297 , #81341, and #81744) (PR #81857)

2024-02-22 Thread David Green via llvm-branch-commits

davemgreen wrote:

> Is this fixing a regression introduced in Clang 18? I'm wondering why the 
> backport is needed in the first place, as this seems to be making potentially 
> significant changes during the RC ("Make +pauth enabled in Armv8.3-a by 
> default").

It is adding new CPU support to clang 18, specifically the ampere-1b. I'm not 
sure what is considered acceptable at this stage. It is up to the release 
maintainers whether they want to accept it. On a technical level I believe it 
should be OK, but if only regressions are being fixed at this stage then it 
might be better to wait for clang-19. I'm not sure how much @ptomsich wanted to 
get this into clang-18?

https://github.com/llvm/llvm-project/pull/81857
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paschalis Mpeis via llvm-branch-commits

https://github.com/paschalis-mpeis updated 
https://github.com/llvm/llvm-project/pull/82488

>From 641aaf7c13d520bef52b092726f8346bfecb1c8d Mon Sep 17 00:00:00 2001
From: Paschalis Mpeis 
Date: Wed, 21 Feb 2024 11:53:00 +
Subject: [PATCH 1/4] SLP cannot vectorize frem calls in AArch64.

It needs updated costs when there are available vector library functions
given the VF and type.
---
 .../SLPVectorizer/AArch64/slp-frem.ll | 71 +++
 1 file changed, 71 insertions(+)
 create mode 100644 llvm/test/Transforms/SLPVectorizer/AArch64/slp-frem.ll

diff --git a/llvm/test/Transforms/SLPVectorizer/AArch64/slp-frem.ll 
b/llvm/test/Transforms/SLPVectorizer/AArch64/slp-frem.ll
new file mode 100644
index 00..45f667f5657889
--- /dev/null
+++ b/llvm/test/Transforms/SLPVectorizer/AArch64/slp-frem.ll
@@ -0,0 +1,71 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py 
UTC_ARGS: --version 4
+; RUN: opt < %s -S -mtriple=aarch64 -vector-library=ArmPL 
-passes=slp-vectorizer | FileCheck %s
+
+@a = common global ptr null, align 8
+
+define void @frem_v2double() {
+; CHECK-LABEL: define void @frem_v2double() {
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:[[A0:%.*]] = load double, ptr @a, align 8
+; CHECK-NEXT:[[A1:%.*]] = load double, ptr getelementptr inbounds (double, 
ptr @a, i64 1), align 8
+; CHECK-NEXT:[[B0:%.*]] = load double, ptr @a, align 8
+; CHECK-NEXT:[[B1:%.*]] = load double, ptr getelementptr inbounds (double, 
ptr @a, i64 1), align 8
+; CHECK-NEXT:[[R0:%.*]] = frem double [[A0]], [[B0]]
+; CHECK-NEXT:[[R1:%.*]] = frem double [[A1]], [[B1]]
+; CHECK-NEXT:store double [[R0]], ptr @a, align 8
+; CHECK-NEXT:store double [[R1]], ptr getelementptr inbounds (double, ptr 
@a, i64 1), align 8
+; CHECK-NEXT:ret void
+;
+entry:
+  %a0 = load double, ptr getelementptr inbounds (double, ptr @a, i64 0), align 
8
+  %a1 = load double, ptr getelementptr inbounds (double, ptr @a, i64 1), align 
8
+  %b0 = load double, ptr getelementptr inbounds (double, ptr @a, i64 0), align 
8
+  %b1 = load double, ptr getelementptr inbounds (double, ptr @a, i64 1), align 
8
+  %r0 = frem double %a0, %b0
+  %r1 = frem double %a1, %b1
+  store double %r0, ptr getelementptr inbounds (double, ptr @a, i64 0), align 8
+  store double %r1, ptr getelementptr inbounds (double, ptr @a, i64 1), align 8
+  ret void
+}
+
+define void @frem_v4float() {
+; CHECK-LABEL: define void @frem_v4float() {
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:[[A0:%.*]] = load float, ptr @a, align 8
+; CHECK-NEXT:[[A1:%.*]] = load float, ptr getelementptr inbounds (float, 
ptr @a, i64 1), align 8
+; CHECK-NEXT:[[A2:%.*]] = load float, ptr getelementptr inbounds (float, 
ptr @a, i64 2), align 8
+; CHECK-NEXT:[[A3:%.*]] = load float, ptr getelementptr inbounds (float, 
ptr @a, i64 3), align 8
+; CHECK-NEXT:[[B0:%.*]] = load float, ptr @a, align 8
+; CHECK-NEXT:[[B1:%.*]] = load float, ptr getelementptr inbounds (float, 
ptr @a, i64 1), align 8
+; CHECK-NEXT:[[B2:%.*]] = load float, ptr getelementptr inbounds (float, 
ptr @a, i64 2), align 8
+; CHECK-NEXT:[[B3:%.*]] = load float, ptr getelementptr inbounds (float, 
ptr @a, i64 3), align 8
+; CHECK-NEXT:[[R0:%.*]] = frem float [[A0]], [[B0]]
+; CHECK-NEXT:[[R1:%.*]] = frem float [[A1]], [[B1]]
+; CHECK-NEXT:[[R2:%.*]] = frem float [[A2]], [[B2]]
+; CHECK-NEXT:[[R3:%.*]] = frem float [[A3]], [[B3]]
+; CHECK-NEXT:store float [[R0]], ptr @a, align 8
+; CHECK-NEXT:store float [[R1]], ptr getelementptr inbounds (float, ptr 
@a, i64 1), align 8
+; CHECK-NEXT:store float [[R2]], ptr getelementptr inbounds (float, ptr 
@a, i64 2), align 8
+; CHECK-NEXT:store float [[R3]], ptr getelementptr inbounds (float, ptr 
@a, i64 3), align 8
+; CHECK-NEXT:ret void
+;
+entry:
+  %a0 = load float, ptr getelementptr inbounds (float, ptr @a, i64 0), align 8
+  %a1 = load float, ptr getelementptr inbounds (float, ptr @a, i64 1), align 8
+  %a2 = load float, ptr getelementptr inbounds (float, ptr @a, i64 2), align 8
+  %a3 = load float, ptr getelementptr inbounds (float, ptr @a, i64 3), align 8
+  %b0 = load float, ptr getelementptr inbounds (float, ptr @a, i64 0), align 8
+  %b1 = load float, ptr getelementptr inbounds (float, ptr @a, i64 1), align 8
+  %b2 = load float, ptr getelementptr inbounds (float, ptr @a, i64 2), align 8
+  %b3 = load float, ptr getelementptr inbounds (float, ptr @a, i64 3), align 8
+  %r0 = frem float %a0, %b0
+  %r1 = frem float %a1, %b1
+  %r2 = frem float %a2, %b2
+  %r3 = frem float %a3, %b3
+  store float %r0, ptr getelementptr inbounds (float, ptr @a, i64 0), align 8
+  store float %r1, ptr getelementptr inbounds (float, ptr @a, i64 1), align 8
+  store float %r2, ptr getelementptr inbounds (float, ptr @a, i64 2), align 8
+  store float %r3, ptr getelementptr inbounds (float, ptr @a, i64 3), align 8
+  ret void
+}
+

>From 29ae086478e3d4bae6b6250670f87273359626d7 Mon Sep 17 

[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paschalis Mpeis via llvm-branch-commits


@@ -869,6 +870,18 @@ TargetTransformInfo::getOperandInfo(const Value *V) {
   return {OpInfo, OpProps};
 }
 
+InstructionCost TargetTransformInfo::getVecLibCallCost(
+const int OpCode, const TargetLibraryInfo *TLI, VectorType *VecTy,
+TTI::TargetCostKind CostKind) {
+  Type *ScalarTy = VecTy->getScalarType();
+  LibFunc Func;
+  if (TLI->getLibFunc(OpCode, ScalarTy, Func) &&
+  TLI->isFunctionVectorizable(TLI->getName(Func), 
VecTy->getElementCount()))

paschalis-mpeis wrote:

Actually, in LoopVectorizer we have done it this way.

For the sake of reusing the code between the 2 vectorizers, I've put it in TTI, 
but after our discussion I've now moved it to `VectorUtils`. LoopVectorizer 
should now reuse this method.

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] [llvm] release/18.x: [AArch64] Backport Ampere1B support (#81297 , #81341, and #81744) (PR #81857)

2024-02-22 Thread Philipp Tomsich via llvm-branch-commits

ptomsich wrote:

> > Is this fixing a regression introduced in Clang 18? I'm wondering why the 
> > backport is needed in the first place, as this seems to be making 
> > potentially significant changes during the RC ("Make +pauth enabled in 
> > Armv8.3-a by default").
> 
> It is adding new CPU support to clang 18, specifically the ampere-1b. I'm not 
> sure what is considered acceptable at this stage. It is up to the release 
> maintainers whether they want to accept it. On a technical level I believe it 
> should be OK, but if only regressions are being fixed at this stage then it 
> might be better to wait for clang-19. I'm not sure how much @ptomsich wanted 
> to get this into clang-18?

Getting this into clang-18 is highly desirable to ensure it recognizes 
"-mcpu=ampere1b" and emits the CSSC instructions for the core.  I would prefer 
not to wait for clang-19, even though we ended up late in the cycle.

https://github.com/llvm/llvm-project/pull/81857
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] [llvm] release/18.x: [AArch64] Backport Ampere1B support (#81297 , #81341, and #81744) (PR #81857)

2024-02-22 Thread Philipp Tomsich via llvm-branch-commits

ptomsich wrote:

On a different note: the "+pauth" fix would be helpful in clang-18 as well, 
given that it brings the definition of "-march=armv8.3-a" in sync with the 
specification.

https://github.com/llvm/llvm-project/pull/81857
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paschalis Mpeis via llvm-branch-commits


@@ -8362,9 +8362,20 @@ BoUpSLP::getEntryCost(const TreeEntry *E, ArrayRef VectorizedVals,
   unsigned OpIdx = isa(VL0) ? 0 : 1;
   TTI::OperandValueInfo Op1Info = getOperandInfo(E->getOperand(0));
   TTI::OperandValueInfo Op2Info = getOperandInfo(E->getOperand(OpIdx));
-  return TTI->getArithmeticInstrCost(ShuffleOrOp, VecTy, CostKind, Op1Info,
- Op2Info) +
- CommonCost;
+  auto VecCost = TTI->getArithmeticInstrCost(ShuffleOrOp, VecTy, CostKind,
+ Op1Info, Op2Info);
+  // Some targets can replace frem with vector library calls.
+  if (ShuffleOrOp == Instruction::FRem) {
+LibFunc Func;
+if (TLI->getLibFunc(ShuffleOrOp, ScalarTy, Func) &&
+TLI->isFunctionVectorizable(TLI->getName(Func),
+VecTy->getElementCount())) {

paschalis-mpeis wrote:

I'd rather not adapt `TTI.getArithmeticInstrCost` API, as that would cause 
changes in 150+ places, including every target that overrides that. But I 
understand your concern as this is specific, affecting one of our instructions.

TLI is simply passed to `getVecLibCallCost`, just like it's widely passed 
around in other places in the SLP code. This isn't making the code any target 
dependent, TLI/TTI are abstractions to that.

Internally, `getVecLibCallCost` does those checks, which have now moved to 
`VectorUtils`.
SLP gets a valid cost if there's one, and picks the minimum between the two.

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [mlir] [mlir][Transforms][NFC] Turn op creation into `IRRewrite` (PR #81759)

2024-02-22 Thread Matthias Springer via llvm-branch-commits


@@ -2549,10 +2572,15 @@ LogicalResult 
OperationConverter::legalizeConvertedArgumentTypes(
 });
 return liveUserIt == val.user_end() ? nullptr : *liveUserIt;
   };
-  for (auto &r : rewriterImpl.rewrites)
-if (auto *rewrite = dyn_cast(r.get()))
-  if (failed(rewrite->materializeLiveConversions(findLiveUser)))
+  // Note: `rewrites` may be reallocated as the loop is running.
+  for (int64_t i = 0; i < rewriterImpl.rewrites.size(); ++i) {

matthias-springer wrote:

That won't work here because things may get added to the vector while the loop 
is running and that could invalidate the iterator (when the vector reallocates 
storage).


https://github.com/llvm/llvm-project/pull/81759
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [mlir] [mlir][Transforms][NFC] Turn op creation into `IRRewrite` (PR #81759)

2024-02-22 Thread Matthias Springer via llvm-branch-commits

https://github.com/matthias-springer updated 
https://github.com/llvm/llvm-project/pull/81759

>From d15c439f166426a613ac0021a9101b774d544357 Mon Sep 17 00:00:00 2001
From: Matthias Springer 
Date: Fri, 16 Feb 2024 15:21:48 +
Subject: [PATCH] [mlir][Transforms][NFC] Turn op creation into `IRRewrite`

This commit is a refactoring of the dialect conversion. The dialect conversion 
maintains a list of "IR rewrites" that can be commited (upon success) or rolled 
back (upon failure).

Until now, the dialect conversion kept track of "op creation" in separate 
internal data structures. This commit turns "op creation" into an `IRRewrite` 
that can be committed and rolled back just like any other rewrite. This commit 
simplifies the internal state of the dialect conversion.
---
 .../Transforms/Utils/DialectConversion.cpp| 101 +++---
 1 file changed, 63 insertions(+), 38 deletions(-)

diff --git a/mlir/lib/Transforms/Utils/DialectConversion.cpp 
b/mlir/lib/Transforms/Utils/DialectConversion.cpp
index dec68048dc1d30..ae81dfa4d8303b 100644
--- a/mlir/lib/Transforms/Utils/DialectConversion.cpp
+++ b/mlir/lib/Transforms/Utils/DialectConversion.cpp
@@ -152,17 +152,12 @@ namespace {
 /// This class contains a snapshot of the current conversion rewriter state.
 /// This is useful when saving and undoing a set of rewrites.
 struct RewriterState {
-  RewriterState(unsigned numCreatedOps, unsigned numUnresolvedMaterializations,
-unsigned numRewrites, unsigned numIgnoredOperations,
-unsigned numErased)
-  : numCreatedOps(numCreatedOps),
-numUnresolvedMaterializations(numUnresolvedMaterializations),
+  RewriterState(unsigned numUnresolvedMaterializations, unsigned numRewrites,
+unsigned numIgnoredOperations, unsigned numErased)
+  : numUnresolvedMaterializations(numUnresolvedMaterializations),
 numRewrites(numRewrites), numIgnoredOperations(numIgnoredOperations),
 numErased(numErased) {}
 
-  /// The current number of created operations.
-  unsigned numCreatedOps;
-
   /// The current number of unresolved materializations.
   unsigned numUnresolvedMaterializations;
 
@@ -303,7 +298,8 @@ class IRRewrite {
 // Operation rewrites
 MoveOperation,
 ModifyOperation,
-ReplaceOperation
+ReplaceOperation,
+CreateOperation
   };
 
   virtual ~IRRewrite() = default;
@@ -376,7 +372,10 @@ class CreateBlockRewrite : public BlockRewrite {
 auto &blockOps = block->getOperations();
 while (!blockOps.empty())
   blockOps.remove(blockOps.begin());
-eraseBlock(block);
+if (block->getParent())
+  eraseBlock(block);
+else
+  delete block;
   }
 };
 
@@ -606,7 +605,7 @@ class OperationRewrite : public IRRewrite {
 
   static bool classof(const IRRewrite *rewrite) {
 return rewrite->getKind() >= Kind::MoveOperation &&
-   rewrite->getKind() <= Kind::ReplaceOperation;
+   rewrite->getKind() <= Kind::CreateOperation;
   }
 
 protected:
@@ -740,6 +739,19 @@ class ReplaceOperationRewrite : public OperationRewrite {
   /// A boolean flag that indicates whether result types have changed or not.
   bool changedResults;
 };
+
+class CreateOperationRewrite : public OperationRewrite {
+public:
+  CreateOperationRewrite(ConversionPatternRewriterImpl &rewriterImpl,
+ Operation *op)
+  : OperationRewrite(Kind::CreateOperation, rewriterImpl, op) {}
+
+  static bool classof(const IRRewrite *rewrite) {
+return rewrite->getKind() == Kind::CreateOperation;
+  }
+
+  void rollback() override;
+};
 } // namespace
 
 /// Return "true" if there is an operation rewrite that matches the specified
@@ -957,9 +969,6 @@ struct ConversionPatternRewriterImpl : public 
RewriterBase::Listener {
   // replacing a value with one of a different type.
   ConversionValueMapping mapping;
 
-  /// Ordered vector of all of the newly created operations during conversion.
-  SmallVector createdOps;
-
   /// Ordered vector of all unresolved type conversion materializations during
   /// conversion.
   SmallVector unresolvedMaterializations;
@@ -1144,6 +1153,15 @@ void ReplaceOperationRewrite::rollback() {
 
 void ReplaceOperationRewrite::cleanup() { eraseOp(op); }
 
+void CreateOperationRewrite::rollback() {
+  for (Region ®ion : op->getRegions()) {
+while (!region.getBlocks().empty())
+  region.getBlocks().remove(region.getBlocks().begin());
+  }
+  op->dropAllUses();
+  eraseOp(op);
+}
+
 void ConversionPatternRewriterImpl::detachNestedAndErase(Operation *op) {
   for (Region ®ion : op->getRegions()) {
 for (Block &block : region.getBlocks()) {
@@ -1161,8 +1179,6 @@ void ConversionPatternRewriterImpl::discardRewrites() {
   // Remove any newly created ops.
   for (UnresolvedMaterialization &materialization : unresolvedMaterializations)
 detachNestedAndErase(materialization.getOp());
-  for (auto *op : llvm::reverse(createdOps))
-detachNestedAndErase(op);
 }
 
 void C

[llvm-branch-commits] [mlir] [mlir][Transforms][NFC] Turn unresolved materializations into `IRRewrite`s (PR #81761)

2024-02-22 Thread Matthias Springer via llvm-branch-commits

https://github.com/matthias-springer updated 
https://github.com/llvm/llvm-project/pull/81761

>From 6d02f6d545fff81a41b7e40fa48f19c55483c77b Mon Sep 17 00:00:00 2001
From: Matthias Springer 
Date: Mon, 19 Feb 2024 10:29:29 +
Subject: [PATCH] [WIP] UnresolvedMaterialization

BEGIN_PUBLIC
No public commit message needed for presubmit.
END_PUBLIC
---
 .../Transforms/Utils/DialectConversion.cpp| 369 +-
 1 file changed, 176 insertions(+), 193 deletions(-)

diff --git a/mlir/lib/Transforms/Utils/DialectConversion.cpp 
b/mlir/lib/Transforms/Utils/DialectConversion.cpp
index ae81dfa4d8303b..5ed31e35dc0705 100644
--- a/mlir/lib/Transforms/Utils/DialectConversion.cpp
+++ b/mlir/lib/Transforms/Utils/DialectConversion.cpp
@@ -152,15 +152,11 @@ namespace {
 /// This class contains a snapshot of the current conversion rewriter state.
 /// This is useful when saving and undoing a set of rewrites.
 struct RewriterState {
-  RewriterState(unsigned numUnresolvedMaterializations, unsigned numRewrites,
-unsigned numIgnoredOperations, unsigned numErased)
-  : numUnresolvedMaterializations(numUnresolvedMaterializations),
-numRewrites(numRewrites), numIgnoredOperations(numIgnoredOperations),
+  RewriterState(unsigned numRewrites, unsigned numIgnoredOperations,
+unsigned numErased)
+  : numRewrites(numRewrites), numIgnoredOperations(numIgnoredOperations),
 numErased(numErased) {}
 
-  /// The current number of unresolved materializations.
-  unsigned numUnresolvedMaterializations;
-
   /// The current number of rewrites performed.
   unsigned numRewrites;
 
@@ -171,109 +167,10 @@ struct RewriterState {
   unsigned numErased;
 };
 
-//===--===//
-// UnresolvedMaterialization
-
-/// This class represents an unresolved materialization, i.e. a materialization
-/// that was inserted during conversion that needs to be legalized at the end 
of
-/// the conversion process.
-class UnresolvedMaterialization {
-public:
-  /// The type of materialization.
-  enum Kind {
-/// This materialization materializes a conversion for an illegal block
-/// argument type, to a legal one.
-Argument,
-
-/// This materialization materializes a conversion from an illegal type to 
a
-/// legal one.
-Target
-  };
-
-  UnresolvedMaterialization(UnrealizedConversionCastOp op = nullptr,
-const TypeConverter *converter = nullptr,
-Kind kind = Target, Type origOutputType = nullptr)
-  : op(op), converterAndKind(converter, kind),
-origOutputType(origOutputType) {}
-
-  /// Return the temporary conversion operation inserted for this
-  /// materialization.
-  UnrealizedConversionCastOp getOp() const { return op; }
-
-  /// Return the type converter of this materialization (which may be null).
-  const TypeConverter *getConverter() const {
-return converterAndKind.getPointer();
-  }
-
-  /// Return the kind of this materialization.
-  Kind getKind() const { return converterAndKind.getInt(); }
-
-  /// Set the kind of this materialization.
-  void setKind(Kind kind) { converterAndKind.setInt(kind); }
-
-  /// Return the original illegal output type of the input values.
-  Type getOrigOutputType() const { return origOutputType; }
-
-private:
-  /// The unresolved materialization operation created during conversion.
-  UnrealizedConversionCastOp op;
-
-  /// The corresponding type converter to use when resolving this
-  /// materialization, and the kind of this materialization.
-  llvm::PointerIntPair converterAndKind;
-
-  /// The original output type. This is only used for argument conversions.
-  Type origOutputType;
-};
-} // namespace
-
-/// Build an unresolved materialization operation given an output type and set
-/// of input operands.
-static Value buildUnresolvedMaterialization(
-UnresolvedMaterialization::Kind kind, Block *insertBlock,
-Block::iterator insertPt, Location loc, ValueRange inputs, Type outputType,
-Type origOutputType, const TypeConverter *converter,
-SmallVectorImpl &unresolvedMaterializations) {
-  // Avoid materializing an unnecessary cast.
-  if (inputs.size() == 1 && inputs.front().getType() == outputType)
-return inputs.front();
-
-  // Create an unresolved materialization. We use a new OpBuilder to avoid
-  // tracking the materialization like we do for other operations.
-  OpBuilder builder(insertBlock, insertPt);
-  auto convertOp =
-  builder.create(loc, outputType, inputs);
-  unresolvedMaterializations.emplace_back(convertOp, converter, kind,
-  origOutputType);
-  return convertOp.getResult(0);
-}
-static Value buildUnresolvedArgumentMaterialization(
-PatternRewriter &rewriter, Location loc, ValueRange inputs,
-Type origOutputType, Type outputType, const TypeConverter *converter,
-SmallVectorImpl &unresolvedMaterial

[llvm-branch-commits] [clang] [Clang] Fixes to immediate-escalating functions (#82281) (PR #82609)

2024-02-22 Thread Balazs Benics via llvm-branch-commits

https://github.com/steakhal milestoned 
https://github.com/llvm/llvm-project/pull/82609
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] [Clang] Fixes to immediate-escalating functions (#82281) (PR #82609)

2024-02-22 Thread Balazs Benics via llvm-branch-commits

https://github.com/steakhal created 
https://github.com/llvm/llvm-project/pull/82609

* Consider that immediate escalating function can appear at global scope, 
fixing a crash

* Lambda conversion to function pointer was sometimes not performed in an 
immediate function context when it should be.

Fixes #82258

(cherry picked from commit baf6bd303bd58a521809d456dd9b179636982fc5)

>From 96303d3df997659bf964693517509d4545a1f82c Mon Sep 17 00:00:00 2001
From: cor3ntin 
Date: Wed, 21 Feb 2024 20:53:44 +0100
Subject: [PATCH] [Clang] Fixes to immediate-escalating functions (#82281)

* Consider that immediate escalating function can appear at global
scope, fixing a crash

* Lambda conversion to function pointer was sometimes not performed in
an immediate function context when it should be.

Fixes #82258

(cherry picked from commit baf6bd303bd58a521809d456dd9b179636982fc5)
---
 clang/docs/ReleaseNotes.rst   |  5 
 clang/include/clang/Sema/Sema.h   |  4 ++-
 clang/lib/Sema/SemaExpr.cpp   |  4 +--
 .../SemaCXX/cxx2b-consteval-propagate.cpp | 26 +++
 4 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 93a67e7a895592..8697f1f3bbe9c2 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -1099,6 +1099,11 @@ Bug Fixes to C++ Support
 - Fix incorrect code generation caused by the object argument of ``static 
operator()`` and ``static operator[]`` calls not being evaluated.
   Fixes (`#67976 `_)
 
+- Fix crash when using an immediate-escalated function at global scope.
+  (`#82258 `_)
+- Correctly immediate-escalate lambda conversion functions.
+  (`#82258 `_)
+
 Bug Fixes to AST Handling
 ^
 - Fixed an import failure of recursive friend class template.
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 1f1cbd11ff7358..6adb8fb7966b3f 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -1090,7 +1090,9 @@ class Sema final {
   if (FD) {
 FD->setWillHaveBody(true);
 S.ExprEvalContexts.back().InImmediateFunctionContext =
-FD->isImmediateFunction();
+FD->isImmediateFunction() ||
+S.ExprEvalContexts[S.ExprEvalContexts.size() - 2]
+.isConstantEvaluated();
 S.ExprEvalContexts.back().InImmediateEscalatingFunctionContext =
 S.getLangOpts().CPlusPlus20 && FD->isImmediateEscalating();
   } else
diff --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 0d9c087ed0cd19..4cce0abc231505 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -18294,7 +18294,6 @@ void Sema::CheckUnusedVolatileAssignment(Expr *E) {
 }
 
 void Sema::MarkExpressionAsImmediateEscalating(Expr *E) {
-  assert(!FunctionScopes.empty() && "Expected a function scope");
   assert(getLangOpts().CPlusPlus20 &&
  ExprEvalContexts.back().InImmediateEscalatingFunctionContext &&
  "Cannot mark an immediate escalating expression outside of an "
@@ -18311,7 +18310,8 @@ void Sema::MarkExpressionAsImmediateEscalating(Expr *E) 
{
   } else {
 assert(false && "expected an immediately escalating expression");
   }
-  getCurFunction()->FoundImmediateEscalatingExpression = true;
+  if (FunctionScopeInfo *FI = getCurFunction())
+FI->FoundImmediateEscalatingExpression = true;
 }
 
 ExprResult Sema::CheckForImmediateInvocation(ExprResult E, FunctionDecl *Decl) 
{
diff --git a/clang/test/SemaCXX/cxx2b-consteval-propagate.cpp 
b/clang/test/SemaCXX/cxx2b-consteval-propagate.cpp
index 531a6262287335..4a75392045d05a 100644
--- a/clang/test/SemaCXX/cxx2b-consteval-propagate.cpp
+++ b/clang/test/SemaCXX/cxx2b-consteval-propagate.cpp
@@ -368,3 +368,29 @@ vector v{};
 // expected-note@-2 {{in call to 'vector()'}}
 
 }
+
+
+namespace GH82258 {
+
+template 
+constexpr auto none_of(R&& r, Pred pred) -> bool { return true; }
+
+struct info { int value; };
+consteval auto is_invalid(info i) -> bool { return false; }
+constexpr info types[] = { {1}, {3}, {5}};
+
+static_assert(none_of(
+types,
++[](info i) consteval {
+return is_invalid(i);
+}
+));
+
+static_assert(none_of(
+types,
+[]{
+return is_invalid;
+}()
+));
+
+}

___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] [Clang] Fixes to immediate-escalating functions (#82281) (PR #82609)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Balazs Benics (steakhal)


Changes

* Consider that immediate escalating function can appear at global scope, 
fixing a crash

* Lambda conversion to function pointer was sometimes not performed in an 
immediate function context when it should be.

Fixes #82258

(cherry picked from commit baf6bd303bd58a521809d456dd9b179636982fc5)

---
Full diff: https://github.com/llvm/llvm-project/pull/82609.diff


4 Files Affected:

- (modified) clang/docs/ReleaseNotes.rst (+5) 
- (modified) clang/include/clang/Sema/Sema.h (+3-1) 
- (modified) clang/lib/Sema/SemaExpr.cpp (+2-2) 
- (modified) clang/test/SemaCXX/cxx2b-consteval-propagate.cpp (+26) 


``diff
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 93a67e7a895592..8697f1f3bbe9c2 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -1099,6 +1099,11 @@ Bug Fixes to C++ Support
 - Fix incorrect code generation caused by the object argument of ``static 
operator()`` and ``static operator[]`` calls not being evaluated.
   Fixes (`#67976 `_)
 
+- Fix crash when using an immediate-escalated function at global scope.
+  (`#82258 `_)
+- Correctly immediate-escalate lambda conversion functions.
+  (`#82258 `_)
+
 Bug Fixes to AST Handling
 ^
 - Fixed an import failure of recursive friend class template.
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 1f1cbd11ff7358..6adb8fb7966b3f 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -1090,7 +1090,9 @@ class Sema final {
   if (FD) {
 FD->setWillHaveBody(true);
 S.ExprEvalContexts.back().InImmediateFunctionContext =
-FD->isImmediateFunction();
+FD->isImmediateFunction() ||
+S.ExprEvalContexts[S.ExprEvalContexts.size() - 2]
+.isConstantEvaluated();
 S.ExprEvalContexts.back().InImmediateEscalatingFunctionContext =
 S.getLangOpts().CPlusPlus20 && FD->isImmediateEscalating();
   } else
diff --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 0d9c087ed0cd19..4cce0abc231505 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -18294,7 +18294,6 @@ void Sema::CheckUnusedVolatileAssignment(Expr *E) {
 }
 
 void Sema::MarkExpressionAsImmediateEscalating(Expr *E) {
-  assert(!FunctionScopes.empty() && "Expected a function scope");
   assert(getLangOpts().CPlusPlus20 &&
  ExprEvalContexts.back().InImmediateEscalatingFunctionContext &&
  "Cannot mark an immediate escalating expression outside of an "
@@ -18311,7 +18310,8 @@ void Sema::MarkExpressionAsImmediateEscalating(Expr *E) 
{
   } else {
 assert(false && "expected an immediately escalating expression");
   }
-  getCurFunction()->FoundImmediateEscalatingExpression = true;
+  if (FunctionScopeInfo *FI = getCurFunction())
+FI->FoundImmediateEscalatingExpression = true;
 }
 
 ExprResult Sema::CheckForImmediateInvocation(ExprResult E, FunctionDecl *Decl) 
{
diff --git a/clang/test/SemaCXX/cxx2b-consteval-propagate.cpp 
b/clang/test/SemaCXX/cxx2b-consteval-propagate.cpp
index 531a6262287335..4a75392045d05a 100644
--- a/clang/test/SemaCXX/cxx2b-consteval-propagate.cpp
+++ b/clang/test/SemaCXX/cxx2b-consteval-propagate.cpp
@@ -368,3 +368,29 @@ vector v{};
 // expected-note@-2 {{in call to 'vector()'}}
 
 }
+
+
+namespace GH82258 {
+
+template 
+constexpr auto none_of(R&& r, Pred pred) -> bool { return true; }
+
+struct info { int value; };
+consteval auto is_invalid(info i) -> bool { return false; }
+constexpr info types[] = { {1}, {3}, {5}};
+
+static_assert(none_of(
+types,
++[](info i) consteval {
+return is_invalid(i);
+}
+));
+
+static_assert(none_of(
+types,
+[]{
+return is_invalid;
+}()
+));
+
+}

``




https://github.com/llvm/llvm-project/pull/82609
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Alexey Bataev via llvm-branch-commits


@@ -869,6 +870,18 @@ TargetTransformInfo::getOperandInfo(const Value *V) {
   return {OpInfo, OpProps};
 }
 
+InstructionCost TargetTransformInfo::getVecLibCallCost(
+const int OpCode, const TargetLibraryInfo *TLI, VectorType *VecTy,
+TTI::TargetCostKind CostKind) {
+  Type *ScalarTy = VecTy->getScalarType();
+  LibFunc Func;
+  if (TLI->getLibFunc(OpCode, ScalarTy, Func) &&
+  TLI->isFunctionVectorizable(TLI->getName(Func), 
VecTy->getElementCount()))

alexey-bataev wrote:

I disagree with this approach and still insist that it should be implemented in 
TTI rather doing some target specific "magic" in the vectorizers

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paul Walker via llvm-branch-commits


@@ -869,6 +870,18 @@ TargetTransformInfo::getOperandInfo(const Value *V) {
   return {OpInfo, OpProps};
 }
 
+InstructionCost TargetTransformInfo::getVecLibCallCost(
+const int OpCode, const TargetLibraryInfo *TLI, VectorType *VecTy,
+TTI::TargetCostKind CostKind) {
+  Type *ScalarTy = VecTy->getScalarType();
+  LibFunc Func;
+  if (TLI->getLibFunc(OpCode, ScalarTy, Func) &&
+  TLI->isFunctionVectorizable(TLI->getName(Func), 
VecTy->getElementCount()))

paulwalker-arm wrote:

TTI should be costing known entities and not trying to second guess what a 
transformation is doing.  Whilst TLI provides a route for target specific 
queries relating to the availability of vector math routines, that doesn’t mean 
those mapping will be used.  The only source of truth is the transformation 
pass itself and thus it needs to ask the TTI the correct question based on this 
source of truth (i.e. whether it intends to use TLI mappings[1]). Both TTI and 
TLI abstract away the target specific queries relating to their design so I 
don’t understand what is the target specific “magic” you are worried about.

[1] This is very important because if the vector function is not used then a 
scalable vector FREM must have an invalid cost because there is no code 
generation support for it.

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Alexey Bataev via llvm-branch-commits


@@ -869,6 +870,18 @@ TargetTransformInfo::getOperandInfo(const Value *V) {
   return {OpInfo, OpProps};
 }
 
+InstructionCost TargetTransformInfo::getVecLibCallCost(
+const int OpCode, const TargetLibraryInfo *TLI, VectorType *VecTy,
+TTI::TargetCostKind CostKind) {
+  Type *ScalarTy = VecTy->getScalarType();
+  LibFunc Func;
+  if (TLI->getLibFunc(OpCode, ScalarTy, Func) &&
+  TLI->isFunctionVectorizable(TLI->getName(Func), 
VecTy->getElementCount()))

alexey-bataev wrote:

It does not known what transsformation is doing, it does exactly what you said 
- estimates the cost of the target-specific code. WE're not emitting frem calls 
directly, we're still emitting regular frem vector code, which is then lowered 
specifically for ARM. And target specific TTI should be aware of this.

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paul Walker via llvm-branch-commits


@@ -869,6 +870,18 @@ TargetTransformInfo::getOperandInfo(const Value *V) {
   return {OpInfo, OpProps};
 }
 
+InstructionCost TargetTransformInfo::getVecLibCallCost(
+const int OpCode, const TargetLibraryInfo *TLI, VectorType *VecTy,
+TTI::TargetCostKind CostKind) {
+  Type *ScalarTy = VecTy->getScalarType();
+  LibFunc Func;
+  if (TLI->getLibFunc(OpCode, ScalarTy, Func) &&
+  TLI->isFunctionVectorizable(TLI->getName(Func), 
VecTy->getElementCount()))

paulwalker-arm wrote:

OK, I see what you're saying.  I guess the problem here is that we're relying 
on a subsequent pass (ReplaceWithVecLib) to be present in the pipeline in order 
to correctly cost the FREM. With neither SLP nor TTI having this knowledge?

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] [llvm] [MC/DC][Coverage] Loosen the limit of NumConds from 6 (PR #82448)

2024-02-22 Thread NAKAMURA Takumi via llvm-branch-commits

https://github.com/chapuni edited 
https://github.com/llvm/llvm-project/pull/82448
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] [llvm] [MC/DC][Coverage] Loosen the limit of NumConds from 6 (PR #82448)

2024-02-22 Thread NAKAMURA Takumi via llvm-branch-commits


@@ -1979,6 +2069,9 @@ struct CounterCoverageMappingBuilder
 // Track RHS True/False Decision.
 const auto DecisionRHS = MCDCBuilder.back();
 
+MCDCBuilder.ccc(E->getLHS(), DecisionLHS);
+MCDCBuilder.ccc(E->getRHS(), DecisionRHS);

chapuni wrote:

I wonder they could be integrated to `createBranchRegion`.

https://github.com/llvm/llvm-project/pull/82448
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] [llvm] [MC/DC][Coverage] Loosen the limit of NumConds from 6 (PR #82448)

2024-02-22 Thread NAKAMURA Takumi via llvm-branch-commits


@@ -723,7 +737,15 @@ struct MCDCCoverageBuilder {
 if (I == CondIDs.end())
   return -1;
 else
-  return I->second;
+  return I->second.ID;
+  }
+
+  void ccc(const Expr *CondExpr, mcdc::ConditionIDs IDs) {
+auto ID = getCondID(CondExpr);
+if (ID < 0)
+  return;
+if (!cache.contains(ID))
+  cache[ID] = IDs;

chapuni wrote:

I wonder `cache` could be retrieved from other existing records.

https://github.com/llvm/llvm-project/pull/82448
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] [llvm] [MC/DC][Coverage] Loosen the limit of NumConds from 6 (PR #82448)

2024-02-22 Thread NAKAMURA Takumi via llvm-branch-commits

https://github.com/chapuni commented:

I know I still have a couple of arbitrary names.
They come from my prototype.

* `MCDCCoverageBuilder::cache` -- will be "NextIDs list"
* `MCDCCoverageBuilder ::ccc(Expr, IDs)` -- just updates `cache`.

I will try to dissolve them within a few days.

https://github.com/llvm/llvm-project/pull/82448
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Alexey Bataev via llvm-branch-commits


@@ -869,6 +870,18 @@ TargetTransformInfo::getOperandInfo(const Value *V) {
   return {OpInfo, OpProps};
 }
 
+InstructionCost TargetTransformInfo::getVecLibCallCost(
+const int OpCode, const TargetLibraryInfo *TLI, VectorType *VecTy,
+TTI::TargetCostKind CostKind) {
+  Type *ScalarTy = VecTy->getScalarType();
+  LibFunc Func;
+  if (TLI->getLibFunc(OpCode, ScalarTy, Func) &&
+  TLI->isFunctionVectorizable(TLI->getName(Func), 
VecTy->getElementCount()))

alexey-bataev wrote:

Yes, and what I'm saying that TTI should handle this since this is 
target-specific lowering.
If you don't want to propagate TLI, then just copy the legality checks from TLI 
to TTI and the cost estimation for this specific lowering to the 
getArithmeticInstructionCost function. This is what we usually do in similar 
cases for other targets.

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paul Walker via llvm-branch-commits

https://github.com/paulwalker-arm edited 
https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paul Walker via llvm-branch-commits


@@ -869,6 +870,18 @@ TargetTransformInfo::getOperandInfo(const Value *V) {
   return {OpInfo, OpProps};
 }
 
+InstructionCost TargetTransformInfo::getVecLibCallCost(
+const int OpCode, const TargetLibraryInfo *TLI, VectorType *VecTy,
+TTI::TargetCostKind CostKind) {
+  Type *ScalarTy = VecTy->getScalarType();
+  LibFunc Func;
+  if (TLI->getLibFunc(OpCode, ScalarTy, Func) &&
+  TLI->isFunctionVectorizable(TLI->getName(Func), 
VecTy->getElementCount()))

paulwalker-arm wrote:

I think it's more subtle than this.  Sure there's some target specific 
behaviour but that is hidden behind TLI as it should be, and I have no problem 
passing TLI into a TTI cost function.  The problem with TTI is that it needs to 
give a different answer based on whether it is called before the 
ReplaceWithVecLib pass or after (or when ReplaceWithVecLib is never run).  I 
don't think TTI has access to such information? Not would I want this to be 
something all cost functions need to worry about.

Personally I'm happy with keeping this nuance outside of TTI but if we really 
want this captured within TTI then I think it's time to break FREM into its own 
cost function (i.e. implement `getFRemInstrCost`.  That way 
getArithmeticInstrCost can work as it does today and the new function can be 
documented to highlight it's assumption that if a TLI is passed in and a vector 
mapping is present then the return value is only valid based on it's assumption 
that vector FREM instructions will be transformed by a following transformation 
pass.  I prefer this to say, adding TLI to getArithmeticInstrCost, because I'd 
rather users of `getFRemInstrCost` to explicitly enter into this contract.


https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paul Walker via llvm-branch-commits

https://github.com/paulwalker-arm commented:

I've review the patch from both side so most of the comment will be void if you 
opt for the new TTI hook.  That advantage of the TTI hook is that because it is 
specific to FREM you can hardware things like numbers of operands, which should 
streamline the implementation.

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paul Walker via llvm-branch-commits


@@ -410,6 +410,14 @@ bool maskIsAllOneOrUndef(Value *Mask);
 /// for each lane which may be active.
 APInt possiblyDemandedEltsInMask(Value *Mask);
 
+/// Returns the cost of a call when a target has a vector library function for
+/// the given \p VecTy, otherwise an invalid cost.

paulwalker-arm wrote:

I think this misses a crucial point as to why it exists.  Perhaps something 
like:

"Returns the cost of a vector instruction based on the assumption that it'll be 
later transformed (by ReplaceWithVecLib) into a call to a platform specific 
vector math function.  Instructions unsupported by ReplaceWithVecLib will 
return InstructionCost::getInvalid()."

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paul Walker via llvm-branch-commits


@@ -1031,6 +1032,22 @@ APInt llvm::possiblyDemandedEltsInMask(Value *Mask) {
   return DemandedElts;
 }
 
+InstructionCost
+llvm::getVecLibCallCost(const Instruction *I, const TargetTransformInfo *TTI,
+const TargetLibraryInfo *TLI, VectorType *VecTy,
+TargetTransformInfo::TargetCostKind CostKind) {
+  SmallVector OpTypes;
+  for (auto &Op : I->operands())
+OpTypes.push_back(Op->getType());

paulwalker-arm wrote:

Should this be `VecTy`? I'm assuming `I` can be a scalar instruction?

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paul Walker via llvm-branch-commits


@@ -8362,9 +8362,12 @@ BoUpSLP::getEntryCost(const TreeEntry *E, ArrayRef VectorizedVals,
   unsigned OpIdx = isa(VL0) ? 0 : 1;
   TTI::OperandValueInfo Op1Info = getOperandInfo(E->getOperand(0));
   TTI::OperandValueInfo Op2Info = getOperandInfo(E->getOperand(OpIdx));
-  return TTI->getArithmeticInstrCost(ShuffleOrOp, VecTy, CostKind, Op1Info,
- Op2Info) +
- CommonCost;
+  InstructionCost VecInstrCost = TTI->getArithmeticInstrCost(
+  ShuffleOrOp, VecTy, CostKind, Op1Info, Op2Info);
+  // Some targets can replace frem with vector library calls.
+  InstructionCost VecCallCost =
+  getVecLibCallCost(VL0, TTI, TLI, VecTy, CostKind);
+  return std::min(VecInstrCost, VecCallCost) + CommonCost;

paulwalker-arm wrote:

This seems a little arbitrary/complex given we know only one of the costs is 
valid at any time.  Perhaps it suggests you really want to implement 
`getVecLibAwareArithmeticInstrCost`?

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paul Walker via llvm-branch-commits


@@ -1031,6 +1032,22 @@ APInt llvm::possiblyDemandedEltsInMask(Value *Mask) {
   return DemandedElts;
 }
 
+InstructionCost
+llvm::getVecLibCallCost(const Instruction *I, const TargetTransformInfo *TTI,
+const TargetLibraryInfo *TLI, VectorType *VecTy,
+TargetTransformInfo::TargetCostKind CostKind) {
+  SmallVector OpTypes;
+  for (auto &Op : I->operands())
+OpTypes.push_back(Op->getType());
+
+  LibFunc Func;
+  if (TLI->getLibFunc(I->getOpcode(), I->getType(), Func) &&
+  TLI->isFunctionVectorizable(TLI->getName(Func), 
VecTy->getElementCount()))
+return TTI->getCallInstrCost(nullptr, VecTy, OpTypes, CostKind);
+
+  return InstructionCost::getInvalid();

paulwalker-arm wrote:

Given you've pulled this from LoopVectorize so the "hack" is easier to track I 
would rather you also update LoopVectorize to use it and thus verify existing 
behaviour is honoured.

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Alexey Bataev via llvm-branch-commits

alexey-bataev wrote:

> Personally I'm happy with keeping this nuance outside of TTI but if we really 
> want this captured within TTI then I think it's time to break FREM into its 
> own cost function (i.e. implement getFRemInstrCost. That way 
> getArithmeticInstrCost can work as it does today and the new function can be 
> documented to highlight it's assumption that if a TLI is passed in and a 
> vector mapping is present then the return value is only valid based on it's 
> assumption that vector FREM instructions will be transformed by a following 
> transformation pass. I prefer this to say, adding TLI to 
> getArithmeticInstrCost, because I'd rather users of getFRemInstrCost to 
> explicitly enter into this contract.

Hm, not sure adding getFRemInstrCost is the best solution here. I would more 
support adding TLI to getArithmeticInstrCost instead. Some other users may 
benefit from this too. Though getFRemInstrCost is still better than the current 
solution

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paul Walker via llvm-branch-commits

paulwalker-arm wrote:

Changing `getArithmeticInstrCost` is just too dangerous.  What if one opcode 
needs TLI for a different reason? all of a sudden all existing callers are 
entered into the contract (FREM is guaranteed to be transformed into a math 
call) without ensuring that's actually the case.

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Alexey Bataev via llvm-branch-commits

alexey-bataev wrote:

> Changing `getArithmeticInstrCost` is just too dangerous. What if one opcode 
> needs TLI for a different reason?

That should be fine, what's the dangerous in it?

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

2024-02-22 Thread Paschalis Mpeis via llvm-branch-commits

paschalis-mpeis wrote:

The benefits of having`getFRemInstrCost` in my view are the below:
1. frem is a special case anyway:
It's an IR instruction that is not supported by all hw and targets have to 
specialize.
Handling it in a dedicated switch case with a dedicated TTI function call, 
clearly exposes that information to anyone who reads the code in both 
vectorizers (and not obscuring it away). 
Plus it won't add any `if (TLI hasVecLib) doThis else doThat` logic to the 
vectorizers.

2. This won't be a significant API change.
It won't force any other user of the `getArithmeticInstrCost` to go through 
that change.

https://github.com/llvm/llvm-project/pull/82488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: [Loads] Fix crash in isSafeToLoadUnconditionally with scalable accessed type (#82650) (PR #82664)

2024-02-22 Thread via llvm-branch-commits

https://github.com/llvmbot created 
https://github.com/llvm/llvm-project/pull/82664

Backport b0edc1c45284586fdb12edd666f95d99f5f62b43

Requested by: @OMaghiarIMG

>From 5994086729d9c28d8ea4059871c39c022097dc6b Mon Sep 17 00:00:00 2001
From: Luke Lau 
Date: Fri, 23 Feb 2024 01:49:19 +0800
Subject: [PATCH] [Loads] Fix crash in isSafeToLoadUnconditionally with
 scalable accessed type (#82650)

This fixes #82606 by updating isSafeToLoadUnconditionally to handle
fixed sized loads from a scalable accessed type.

(cherry picked from commit b0edc1c45284586fdb12edd666f95d99f5f62b43)
---
 llvm/lib/Analysis/Loads.cpp   |  6 +++---
 .../VectorCombine/RISCV/load-widening.ll  | 19 +++
 2 files changed, 22 insertions(+), 3 deletions(-)
 create mode 100644 llvm/test/Transforms/VectorCombine/RISCV/load-widening.ll

diff --git a/llvm/lib/Analysis/Loads.cpp b/llvm/lib/Analysis/Loads.cpp
index 6bf0d2f56eb4eb..5916d2ab48ecec 100644
--- a/llvm/lib/Analysis/Loads.cpp
+++ b/llvm/lib/Analysis/Loads.cpp
@@ -364,7 +364,7 @@ bool llvm::isSafeToLoadUnconditionally(Value *V, Align 
Alignment, APInt &Size,
 
   if (Size.getBitWidth() > 64)
 return false;
-  const uint64_t LoadSize = Size.getZExtValue();
+  const TypeSize LoadSize = TypeSize::getFixed(Size.getZExtValue());
 
   // Otherwise, be a little bit aggressive by scanning the local block where we
   // want to check to see if the pointer is already being loaded or stored
@@ -414,11 +414,11 @@ bool llvm::isSafeToLoadUnconditionally(Value *V, Align 
Alignment, APInt &Size,
 
 // Handle trivial cases.
 if (AccessedPtr == V &&
-LoadSize <= DL.getTypeStoreSize(AccessedTy))
+TypeSize::isKnownLE(LoadSize, DL.getTypeStoreSize(AccessedTy)))
   return true;
 
 if (AreEquivalentAddressValues(AccessedPtr->stripPointerCasts(), V) &&
-LoadSize <= DL.getTypeStoreSize(AccessedTy))
+TypeSize::isKnownLE(LoadSize, DL.getTypeStoreSize(AccessedTy)))
   return true;
   }
   return false;
diff --git a/llvm/test/Transforms/VectorCombine/RISCV/load-widening.ll 
b/llvm/test/Transforms/VectorCombine/RISCV/load-widening.ll
new file mode 100644
index 00..0a43ad2f9a3684
--- /dev/null
+++ b/llvm/test/Transforms/VectorCombine/RISCV/load-widening.ll
@@ -0,0 +1,19 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py 
UTC_ARGS: --version 4
+; RUN: opt < %s -passes=vector-combine -S -mtriple=riscv32 -mattr=+v | 
FileCheck %s
+; RUN: opt < %s -passes=vector-combine -S -mtriple=riscv64 -mattr=+v | 
FileCheck %s
+
+define void @fixed_load_scalable_src(ptr %p) {
+; CHECK-LABEL: define void @fixed_load_scalable_src(
+; CHECK-SAME: ptr [[P:%.*]]) #[[ATTR0:[0-9]+]] {
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:store  zeroinitializer, ptr [[P]], align 8
+; CHECK-NEXT:[[TMP0:%.*]] = load <4 x i16>, ptr [[P]], align 8
+; CHECK-NEXT:[[TMP1:%.*]] = shufflevector <4 x i16> [[TMP0]], <4 x i16> 
zeroinitializer, <8 x i32> 
+; CHECK-NEXT:ret void
+;
+entry:
+  store  zeroinitializer, ptr %p
+  %0 = load <4 x i16>, ptr %p
+  %1 = shufflevector <4 x i16> %0, <4 x i16> zeroinitializer, <8 x i32> 
+  ret void
+}

___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: [Loads] Fix crash in isSafeToLoadUnconditionally with scalable accessed type (#82650) (PR #82664)

2024-02-22 Thread via llvm-branch-commits

https://github.com/llvmbot milestoned 
https://github.com/llvm/llvm-project/pull/82664
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: [Loads] Fix crash in isSafeToLoadUnconditionally with scalable accessed type (#82650) (PR #82664)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:

@lukel97 What do you think about merging this PR to the release branch?

https://github.com/llvm/llvm-project/pull/82664
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: [Loads] Fix crash in isSafeToLoadUnconditionally with scalable accessed type (#82650) (PR #82664)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:




@llvm/pr-subscribers-llvm-transforms

Author: None (llvmbot)


Changes

Backport b0edc1c45284586fdb12edd666f95d99f5f62b43

Requested by: @OMaghiarIMG

---
Full diff: https://github.com/llvm/llvm-project/pull/82664.diff


2 Files Affected:

- (modified) llvm/lib/Analysis/Loads.cpp (+3-3) 
- (added) llvm/test/Transforms/VectorCombine/RISCV/load-widening.ll (+19) 


``diff
diff --git a/llvm/lib/Analysis/Loads.cpp b/llvm/lib/Analysis/Loads.cpp
index 6bf0d2f56eb4eb..5916d2ab48ecec 100644
--- a/llvm/lib/Analysis/Loads.cpp
+++ b/llvm/lib/Analysis/Loads.cpp
@@ -364,7 +364,7 @@ bool llvm::isSafeToLoadUnconditionally(Value *V, Align 
Alignment, APInt &Size,
 
   if (Size.getBitWidth() > 64)
 return false;
-  const uint64_t LoadSize = Size.getZExtValue();
+  const TypeSize LoadSize = TypeSize::getFixed(Size.getZExtValue());
 
   // Otherwise, be a little bit aggressive by scanning the local block where we
   // want to check to see if the pointer is already being loaded or stored
@@ -414,11 +414,11 @@ bool llvm::isSafeToLoadUnconditionally(Value *V, Align 
Alignment, APInt &Size,
 
 // Handle trivial cases.
 if (AccessedPtr == V &&
-LoadSize <= DL.getTypeStoreSize(AccessedTy))
+TypeSize::isKnownLE(LoadSize, DL.getTypeStoreSize(AccessedTy)))
   return true;
 
 if (AreEquivalentAddressValues(AccessedPtr->stripPointerCasts(), V) &&
-LoadSize <= DL.getTypeStoreSize(AccessedTy))
+TypeSize::isKnownLE(LoadSize, DL.getTypeStoreSize(AccessedTy)))
   return true;
   }
   return false;
diff --git a/llvm/test/Transforms/VectorCombine/RISCV/load-widening.ll 
b/llvm/test/Transforms/VectorCombine/RISCV/load-widening.ll
new file mode 100644
index 00..0a43ad2f9a3684
--- /dev/null
+++ b/llvm/test/Transforms/VectorCombine/RISCV/load-widening.ll
@@ -0,0 +1,19 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py 
UTC_ARGS: --version 4
+; RUN: opt < %s -passes=vector-combine -S -mtriple=riscv32 -mattr=+v | 
FileCheck %s
+; RUN: opt < %s -passes=vector-combine -S -mtriple=riscv64 -mattr=+v | 
FileCheck %s
+
+define void @fixed_load_scalable_src(ptr %p) {
+; CHECK-LABEL: define void @fixed_load_scalable_src(
+; CHECK-SAME: ptr [[P:%.*]]) #[[ATTR0:[0-9]+]] {
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:store  zeroinitializer, ptr [[P]], align 8
+; CHECK-NEXT:[[TMP0:%.*]] = load <4 x i16>, ptr [[P]], align 8
+; CHECK-NEXT:[[TMP1:%.*]] = shufflevector <4 x i16> [[TMP0]], <4 x i16> 
zeroinitializer, <8 x i32> 
+; CHECK-NEXT:ret void
+;
+entry:
+  store  zeroinitializer, ptr %p
+  %0 = load <4 x i16>, ptr %p
+  %1 = shufflevector <4 x i16> %0, <4 x i16> zeroinitializer, <8 x i32> 
+  ret void
+}

``




https://github.com/llvm/llvm-project/pull/82664
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] [llvm] release/18.x: [AArch64] Backport Ampere1B support (#81297 , #81341, and #81744) (PR #81857)

2024-02-22 Thread Tom Stellard via llvm-branch-commits

tstellar wrote:

> On a different note: the "+pauth" fix would be helpful in clang-18 as well, 
> given that it brings the definition of "-march=armv8.3-a" in sync with the 
> specification.

OK, so sounds like the +pauth change is separate but included in this PR for 
convenience.

https://github.com/llvm/llvm-project/pull/81857
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] [llvm] release/18.x: [AArch64] Backport Ampere1B support (#81297 , #81341, and #81744) (PR #81857)

2024-02-22 Thread Philipp Tomsich via llvm-branch-commits

ptomsich wrote:

> > On a different note: the "+pauth" fix would be helpful in clang-18 as well, 
> > given that it brings the definition of "-march=armv8.3-a" in sync with the 
> > specification.
> 
> OK, so sounds like the +pauth change is separate but included in this PR for 
> convenience.

@tstellar The +pauth change was included to allow a straight cherry-pick of the 
Ampere1B changes.  Without, we need to modify one patch (or'ing in the PAUTH 
bit) from what was committed onto main.

https://github.com/llvm/llvm-project/pull/81857
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [scudo] Allow to resize allocation ring buffer (PR #82683)

2024-02-22 Thread Florian Mayer via llvm-branch-commits

https://github.com/fmayer created 
https://github.com/llvm/llvm-project/pull/82683

None


___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [scudo] Allow to resize allocation ring buffer (PR #82683)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:




@llvm/pr-subscribers-compiler-rt-sanitizer

Author: Florian Mayer (fmayer)


Changes



---
Full diff: https://github.com/llvm/llvm-project/pull/82683.diff


4 Files Affected:

- (modified) compiler-rt/lib/scudo/standalone/combined.h (+34-10) 
- (modified) compiler-rt/lib/scudo/standalone/include/scudo/interface.h (+2) 
- (modified) compiler-rt/lib/scudo/standalone/tests/combined_test.cpp (+27) 
- (modified) compiler-rt/lib/scudo/standalone/wrappers_c_bionic.cpp (+4) 


``diff
diff --git a/compiler-rt/lib/scudo/standalone/combined.h 
b/compiler-rt/lib/scudo/standalone/combined.h
index 79b5891fd35869..479e49c328e3d7 100644
--- a/compiler-rt/lib/scudo/standalone/combined.h
+++ b/compiler-rt/lib/scudo/standalone/combined.h
@@ -174,9 +174,11 @@ class Allocator {
 static_cast(getFlags()->quarantine_size_kb << 10),
 static_cast(getFlags()->thread_local_quarantine_size_kb << 10));
 
-mapAndInitializeRingBuffer();
+mapAndInitializeRingBuffer(getFlags()->allocation_ring_buffer_size);
   }
 
+  bool resizeRingBuffer(int Size) { return mapAndInitializeRingBuffer(Size); }
+
   // Initialize the embedded GWP-ASan instance. Requires the main allocator to
   // be functional, best called from PostInitCallback.
   void initGwpAsan() {
@@ -1531,11 +1533,15 @@ class Allocator {
 RBEntryStart)[N];
   }
 
-  void mapAndInitializeRingBuffer() {
-if (getFlags()->allocation_ring_buffer_size <= 0)
-  return;
-u32 AllocationRingBufferSize =
-static_cast(getFlags()->allocation_ring_buffer_size);
+  bool mapAndInitializeRingBuffer(int RingBufferSize) {
+if (RingBufferSize < 0 ||
+static_cast(RingBufferSize) >= UINT32_MAX)
+  return false;
+if (RingBufferSize == 0) {
+  swapOutRingBuffer(nullptr);
+  return true;
+}
+u32 AllocationRingBufferSize = static_cast(RingBufferSize);
 
 // We store alloc and free stacks for each entry.
 constexpr u32 kStacksPerRingBufferEntry = 2;
@@ -1555,11 +1561,11 @@ class Allocator {
   UINTPTR_MAX);
 
 if (AllocationRingBufferSize > kMaxU32Pow2 / kStacksPerRingBufferEntry)
-  return;
+  return false;
 u32 TabSize = static_cast(roundUpPowerOfTwo(kStacksPerRingBufferEntry 
*
  
AllocationRingBufferSize));
 if (TabSize > UINT32_MAX / kFramesPerStack)
-  return;
+  return false;
 u32 RingSize = static_cast(TabSize * kFramesPerStack);
 DCHECK(isPowerOfTwo(RingSize));
 
@@ -1585,12 +1591,30 @@ class Allocator {
 RB->StackDepotSize = StackDepotSize;
 RB->RawStackDepotMap = DepotMap;
 
-atomic_store(&RingBufferAddress, reinterpret_cast(RB),
- memory_order_release);
+swapOutRingBuffer(RB);
 static_assert(sizeof(AllocationRingBuffer) %
   alignof(typename AllocationRingBuffer::Entry) ==
   0,
   "invalid alignment");
+return true;
+  }
+
+  void swapOutRingBuffer(AllocationRingBuffer *NewRB) {
+AllocationRingBuffer *PrevRB = reinterpret_cast(
+atomic_exchange(&RingBufferAddress, reinterpret_cast(NewRB),
+memory_order_acq_rel));
+if (PrevRB) {
+  auto RawStackDepotMap = PrevRB->RawStackDepotMap;
+  if (RawStackDepotMap.isAllocated()) {
+RawStackDepotMap.releaseAndZeroPagesToOS(
+RawStackDepotMap.getBase(), RawStackDepotMap.getCapacity());
+  }
+  auto RawRingBufferMap = PrevRB->RawRingBufferMap;
+  if (RawRingBufferMap.isAllocated()) {
+RawRingBufferMap.releaseAndZeroPagesToOS(
+RawRingBufferMap.getBase(), RawRingBufferMap.getCapacity());
+  }
+}
   }
 
   void unmapRingBuffer() {
diff --git a/compiler-rt/lib/scudo/standalone/include/scudo/interface.h 
b/compiler-rt/lib/scudo/standalone/include/scudo/interface.h
index a2dedea910cc08..8aca56b7172d9f 100644
--- a/compiler-rt/lib/scudo/standalone/include/scudo/interface.h
+++ b/compiler-rt/lib/scudo/standalone/include/scudo/interface.h
@@ -123,6 +123,8 @@ size_t __scudo_get_region_info_size(void);
 const char *__scudo_get_ring_buffer_addr(void);
 size_t __scudo_get_ring_buffer_size(void);
 
+bool __scudo_resize_ring_buffer(int);
+
 #ifndef M_DECAY_TIME
 #define M_DECAY_TIME -100
 #endif
diff --git a/compiler-rt/lib/scudo/standalone/tests/combined_test.cpp 
b/compiler-rt/lib/scudo/standalone/tests/combined_test.cpp
index 13d627b116809b..7e7a0e59cfe6d0 100644
--- a/compiler-rt/lib/scudo/standalone/tests/combined_test.cpp
+++ b/compiler-rt/lib/scudo/standalone/tests/combined_test.cpp
@@ -915,6 +915,33 @@ SCUDO_TYPED_TEST(ScudoCombinedTest, StackDepot) {
   EXPECT_EQ(Depot->at(RingPosPtr + 2), 3u);
 }
 
+SCUDO_TYPED_TEST(ScudoCombinedTest, ResizeRingBuffer) {
+  auto *Allocator = this->Allocator.get();
+  auto Size = static_cast(Allocator->getRingBufferSize());
+  auto DepotSize = Allocator->getStackDepotSize();
+  ASSERT_GT(Size, 0);
+  ASSE

[llvm-branch-commits] [compiler-rt] [scudo] Allow to resize allocation ring buffer (PR #82683)

2024-02-22 Thread Florian Mayer via llvm-branch-commits

https://github.com/fmayer updated 
https://github.com/llvm/llvm-project/pull/82683

>From af8afe08ee20a04b2ccb363cac66aa02cfaecd02 Mon Sep 17 00:00:00 2001
From: Florian Mayer 
Date: Thu, 22 Feb 2024 12:37:06 -0800
Subject: [PATCH] update message

Created using spr 1.3.4
---
 compiler-rt/lib/scudo/standalone/combined.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/compiler-rt/lib/scudo/standalone/combined.h 
b/compiler-rt/lib/scudo/standalone/combined.h
index 479e49c328e3d7..24ad979a9653e1 100644
--- a/compiler-rt/lib/scudo/standalone/combined.h
+++ b/compiler-rt/lib/scudo/standalone/combined.h
@@ -1600,6 +1600,9 @@ class Allocator {
   }
 
   void swapOutRingBuffer(AllocationRingBuffer *NewRB) {
+// To allow resizeRingBuffer to be called in a multi-threaded context by 
apps,
+// we do not actually unmap, but only madvise(DONTNEED) the pages. That 
way,
+// straggler threads will not crash.
 AllocationRingBuffer *PrevRB = reinterpret_cast(
 atomic_exchange(&RingBufferAddress, reinterpret_cast(NewRB),
 memory_order_acq_rel));

___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [compiler-rt] [scudo] Allow to resize allocation ring buffer (PR #82683)

2024-02-22 Thread Florian Mayer via llvm-branch-commits

https://github.com/fmayer edited https://github.com/llvm/llvm-project/pull/82683
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: Extend GCC workaround to GCC < 8.4 for llvm::iterator_range ctor (#82643) (PR #82688)

2024-02-22 Thread via llvm-branch-commits

https://github.com/llvmbot created 
https://github.com/llvm/llvm-project/pull/82688

Backport 7f71fa909a10be182b82b9dfaf0fade6eb84796c

Requested by: @RoboTux

>From b9029ed0053b93d94e0f133e6a44250f82bf0dc2 Mon Sep 17 00:00:00 2001
From: Thomas Preud'homme 
Date: Thu, 22 Feb 2024 21:01:05 +
Subject: [PATCH] Extend GCC workaround to GCC < 8.4 for llvm::iterator_range
 ctor (#82643)

GCC SFINAE error with decltype was fixed in commit
ac5e28911abdfb8d9bf6bea980223e199bbcf28d which made it into GCC 8.4.
Therefore adjust GCC version test accordingly.

(cherry picked from commit 7f71fa909a10be182b82b9dfaf0fade6eb84796c)
---
 llvm/include/llvm/ADT/iterator_range.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/llvm/include/llvm/ADT/iterator_range.h 
b/llvm/include/llvm/ADT/iterator_range.h
index 2dc227935984b1..7d288ea4506ba5 100644
--- a/llvm/include/llvm/ADT/iterator_range.h
+++ b/llvm/include/llvm/ADT/iterator_range.h
@@ -43,8 +43,8 @@ class iterator_range {
   IteratorT begin_iterator, end_iterator;
 
 public:
-#if __GNUC__ == 7
-  // Be careful no to break gcc-7 on the mlir target.
+#if __GNUC__ == 7 || (__GNUC__ == 8 && __GNUC_MINOR__ < 4)
+  // Be careful no to break gcc-7 and gcc-8 < 8.4 on the mlir target.
   // See https://github.com/llvm/llvm-project/issues/63843
   template 
 #else

___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: Extend GCC workaround to GCC < 8.4 for llvm::iterator_range ctor (#82643) (PR #82688)

2024-02-22 Thread via llvm-branch-commits

https://github.com/llvmbot milestoned 
https://github.com/llvm/llvm-project/pull/82688
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: Extend GCC workaround to GCC < 8.4 for llvm::iterator_range ctor (#82643) (PR #82688)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:

@MaskRay What do you think about merging this PR to the release branch?

https://github.com/llvm/llvm-project/pull/82688
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: Extend GCC workaround to GCC < 8.4 for llvm::iterator_range ctor (#82643) (PR #82688)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:




@llvm/pr-subscribers-llvm-adt

Author: None (llvmbot)


Changes

Backport 7f71fa909a10be182b82b9dfaf0fade6eb84796c

Requested by: @RoboTux

---
Full diff: https://github.com/llvm/llvm-project/pull/82688.diff


1 Files Affected:

- (modified) llvm/include/llvm/ADT/iterator_range.h (+2-2) 


``diff
diff --git a/llvm/include/llvm/ADT/iterator_range.h 
b/llvm/include/llvm/ADT/iterator_range.h
index 2dc227935984b1..7d288ea4506ba5 100644
--- a/llvm/include/llvm/ADT/iterator_range.h
+++ b/llvm/include/llvm/ADT/iterator_range.h
@@ -43,8 +43,8 @@ class iterator_range {
   IteratorT begin_iterator, end_iterator;
 
 public:
-#if __GNUC__ == 7
-  // Be careful no to break gcc-7 on the mlir target.
+#if __GNUC__ == 7 || (__GNUC__ == 8 && __GNUC_MINOR__ < 4)
+  // Be careful no to break gcc-7 and gcc-8 < 8.4 on the mlir target.
   // See https://github.com/llvm/llvm-project/issues/63843
   template 
 #else

``




https://github.com/llvm/llvm-project/pull/82688
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: Extend GCC workaround to GCC < 8.4 for llvm::iterator_range ctor (#82643) (PR #82688)

2024-02-22 Thread Fangrui Song via llvm-branch-commits

https://github.com/MaskRay approved this pull request.


https://github.com/llvm/llvm-project/pull/82688
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82693)

2024-02-22 Thread via llvm-branch-commits

https://github.com/llvmbot milestoned 
https://github.com/llvm/llvm-project/pull/82693
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82693)

2024-02-22 Thread via llvm-branch-commits

https://github.com/llvmbot created 
https://github.com/llvm/llvm-project/pull/82693

Backport 26d71d9ed56c4c23e6284dac7a9bdf603a5801f3

Requested by: @brad0

>From 6ab419cea064195460c56a9e38e05fc25b8dc8c9 Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Thu, 22 Feb 2024 09:24:21 -0800
Subject: [PATCH] [llvm-readobj,ELF] Support --decompress/-z (#82594)

When a section has the SHF_COMPRESSED flag, -p/-x dump the compressed
content by default. In GNU readelf, if --decompress/-z is specified,
-p/-x will dump the decompressed content. This patch implements the
option.

Close #82507

(cherry picked from commit 26d71d9ed56c4c23e6284dac7a9bdf603a5801f3)
---
 llvm/docs/CommandGuide/llvm-readelf.rst   |  5 ++
 llvm/docs/CommandGuide/llvm-readobj.rst   |  5 ++
 .../ELF/decompress-zlib-unsupported.test  | 32 
 .../llvm-readobj/ELF/decompress-zlib.test | 76 +++
 .../ELF/decompress-zstd-unsupported.test  | 31 
 .../llvm-readobj/ELF/decompress-zstd.test | 28 +++
 llvm/tools/llvm-readobj/ObjDumper.cpp | 26 ++-
 llvm/tools/llvm-readobj/ObjDumper.h   |  4 +-
 llvm/tools/llvm-readobj/Opts.td   |  2 +
 llvm/tools/llvm-readobj/llvm-readobj.cpp  |  6 +-
 10 files changed, 209 insertions(+), 6 deletions(-)
 create mode 100644 
llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
 create mode 100644 llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
 create mode 100644 
llvm/test/tools/llvm-readobj/ELF/decompress-zstd-unsupported.test
 create mode 100644 llvm/test/tools/llvm-readobj/ELF/decompress-zstd.test

diff --git a/llvm/docs/CommandGuide/llvm-readelf.rst 
b/llvm/docs/CommandGuide/llvm-readelf.rst
index 6ee4a5dfb15917..675628fdda45ec 100644
--- a/llvm/docs/CommandGuide/llvm-readelf.rst
+++ b/llvm/docs/CommandGuide/llvm-readelf.rst
@@ -38,6 +38,11 @@ OPTIONS
  Display the contents of the basic block address map section(s), which contain 
the
  address of each function, along with the relative offset of each basic block.
 
+.. option:: --decompress, -z
+
+  Dump decompressed section content when used with ``-x`` or ``-p``.
+  If the section(s) are not compressed, they are displayed as is.
+
 .. option:: --demangle, -C
 
  Display demangled symbol names in the output.
diff --git a/llvm/docs/CommandGuide/llvm-readobj.rst 
b/llvm/docs/CommandGuide/llvm-readobj.rst
index cb9232ef5e560a..6d78a038723445 100644
--- a/llvm/docs/CommandGuide/llvm-readobj.rst
+++ b/llvm/docs/CommandGuide/llvm-readobj.rst
@@ -56,6 +56,11 @@ file formats.
 
  Display the address-significance table.
 
+.. option:: --decompress, -z
+
+  Dump decompressed section content when used with ``-x`` or ``-p``.
+  If the section(s) are not compressed, they are displayed as is.
+
 .. option:: --expand-relocs
 
  When used with :option:`--relocs`, display each relocation in an expanded
diff --git a/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test 
b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
new file mode 100644
index 00..f4c73de7ca6c9d
--- /dev/null
+++ b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
@@ -0,0 +1,32 @@
+# UNSUPPORTED: zlib
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-readobj -z -p .a -x .b %t 2>&1 | FileCheck %s -DFILE=%t
+
+# CHECK:  String dump of section '.a':
+# CHECK-NEXT: warning: '[[FILE]]': LLVM was not built with LLVM_ENABLE_ZLIB or 
did not find zlib at build time
+# CHECK-NEXT: [ 0] .
+# CHECK-NEXT: [ 8] .
+# CHECK-NEXT: [10] .
+# CHECK-NEXT: [18] x.c.
+# CHECK-NEXT: [1e] .
+# CHECK-NEXT: [20] .
+# CHECK-NEXT: Hex dump of section '.b':
+# CHECK-NEXT: warning: '[[FILE]]': LLVM was not built with LLVM_ENABLE_ZLIB or 
did not find zlib at build time
+# CHECK-NEXT: 0x 0100  0100  
+# CHECK-NEXT: 0x0010 0100  789c6304 0200 x.c.
+# CHECK-NEXT: 0x0020 02  .
+
+--- !ELF
+FileHeader:
+  Class: ELFCLASS64
+  Data:  ELFDATA2LSB
+  Type:  ET_REL
+Sections:
+  - Name: .a
+Type: SHT_PROGBITS
+Flags: [SHF_COMPRESSED]
+Content: 010001000100789c6304020002
+  - Name: .b
+Type: SHT_PROGBITS
+Flags: [SHF_COMPRESSED]
+Content: 010001000100789c6304020002
diff --git a/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test 
b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
new file mode 100644
index 00..ea7a8854eb1a0c
--- /dev/null
+++ b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
@@ -0,0 +1,76 @@
+# REQUIRES: zlib
+## Test --decompress/-z.
+
+# RUN: yaml2obj %s -o %t
+
+# RUN: llvm-readelf -z -x .strings -x .not_null_terminated %t | FileCheck %s 
--check-prefix=HEX
+# RUN: llvm-readobj --decompress -p .strings -p .not_null_terminated %t | 
FileCheck %s --check-prefix=STR
+
+# HEX:  Hex dump of section '.strings'

[llvm-branch-commits] [llvm] release/18.x: [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82693)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:

@emaste What do you think about merging this PR to the release branch?

https://github.com/llvm/llvm-project/pull/82693
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82693)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:




@llvm/pr-subscribers-llvm-binary-utilities

Author: None (llvmbot)


Changes

Backport 26d71d9ed56c4c23e6284dac7a9bdf603a5801f3

Requested by: @brad0

---
Full diff: https://github.com/llvm/llvm-project/pull/82693.diff


10 Files Affected:

- (modified) llvm/docs/CommandGuide/llvm-readelf.rst (+5) 
- (modified) llvm/docs/CommandGuide/llvm-readobj.rst (+5) 
- (added) llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test 
(+32) 
- (added) llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test (+76) 
- (added) llvm/test/tools/llvm-readobj/ELF/decompress-zstd-unsupported.test 
(+31) 
- (added) llvm/test/tools/llvm-readobj/ELF/decompress-zstd.test (+28) 
- (modified) llvm/tools/llvm-readobj/ObjDumper.cpp (+24-2) 
- (modified) llvm/tools/llvm-readobj/ObjDumper.h (+2-2) 
- (modified) llvm/tools/llvm-readobj/Opts.td (+2) 
- (modified) llvm/tools/llvm-readobj/llvm-readobj.cpp (+4-2) 


``diff
diff --git a/llvm/docs/CommandGuide/llvm-readelf.rst 
b/llvm/docs/CommandGuide/llvm-readelf.rst
index 6ee4a5dfb15917..675628fdda45ec 100644
--- a/llvm/docs/CommandGuide/llvm-readelf.rst
+++ b/llvm/docs/CommandGuide/llvm-readelf.rst
@@ -38,6 +38,11 @@ OPTIONS
  Display the contents of the basic block address map section(s), which contain 
the
  address of each function, along with the relative offset of each basic block.
 
+.. option:: --decompress, -z
+
+  Dump decompressed section content when used with ``-x`` or ``-p``.
+  If the section(s) are not compressed, they are displayed as is.
+
 .. option:: --demangle, -C
 
  Display demangled symbol names in the output.
diff --git a/llvm/docs/CommandGuide/llvm-readobj.rst 
b/llvm/docs/CommandGuide/llvm-readobj.rst
index cb9232ef5e560a..6d78a038723445 100644
--- a/llvm/docs/CommandGuide/llvm-readobj.rst
+++ b/llvm/docs/CommandGuide/llvm-readobj.rst
@@ -56,6 +56,11 @@ file formats.
 
  Display the address-significance table.
 
+.. option:: --decompress, -z
+
+  Dump decompressed section content when used with ``-x`` or ``-p``.
+  If the section(s) are not compressed, they are displayed as is.
+
 .. option:: --expand-relocs
 
  When used with :option:`--relocs`, display each relocation in an expanded
diff --git a/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test 
b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
new file mode 100644
index 00..f4c73de7ca6c9d
--- /dev/null
+++ b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
@@ -0,0 +1,32 @@
+# UNSUPPORTED: zlib
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-readobj -z -p .a -x .b %t 2>&1 | FileCheck %s -DFILE=%t
+
+# CHECK:  String dump of section '.a':
+# CHECK-NEXT: warning: '[[FILE]]': LLVM was not built with LLVM_ENABLE_ZLIB or 
did not find zlib at build time
+# CHECK-NEXT: [ 0] .
+# CHECK-NEXT: [ 8] .
+# CHECK-NEXT: [10] .
+# CHECK-NEXT: [18] x.c.
+# CHECK-NEXT: [1e] .
+# CHECK-NEXT: [20] .
+# CHECK-NEXT: Hex dump of section '.b':
+# CHECK-NEXT: warning: '[[FILE]]': LLVM was not built with LLVM_ENABLE_ZLIB or 
did not find zlib at build time
+# CHECK-NEXT: 0x 0100  0100  
+# CHECK-NEXT: 0x0010 0100  789c6304 0200 x.c.
+# CHECK-NEXT: 0x0020 02  .
+
+--- !ELF
+FileHeader:
+  Class: ELFCLASS64
+  Data:  ELFDATA2LSB
+  Type:  ET_REL
+Sections:
+  - Name: .a
+Type: SHT_PROGBITS
+Flags: [SHF_COMPRESSED]
+Content: 010001000100789c6304020002
+  - Name: .b
+Type: SHT_PROGBITS
+Flags: [SHF_COMPRESSED]
+Content: 010001000100789c6304020002
diff --git a/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test 
b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
new file mode 100644
index 00..ea7a8854eb1a0c
--- /dev/null
+++ b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
@@ -0,0 +1,76 @@
+# REQUIRES: zlib
+## Test --decompress/-z.
+
+# RUN: yaml2obj %s -o %t
+
+# RUN: llvm-readelf -z -x .strings -x .not_null_terminated %t | FileCheck %s 
--check-prefix=HEX
+# RUN: llvm-readobj --decompress -p .strings -p .not_null_terminated %t | 
FileCheck %s --check-prefix=STR
+
+# HEX:  Hex dump of section '.strings':
+# HEX-NEXT: 0x 68657265 00617265 00736f6d 65007374 here.are.some.st
+# HEX-NEXT: 0x0010 72696e67 7300   rings.
+# HEX:  Hex dump of section '.not_null_terminated':
+# HEX-NEXT: 0x 6e6f006e 756c6c no.null
+
+# STR:  String dump of section '.strings':
+# STR-NEXT: [ 0] here
+# STR-NEXT: [ 5] are
+# STR-NEXT: [ 9] some
+# STR-NEXT: [ e] strings
+# STR-EMPTY:
+# STR-NEXT: String dump of section '.not_null_terminated':
+# STR-NEXT: [ 0] no
+# STR-NEXT: [ 3] null{{$}}
+# STR-NOT:  {{.}}
+
+# RUN: llvm-readobj -x .strings -p .not_null_terminated %t | FileCheck %s 
--check-prefix=COMPRESSED
+
+# COMPRESSED:  String 

[llvm-branch-commits] [llvm] [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82713)

2024-02-22 Thread Brad Smith via llvm-branch-commits

https://github.com/brad0 milestoned 
https://github.com/llvm/llvm-project/pull/82713
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82713)

2024-02-22 Thread Brad Smith via llvm-branch-commits

https://github.com/brad0 created https://github.com/llvm/llvm-project/pull/82713

When a section has the SHF_COMPRESSED flag, -p/-x dump the compressed
content by default. In GNU readelf, if --decompress/-z is specified,
-p/-x will dump the decompressed content. This patch implements the
option.

Close #82507

(cherry picked from commit 26d71d9ed56c4c23e6284dac7a9bdf603a5801f3)

>From 0a534697de043d57fbc3c37591ee603b994e2606 Mon Sep 17 00:00:00 2001
From: Brad Smith 
Date: Thu, 22 Feb 2024 19:20:28 -0500
Subject: [PATCH] [llvm-readobj,ELF] Support --decompress/-z (#82594)

When a section has the SHF_COMPRESSED flag, -p/-x dump the compressed
content by default. In GNU readelf, if --decompress/-z is specified,
-p/-x will dump the decompressed content. This patch implements the
option.

Close #82507

(cherry picked from commit 26d71d9ed56c4c23e6284dac7a9bdf603a5801f3)
---
 llvm/docs/CommandGuide/llvm-readelf.rst   |  5 ++
 llvm/docs/CommandGuide/llvm-readobj.rst   |  5 ++
 .../ELF/decompress-zlib-unsupported.test  | 32 
 .../llvm-readobj/ELF/decompress-zlib.test | 76 +++
 .../ELF/decompress-zstd-unsupported.test  | 31 
 .../llvm-readobj/ELF/decompress-zstd.test | 28 +++
 llvm/tools/llvm-readobj/ObjDumper.cpp | 26 ++-
 llvm/tools/llvm-readobj/ObjDumper.h   |  4 +-
 llvm/tools/llvm-readobj/Opts.td   |  2 +
 llvm/tools/llvm-readobj/llvm-readobj.cpp  |  6 +-
 10 files changed, 209 insertions(+), 6 deletions(-)
 create mode 100644 
llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
 create mode 100644 llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
 create mode 100644 
llvm/test/tools/llvm-readobj/ELF/decompress-zstd-unsupported.test
 create mode 100644 llvm/test/tools/llvm-readobj/ELF/decompress-zstd.test

diff --git a/llvm/docs/CommandGuide/llvm-readelf.rst 
b/llvm/docs/CommandGuide/llvm-readelf.rst
index 6ee4a5dfb15917..675628fdda45ec 100644
--- a/llvm/docs/CommandGuide/llvm-readelf.rst
+++ b/llvm/docs/CommandGuide/llvm-readelf.rst
@@ -38,6 +38,11 @@ OPTIONS
  Display the contents of the basic block address map section(s), which contain 
the
  address of each function, along with the relative offset of each basic block.
 
+.. option:: --decompress, -z
+
+  Dump decompressed section content when used with ``-x`` or ``-p``.
+  If the section(s) are not compressed, they are displayed as is.
+
 .. option:: --demangle, -C
 
  Display demangled symbol names in the output.
diff --git a/llvm/docs/CommandGuide/llvm-readobj.rst 
b/llvm/docs/CommandGuide/llvm-readobj.rst
index cb9232ef5e560a..6d78a038723445 100644
--- a/llvm/docs/CommandGuide/llvm-readobj.rst
+++ b/llvm/docs/CommandGuide/llvm-readobj.rst
@@ -56,6 +56,11 @@ file formats.
 
  Display the address-significance table.
 
+.. option:: --decompress, -z
+
+  Dump decompressed section content when used with ``-x`` or ``-p``.
+  If the section(s) are not compressed, they are displayed as is.
+
 .. option:: --expand-relocs
 
  When used with :option:`--relocs`, display each relocation in an expanded
diff --git a/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test 
b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
new file mode 100644
index 00..f4c73de7ca6c9d
--- /dev/null
+++ b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
@@ -0,0 +1,32 @@
+# UNSUPPORTED: zlib
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-readobj -z -p .a -x .b %t 2>&1 | FileCheck %s -DFILE=%t
+
+# CHECK:  String dump of section '.a':
+# CHECK-NEXT: warning: '[[FILE]]': LLVM was not built with LLVM_ENABLE_ZLIB or 
did not find zlib at build time
+# CHECK-NEXT: [ 0] .
+# CHECK-NEXT: [ 8] .
+# CHECK-NEXT: [10] .
+# CHECK-NEXT: [18] x.c.
+# CHECK-NEXT: [1e] .
+# CHECK-NEXT: [20] .
+# CHECK-NEXT: Hex dump of section '.b':
+# CHECK-NEXT: warning: '[[FILE]]': LLVM was not built with LLVM_ENABLE_ZLIB or 
did not find zlib at build time
+# CHECK-NEXT: 0x 0100  0100  
+# CHECK-NEXT: 0x0010 0100  789c6304 0200 x.c.
+# CHECK-NEXT: 0x0020 02  .
+
+--- !ELF
+FileHeader:
+  Class: ELFCLASS64
+  Data:  ELFDATA2LSB
+  Type:  ET_REL
+Sections:
+  - Name: .a
+Type: SHT_PROGBITS
+Flags: [SHF_COMPRESSED]
+Content: 010001000100789c6304020002
+  - Name: .b
+Type: SHT_PROGBITS
+Flags: [SHF_COMPRESSED]
+Content: 010001000100789c6304020002
diff --git a/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test 
b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
new file mode 100644
index 00..ea7a8854eb1a0c
--- /dev/null
+++ b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
@@ -0,0 +1,76 @@
+# REQUIRES: zlib
+## Test --decompress/-z.
+
+# RUN: yaml2obj %s -o %t
+
+# RUN: llvm-readelf -z -x .s

[llvm-branch-commits] [llvm] [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82713)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:




@llvm/pr-subscribers-llvm-binary-utilities

Author: Brad Smith (brad0)


Changes

When a section has the SHF_COMPRESSED flag, -p/-x dump the compressed
content by default. In GNU readelf, if --decompress/-z is specified,
-p/-x will dump the decompressed content. This patch implements the
option.

Close #82507

(cherry picked from commit 26d71d9ed56c4c23e6284dac7a9bdf603a5801f3)

---
Full diff: https://github.com/llvm/llvm-project/pull/82713.diff


10 Files Affected:

- (modified) llvm/docs/CommandGuide/llvm-readelf.rst (+5) 
- (modified) llvm/docs/CommandGuide/llvm-readobj.rst (+5) 
- (added) llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test 
(+32) 
- (added) llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test (+76) 
- (added) llvm/test/tools/llvm-readobj/ELF/decompress-zstd-unsupported.test 
(+31) 
- (added) llvm/test/tools/llvm-readobj/ELF/decompress-zstd.test (+28) 
- (modified) llvm/tools/llvm-readobj/ObjDumper.cpp (+24-2) 
- (modified) llvm/tools/llvm-readobj/ObjDumper.h (+2-2) 
- (modified) llvm/tools/llvm-readobj/Opts.td (+2) 
- (modified) llvm/tools/llvm-readobj/llvm-readobj.cpp (+4-2) 


``diff
diff --git a/llvm/docs/CommandGuide/llvm-readelf.rst 
b/llvm/docs/CommandGuide/llvm-readelf.rst
index 6ee4a5dfb15917..675628fdda45ec 100644
--- a/llvm/docs/CommandGuide/llvm-readelf.rst
+++ b/llvm/docs/CommandGuide/llvm-readelf.rst
@@ -38,6 +38,11 @@ OPTIONS
  Display the contents of the basic block address map section(s), which contain 
the
  address of each function, along with the relative offset of each basic block.
 
+.. option:: --decompress, -z
+
+  Dump decompressed section content when used with ``-x`` or ``-p``.
+  If the section(s) are not compressed, they are displayed as is.
+
 .. option:: --demangle, -C
 
  Display demangled symbol names in the output.
diff --git a/llvm/docs/CommandGuide/llvm-readobj.rst 
b/llvm/docs/CommandGuide/llvm-readobj.rst
index cb9232ef5e560a..6d78a038723445 100644
--- a/llvm/docs/CommandGuide/llvm-readobj.rst
+++ b/llvm/docs/CommandGuide/llvm-readobj.rst
@@ -56,6 +56,11 @@ file formats.
 
  Display the address-significance table.
 
+.. option:: --decompress, -z
+
+  Dump decompressed section content when used with ``-x`` or ``-p``.
+  If the section(s) are not compressed, they are displayed as is.
+
 .. option:: --expand-relocs
 
  When used with :option:`--relocs`, display each relocation in an expanded
diff --git a/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test 
b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
new file mode 100644
index 00..f4c73de7ca6c9d
--- /dev/null
+++ b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
@@ -0,0 +1,32 @@
+# UNSUPPORTED: zlib
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-readobj -z -p .a -x .b %t 2>&1 | FileCheck %s -DFILE=%t
+
+# CHECK:  String dump of section '.a':
+# CHECK-NEXT: warning: '[[FILE]]': LLVM was not built with LLVM_ENABLE_ZLIB or 
did not find zlib at build time
+# CHECK-NEXT: [ 0] .
+# CHECK-NEXT: [ 8] .
+# CHECK-NEXT: [10] .
+# CHECK-NEXT: [18] x.c.
+# CHECK-NEXT: [1e] .
+# CHECK-NEXT: [20] .
+# CHECK-NEXT: Hex dump of section '.b':
+# CHECK-NEXT: warning: '[[FILE]]': LLVM was not built with LLVM_ENABLE_ZLIB or 
did not find zlib at build time
+# CHECK-NEXT: 0x 0100  0100  
+# CHECK-NEXT: 0x0010 0100  789c6304 0200 x.c.
+# CHECK-NEXT: 0x0020 02  .
+
+--- !ELF
+FileHeader:
+  Class: ELFCLASS64
+  Data:  ELFDATA2LSB
+  Type:  ET_REL
+Sections:
+  - Name: .a
+Type: SHT_PROGBITS
+Flags: [SHF_COMPRESSED]
+Content: 010001000100789c6304020002
+  - Name: .b
+Type: SHT_PROGBITS
+Flags: [SHF_COMPRESSED]
+Content: 010001000100789c6304020002
diff --git a/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test 
b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
new file mode 100644
index 00..ea7a8854eb1a0c
--- /dev/null
+++ b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
@@ -0,0 +1,76 @@
+# REQUIRES: zlib
+## Test --decompress/-z.
+
+# RUN: yaml2obj %s -o %t
+
+# RUN: llvm-readelf -z -x .strings -x .not_null_terminated %t | FileCheck %s 
--check-prefix=HEX
+# RUN: llvm-readobj --decompress -p .strings -p .not_null_terminated %t | 
FileCheck %s --check-prefix=STR
+
+# HEX:  Hex dump of section '.strings':
+# HEX-NEXT: 0x 68657265 00617265 00736f6d 65007374 here.are.some.st
+# HEX-NEXT: 0x0010 72696e67 7300   rings.
+# HEX:  Hex dump of section '.not_null_terminated':
+# HEX-NEXT: 0x 6e6f006e 756c6c no.null
+
+# STR:  String dump of section '.strings':
+# STR-NEXT: [ 0] here
+# STR-NEXT: [ 5] are
+# STR-NEXT: [ 9] some
+# STR-NEXT: [ e] strings
+# STR-EMPTY:
+# STR-NEXT: String dump of se

[llvm-branch-commits] [llvm] release/18.x: [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82693)

2024-02-22 Thread Brad Smith via llvm-branch-commits

https://github.com/brad0 closed https://github.com/llvm/llvm-project/pull/82693
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82713)

2024-02-22 Thread Fangrui Song via llvm-branch-commits

MaskRay wrote:

Does `/cherry-pick $commit_id` work? I think it's the preferred way to backport 
a commit.

https://github.com/llvm/llvm-project/pull/82713
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82713)

2024-02-22 Thread Brad Smith via llvm-branch-commits

brad0 wrote:

> Does `/cherry-pick $commit_id` work? I think it's the preferred way to 
> backport a commit.

I tried.  https://github.com/llvm/llvm-project/issues/82692

https://github.com/llvm/llvm-project/pull/82713
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82713)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:


Failed to cherry-pick: $commit_id`

https://github.com/llvm/llvm-project/actions/runs/8013198408

Please manually backport the fix and push it to your github fork.  Once this is 
done, please create a [pull 
request](https://github.com/llvm/llvm-project/compare)

https://github.com/llvm/llvm-project/pull/82713
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82713)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:


Failed to cherry-pick: $commit_id`

https://github.com/llvm/llvm-project/actions/runs/8013213107

Please manually backport the fix and push it to your github fork.  Once this is 
done, please create a [pull 
request](https://github.com/llvm/llvm-project/compare)

https://github.com/llvm/llvm-project/pull/82713
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82713)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:


Failed to cherry-pick: $commit_id`

https://github.com/llvm/llvm-project/actions/runs/8013240633

Please manually backport the fix and push it to your github fork.  Once this is 
done, please create a [pull 
request](https://github.com/llvm/llvm-project/compare)

https://github.com/llvm/llvm-project/pull/82713
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82718)

2024-02-22 Thread via llvm-branch-commits

https://github.com/llvmbot created 
https://github.com/llvm/llvm-project/pull/82718

Backport 26d71d9ed56c4c23e6284dac7a9bdf603a5801f3

Requested by: @brad0

>From 7b790b0ad947db820462799ac70722aa4a18a25f Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Thu, 22 Feb 2024 09:24:21 -0800
Subject: [PATCH] [llvm-readobj,ELF] Support --decompress/-z (#82594)

When a section has the SHF_COMPRESSED flag, -p/-x dump the compressed
content by default. In GNU readelf, if --decompress/-z is specified,
-p/-x will dump the decompressed content. This patch implements the
option.

Close #82507

(cherry picked from commit 26d71d9ed56c4c23e6284dac7a9bdf603a5801f3)
---
 llvm/docs/CommandGuide/llvm-readelf.rst   |  5 ++
 llvm/docs/CommandGuide/llvm-readobj.rst   |  5 ++
 .../ELF/decompress-zlib-unsupported.test  | 32 
 .../llvm-readobj/ELF/decompress-zlib.test | 76 +++
 .../ELF/decompress-zstd-unsupported.test  | 31 
 .../llvm-readobj/ELF/decompress-zstd.test | 28 +++
 llvm/tools/llvm-readobj/ObjDumper.cpp | 26 ++-
 llvm/tools/llvm-readobj/ObjDumper.h   |  4 +-
 llvm/tools/llvm-readobj/Opts.td   |  2 +
 llvm/tools/llvm-readobj/llvm-readobj.cpp  |  6 +-
 10 files changed, 209 insertions(+), 6 deletions(-)
 create mode 100644 
llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
 create mode 100644 llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
 create mode 100644 
llvm/test/tools/llvm-readobj/ELF/decompress-zstd-unsupported.test
 create mode 100644 llvm/test/tools/llvm-readobj/ELF/decompress-zstd.test

diff --git a/llvm/docs/CommandGuide/llvm-readelf.rst 
b/llvm/docs/CommandGuide/llvm-readelf.rst
index 6ee4a5dfb15917..675628fdda45ec 100644
--- a/llvm/docs/CommandGuide/llvm-readelf.rst
+++ b/llvm/docs/CommandGuide/llvm-readelf.rst
@@ -38,6 +38,11 @@ OPTIONS
  Display the contents of the basic block address map section(s), which contain 
the
  address of each function, along with the relative offset of each basic block.
 
+.. option:: --decompress, -z
+
+  Dump decompressed section content when used with ``-x`` or ``-p``.
+  If the section(s) are not compressed, they are displayed as is.
+
 .. option:: --demangle, -C
 
  Display demangled symbol names in the output.
diff --git a/llvm/docs/CommandGuide/llvm-readobj.rst 
b/llvm/docs/CommandGuide/llvm-readobj.rst
index cb9232ef5e560a..6d78a038723445 100644
--- a/llvm/docs/CommandGuide/llvm-readobj.rst
+++ b/llvm/docs/CommandGuide/llvm-readobj.rst
@@ -56,6 +56,11 @@ file formats.
 
  Display the address-significance table.
 
+.. option:: --decompress, -z
+
+  Dump decompressed section content when used with ``-x`` or ``-p``.
+  If the section(s) are not compressed, they are displayed as is.
+
 .. option:: --expand-relocs
 
  When used with :option:`--relocs`, display each relocation in an expanded
diff --git a/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test 
b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
new file mode 100644
index 00..f4c73de7ca6c9d
--- /dev/null
+++ b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
@@ -0,0 +1,32 @@
+# UNSUPPORTED: zlib
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-readobj -z -p .a -x .b %t 2>&1 | FileCheck %s -DFILE=%t
+
+# CHECK:  String dump of section '.a':
+# CHECK-NEXT: warning: '[[FILE]]': LLVM was not built with LLVM_ENABLE_ZLIB or 
did not find zlib at build time
+# CHECK-NEXT: [ 0] .
+# CHECK-NEXT: [ 8] .
+# CHECK-NEXT: [10] .
+# CHECK-NEXT: [18] x.c.
+# CHECK-NEXT: [1e] .
+# CHECK-NEXT: [20] .
+# CHECK-NEXT: Hex dump of section '.b':
+# CHECK-NEXT: warning: '[[FILE]]': LLVM was not built with LLVM_ENABLE_ZLIB or 
did not find zlib at build time
+# CHECK-NEXT: 0x 0100  0100  
+# CHECK-NEXT: 0x0010 0100  789c6304 0200 x.c.
+# CHECK-NEXT: 0x0020 02  .
+
+--- !ELF
+FileHeader:
+  Class: ELFCLASS64
+  Data:  ELFDATA2LSB
+  Type:  ET_REL
+Sections:
+  - Name: .a
+Type: SHT_PROGBITS
+Flags: [SHF_COMPRESSED]
+Content: 010001000100789c6304020002
+  - Name: .b
+Type: SHT_PROGBITS
+Flags: [SHF_COMPRESSED]
+Content: 010001000100789c6304020002
diff --git a/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test 
b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
new file mode 100644
index 00..ea7a8854eb1a0c
--- /dev/null
+++ b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
@@ -0,0 +1,76 @@
+# REQUIRES: zlib
+## Test --decompress/-z.
+
+# RUN: yaml2obj %s -o %t
+
+# RUN: llvm-readelf -z -x .strings -x .not_null_terminated %t | FileCheck %s 
--check-prefix=HEX
+# RUN: llvm-readobj --decompress -p .strings -p .not_null_terminated %t | 
FileCheck %s --check-prefix=STR
+
+# HEX:  Hex dump of section '.strings'

[llvm-branch-commits] [llvm] release/18.x: [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82718)

2024-02-22 Thread via llvm-branch-commits

https://github.com/llvmbot milestoned 
https://github.com/llvm/llvm-project/pull/82718
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82718)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:

@emaste What do you think about merging this PR to the release branch?

https://github.com/llvm/llvm-project/pull/82718
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82718)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:




@llvm/pr-subscribers-llvm-binary-utilities

Author: None (llvmbot)


Changes

Backport 26d71d9ed56c4c23e6284dac7a9bdf603a5801f3

Requested by: @brad0

---
Full diff: https://github.com/llvm/llvm-project/pull/82718.diff


10 Files Affected:

- (modified) llvm/docs/CommandGuide/llvm-readelf.rst (+5) 
- (modified) llvm/docs/CommandGuide/llvm-readobj.rst (+5) 
- (added) llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test 
(+32) 
- (added) llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test (+76) 
- (added) llvm/test/tools/llvm-readobj/ELF/decompress-zstd-unsupported.test 
(+31) 
- (added) llvm/test/tools/llvm-readobj/ELF/decompress-zstd.test (+28) 
- (modified) llvm/tools/llvm-readobj/ObjDumper.cpp (+24-2) 
- (modified) llvm/tools/llvm-readobj/ObjDumper.h (+2-2) 
- (modified) llvm/tools/llvm-readobj/Opts.td (+2) 
- (modified) llvm/tools/llvm-readobj/llvm-readobj.cpp (+4-2) 


``diff
diff --git a/llvm/docs/CommandGuide/llvm-readelf.rst 
b/llvm/docs/CommandGuide/llvm-readelf.rst
index 6ee4a5dfb15917..675628fdda45ec 100644
--- a/llvm/docs/CommandGuide/llvm-readelf.rst
+++ b/llvm/docs/CommandGuide/llvm-readelf.rst
@@ -38,6 +38,11 @@ OPTIONS
  Display the contents of the basic block address map section(s), which contain 
the
  address of each function, along with the relative offset of each basic block.
 
+.. option:: --decompress, -z
+
+  Dump decompressed section content when used with ``-x`` or ``-p``.
+  If the section(s) are not compressed, they are displayed as is.
+
 .. option:: --demangle, -C
 
  Display demangled symbol names in the output.
diff --git a/llvm/docs/CommandGuide/llvm-readobj.rst 
b/llvm/docs/CommandGuide/llvm-readobj.rst
index cb9232ef5e560a..6d78a038723445 100644
--- a/llvm/docs/CommandGuide/llvm-readobj.rst
+++ b/llvm/docs/CommandGuide/llvm-readobj.rst
@@ -56,6 +56,11 @@ file formats.
 
  Display the address-significance table.
 
+.. option:: --decompress, -z
+
+  Dump decompressed section content when used with ``-x`` or ``-p``.
+  If the section(s) are not compressed, they are displayed as is.
+
 .. option:: --expand-relocs
 
  When used with :option:`--relocs`, display each relocation in an expanded
diff --git a/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test 
b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
new file mode 100644
index 00..f4c73de7ca6c9d
--- /dev/null
+++ b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib-unsupported.test
@@ -0,0 +1,32 @@
+# UNSUPPORTED: zlib
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-readobj -z -p .a -x .b %t 2>&1 | FileCheck %s -DFILE=%t
+
+# CHECK:  String dump of section '.a':
+# CHECK-NEXT: warning: '[[FILE]]': LLVM was not built with LLVM_ENABLE_ZLIB or 
did not find zlib at build time
+# CHECK-NEXT: [ 0] .
+# CHECK-NEXT: [ 8] .
+# CHECK-NEXT: [10] .
+# CHECK-NEXT: [18] x.c.
+# CHECK-NEXT: [1e] .
+# CHECK-NEXT: [20] .
+# CHECK-NEXT: Hex dump of section '.b':
+# CHECK-NEXT: warning: '[[FILE]]': LLVM was not built with LLVM_ENABLE_ZLIB or 
did not find zlib at build time
+# CHECK-NEXT: 0x 0100  0100  
+# CHECK-NEXT: 0x0010 0100  789c6304 0200 x.c.
+# CHECK-NEXT: 0x0020 02  .
+
+--- !ELF
+FileHeader:
+  Class: ELFCLASS64
+  Data:  ELFDATA2LSB
+  Type:  ET_REL
+Sections:
+  - Name: .a
+Type: SHT_PROGBITS
+Flags: [SHF_COMPRESSED]
+Content: 010001000100789c6304020002
+  - Name: .b
+Type: SHT_PROGBITS
+Flags: [SHF_COMPRESSED]
+Content: 010001000100789c6304020002
diff --git a/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test 
b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
new file mode 100644
index 00..ea7a8854eb1a0c
--- /dev/null
+++ b/llvm/test/tools/llvm-readobj/ELF/decompress-zlib.test
@@ -0,0 +1,76 @@
+# REQUIRES: zlib
+## Test --decompress/-z.
+
+# RUN: yaml2obj %s -o %t
+
+# RUN: llvm-readelf -z -x .strings -x .not_null_terminated %t | FileCheck %s 
--check-prefix=HEX
+# RUN: llvm-readobj --decompress -p .strings -p .not_null_terminated %t | 
FileCheck %s --check-prefix=STR
+
+# HEX:  Hex dump of section '.strings':
+# HEX-NEXT: 0x 68657265 00617265 00736f6d 65007374 here.are.some.st
+# HEX-NEXT: 0x0010 72696e67 7300   rings.
+# HEX:  Hex dump of section '.not_null_terminated':
+# HEX-NEXT: 0x 6e6f006e 756c6c no.null
+
+# STR:  String dump of section '.strings':
+# STR-NEXT: [ 0] here
+# STR-NEXT: [ 5] are
+# STR-NEXT: [ 9] some
+# STR-NEXT: [ e] strings
+# STR-EMPTY:
+# STR-NEXT: String dump of section '.not_null_terminated':
+# STR-NEXT: [ 0] no
+# STR-NEXT: [ 3] null{{$}}
+# STR-NOT:  {{.}}
+
+# RUN: llvm-readobj -x .strings -p .not_null_terminated %t | FileCheck %s 
--check-prefix=COMPRESSED
+
+# COMPRESSED:  String 

[llvm-branch-commits] [llvm] [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82713)

2024-02-22 Thread Brad Smith via llvm-branch-commits

https://github.com/brad0 closed https://github.com/llvm/llvm-project/pull/82713
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82718)

2024-02-22 Thread Fangrui Song via llvm-branch-commits

https://github.com/MaskRay approved this pull request.

LGTM since this helps at least FreeBSD. Does OpenBSD want to try llvm binary 
utilities?

https://github.com/llvm/llvm-project/pull/82718
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: [llvm-readobj, ELF] Support --decompress/-z (#82594) (PR #82718)

2024-02-22 Thread Brad Smith via llvm-branch-commits

brad0 wrote:

> LGTM since this helps at least FreeBSD. Does OpenBSD want to try llvm binary 
> utilities?

We're slowly moving in that direction with sparing use of objcopy and readelf 
in some places with a desire for more like ar, ranlib and strip.

https://github.com/llvm/llvm-project/pull/82718
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] b9029ed - Extend GCC workaround to GCC < 8.4 for llvm::iterator_range ctor (#82643)

2024-02-22 Thread via llvm-branch-commits

Author: Thomas Preud'homme
Date: 2024-02-22T21:08:58Z
New Revision: b9029ed0053b93d94e0f133e6a44250f82bf0dc2

URL: 
https://github.com/llvm/llvm-project/commit/b9029ed0053b93d94e0f133e6a44250f82bf0dc2
DIFF: 
https://github.com/llvm/llvm-project/commit/b9029ed0053b93d94e0f133e6a44250f82bf0dc2.diff

LOG: Extend GCC workaround to GCC < 8.4 for llvm::iterator_range ctor (#82643)

GCC SFINAE error with decltype was fixed in commit
ac5e28911abdfb8d9bf6bea980223e199bbcf28d which made it into GCC 8.4.
Therefore adjust GCC version test accordingly.

(cherry picked from commit 7f71fa909a10be182b82b9dfaf0fade6eb84796c)

Added: 


Modified: 
llvm/include/llvm/ADT/iterator_range.h

Removed: 




diff  --git a/llvm/include/llvm/ADT/iterator_range.h 
b/llvm/include/llvm/ADT/iterator_range.h
index 2dc227935984b1..7d288ea4506ba5 100644
--- a/llvm/include/llvm/ADT/iterator_range.h
+++ b/llvm/include/llvm/ADT/iterator_range.h
@@ -43,8 +43,8 @@ class iterator_range {
   IteratorT begin_iterator, end_iterator;
 
 public:
-#if __GNUC__ == 7
-  // Be careful no to break gcc-7 on the mlir target.
+#if __GNUC__ == 7 || (__GNUC__ == 8 && __GNUC_MINOR__ < 4)
+  // Be careful no to break gcc-7 and gcc-8 < 8.4 on the mlir target.
   // See https://github.com/llvm/llvm-project/issues/63843
   template 
 #else



___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/18.x: Extend GCC workaround to GCC < 8.4 for llvm::iterator_range ctor (#82643) (PR #82688)

2024-02-22 Thread Tom Stellard via llvm-branch-commits

https://github.com/tstellar closed 
https://github.com/llvm/llvm-project/pull/82688
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] [llvm] release/18.x: [AArch64] Backport Ampere1B support (#81297 , #81341, and #81744) (PR #81857)

2024-02-22 Thread Tom Stellard via llvm-branch-commits

tstellar wrote:

I'm OK with this kind of change if the AArch64 maintainers are on board.  
@AaronBallman Do you have a strong objection to this PR?

https://github.com/llvm/llvm-project/pull/81857
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [OpenMP][MLIR] Add new partial_map and members_index arguments to omp.map_info operations to help support record type mapping (PR #81509)

2024-02-22 Thread via llvm-branch-commits

https://github.com/agozillon updated 
https://github.com/llvm/llvm-project/pull/81509


___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [OpenMP][MLIR] Add new partial_map and members_index arguments to omp.map_info operations to help support record type mapping (PR #81509)

2024-02-22 Thread via llvm-branch-commits

https://github.com/agozillon updated 
https://github.com/llvm/llvm-project/pull/81509


___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [OpenMP][MLIR] Extend explicit derived type member mapping support for OpenMP dialects lowering to LLVM-IR (PR #81510)

2024-02-22 Thread via llvm-branch-commits

https://github.com/agozillon updated 
https://github.com/llvm/llvm-project/pull/81510


___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [Flang][OpenMP][MLIR] Extend derived (record) type map support in Flang OpenMP by adding some initial support for explicit member mapping (PR #81511)

2024-02-22 Thread via llvm-branch-commits

https://github.com/agozillon updated 
https://github.com/llvm/llvm-project/pull/81511


___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [OpenMP][MLIR] Extend explicit derived type member mapping support for OpenMP dialects lowering to LLVM-IR (PR #81510)

2024-02-22 Thread via llvm-branch-commits

https://github.com/agozillon updated 
https://github.com/llvm/llvm-project/pull/81510


___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [Flang][OpenMP][MLIR] Extend derived (record) type map support in Flang OpenMP by adding some initial support for explicit member mapping (PR #81511)

2024-02-22 Thread via llvm-branch-commits

https://github.com/agozillon updated 
https://github.com/llvm/llvm-project/pull/81511


___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [Flang][OpenMP][MLIR] Extend derived (record) type map support in Flang OpenMP by adding some initial support for explicit member mapping (PR #81511)

2024-02-22 Thread via llvm-branch-commits

agozillon wrote:

Rebased on recent changes to the OpenMP lowering!

Plus a little ping for some reviewer attention if at all possible please to get 
some forward momentum on the PR stack, thank you very much ahead of time!

https://github.com/llvm/llvm-project/pull/81511
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [OpenMP][MLIR] Extend explicit derived type member mapping support for OpenMP dialects lowering to LLVM-IR (PR #81510)

2024-02-22 Thread via llvm-branch-commits

agozillon wrote:

a little ping for some reviewer attention if at all possible please to get some 
forward momentum on the PR stack, thank you very much ahead of time!

https://github.com/llvm/llvm-project/pull/81510
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [OpenMP][MLIR] Add new partial_map and members_index arguments to omp.map_info operations to help support record type mapping (PR #81509)

2024-02-22 Thread via llvm-branch-commits

agozillon wrote:

a little ping for some reviewer attention if at all possible please to get some 
forward momentum on the PR stack, thank you very much ahead of time!

https://github.com/llvm/llvm-project/pull/81509
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [libcxx] [libc++] Add details about string annotations (PR #82730)

2024-02-22 Thread via llvm-branch-commits

https://github.com/AdvenamTacet created 
https://github.com/llvm/llvm-project/pull/82730

This commit adds information that only long strings are annotated, and with all 
allocators by default.

To read why short string annotations are not turned on yet, read comments in a 
related PR: https://github.com/llvm/llvm-project/pull/79536

Upstreamed in: 7661ade5d1ac4fc8e1e2339b2476cb8e45c24641
Upstream PR: #80912

-

Co-authored-by: Mark de Wever 

>From af13d9e09c045bdab71740584e5f54e83313e7b1 Mon Sep 17 00:00:00 2001
From: Tacet 
Date: Tue, 20 Feb 2024 07:20:21 +0100
Subject: [PATCH] [libc++] Add details about string annotations (#80912)

This commit adds information that only long strings are annotated, and
with all allocators by default.

To read why short string annotations are not turned on yet, read comments in a 
related
PR: https://github.com/llvm/llvm-project/pull/79536

-

Co-authored-by: Mark de Wever 
---
 libcxx/docs/ReleaseNotes/18.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libcxx/docs/ReleaseNotes/18.rst b/libcxx/docs/ReleaseNotes/18.rst
index 391e0ebc52a428..7ea13e6943dd4c 100644
--- a/libcxx/docs/ReleaseNotes/18.rst
+++ b/libcxx/docs/ReleaseNotes/18.rst
@@ -125,6 +125,8 @@ Improvements and New Features
   ``${PREFIX}/share/libc++/v1``.
 
 - AddressSanitizer annotations have been added to ``std::basic_string``.
+  These annotations are enabled for all allocators by default.
+  It's only enabled for long strings, strings using the small buffer 
optimization are not annotated.
 
 - The libc++ source code has been formatted with ``clang-format``. This
   `discourse thread 
`_

___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [libcxx] [libc++] Add details about string annotations (PR #82730)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:




@llvm/pr-subscribers-libcxx

Author: Tacet (AdvenamTacet)


Changes

This commit adds information that only long strings are annotated, and with all 
allocators by default.

To read why short string annotations are not turned on yet, read comments in a 
related PR: https://github.com/llvm/llvm-project/pull/79536

Upstreamed in: 7661ade5d1ac4fc8e1e2339b2476cb8e45c24641
Upstream PR: #80912

-

Co-authored-by: Mark de Wever 

---
Full diff: https://github.com/llvm/llvm-project/pull/82730.diff


1 Files Affected:

- (modified) libcxx/docs/ReleaseNotes/18.rst (+2) 


``diff
diff --git a/libcxx/docs/ReleaseNotes/18.rst b/libcxx/docs/ReleaseNotes/18.rst
index 391e0ebc52a428..7ea13e6943dd4c 100644
--- a/libcxx/docs/ReleaseNotes/18.rst
+++ b/libcxx/docs/ReleaseNotes/18.rst
@@ -125,6 +125,8 @@ Improvements and New Features
   ``${PREFIX}/share/libc++/v1``.
 
 - AddressSanitizer annotations have been added to ``std::basic_string``.
+  These annotations are enabled for all allocators by default.
+  It's only enabled for long strings, strings using the small buffer 
optimization are not annotated.
 
 - The libc++ source code has been formatted with ``clang-format``. This
   `discourse thread 
`_

``




https://github.com/llvm/llvm-project/pull/82730
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] ReleaseNotes: mention -mtls-dialect=desc (PR #82731)

2024-02-22 Thread Fangrui Song via llvm-branch-commits

https://github.com/MaskRay milestoned 
https://github.com/llvm/llvm-project/pull/82731
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] ReleaseNotes: mention -mtls-dialect=desc (PR #82731)

2024-02-22 Thread Fangrui Song via llvm-branch-commits

https://github.com/MaskRay created 
https://github.com/llvm/llvm-project/pull/82731

None

>From 9e42ddc522436a1129ba5a5e014035ca00262cc0 Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Thu, 22 Feb 2024 19:57:15 -0800
Subject: [PATCH] ReleaseNotes: mention -mtls-dialect=desc

---
 clang/docs/ReleaseNotes.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 93a67e7a895592..6121ef7fa98c04 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -1286,6 +1286,7 @@ RISC-V Support
   for RV64.
 
 - ``__attribute__((rvv_vector_bits(N)))`` is now supported for RVV vbool*_t 
types.
+- ``-mtls-dialect=desc`` is now supported to enable TLS descriptors (TLSDESC).
 
 CUDA/HIP Language Changes
 ^

___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] ReleaseNotes: mention -mtls-dialect=desc (PR #82731)

2024-02-22 Thread via llvm-branch-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Fangrui Song (MaskRay)


Changes



---
Full diff: https://github.com/llvm/llvm-project/pull/82731.diff


1 Files Affected:

- (modified) clang/docs/ReleaseNotes.rst (+1) 


``diff
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 93a67e7a895592..6121ef7fa98c04 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -1286,6 +1286,7 @@ RISC-V Support
   for RV64.
 
 - ``__attribute__((rvv_vector_bits(N)))`` is now supported for RVV vbool*_t 
types.
+- ``-mtls-dialect=desc`` is now supported to enable TLS descriptors (TLSDESC).
 
 CUDA/HIP Language Changes
 ^

``




https://github.com/llvm/llvm-project/pull/82731
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [clang] ReleaseNotes: mention -mtls-dialect=desc (PR #82731)

2024-02-22 Thread Paul Kirth via llvm-branch-commits

https://github.com/ilovepi approved this pull request.


https://github.com/llvm/llvm-project/pull/82731
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [mlir] [mlir][Transforms][NFC] Turn unresolved materializations into `IRRewrite`s (PR #81761)

2024-02-22 Thread Jacques Pienaar via llvm-branch-commits

https://github.com/jpienaar approved this pull request.


https://github.com/llvm/llvm-project/pull/81761
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [mlir] [mlir][Transforms] Encapsulate dialect conversion options in `ConversionConfig` (PR #82250)

2024-02-22 Thread Jacques Pienaar via llvm-branch-commits

https://github.com/jpienaar edited 
https://github.com/llvm/llvm-project/pull/82250
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [mlir] [mlir][Transforms] Encapsulate dialect conversion options in `ConversionConfig` (PR #82250)

2024-02-22 Thread Jacques Pienaar via llvm-branch-commits

https://github.com/jpienaar approved this pull request.


https://github.com/llvm/llvm-project/pull/82250
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [mlir] [mlir][Transforms] Encapsulate dialect conversion options in `ConversionConfig` (PR #82250)

2024-02-22 Thread Jacques Pienaar via llvm-branch-commits


@@ -1070,6 +1072,30 @@ class PDLConversionConfig final {
 
 #endif // MLIR_ENABLE_PDL_IN_PATTERNMATCH
 
+//===--===//
+// ConversionConfig
+//===--===//
+
+/// Dialect conversion configuration.
+struct ConversionConfig {
+  /// An optional callback used to notify about match failure diagnostics 
during
+  /// the conversion. Diagnostics are only reported to this callback may only 
be

jpienaar wrote:

"Diagnostics are only reported to this callback may only be available in debug 
mode" - this reads a bit weird.

https://github.com/llvm/llvm-project/pull/82250
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits