[llvm-branch-commits] [libcxx] release/18.x: change the visibility of libc++ header to public in libcxx module (PR #91182)
RichardLuo0 wrote: > Is there a similar change that is proposed for the main branch? Yes https://github.com/llvm/llvm-project/pull/91240, I forget to mention that here. https://github.com/llvm/llvm-project/pull/91182 ___ 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] [BOLT][BAT] Add entries for deleted basic blocks (PR #91906)
https://github.com/aaupov updated
https://github.com/llvm/llvm-project/pull/91906
>From 972047a832f4fe67170f08f4f75bd3c0bb614021 Mon Sep 17 00:00:00 2001
From: Amir Ayupov
Date: Sun, 12 May 2024 17:37:48 -0700
Subject: [PATCH 1/2] fix test
Created using spr 1.3.4
---
bolt/test/X86/bb-with-two-tail-calls.s | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/bolt/test/X86/bb-with-two-tail-calls.s
b/bolt/test/X86/bb-with-two-tail-calls.s
index c0b01e1894a49..8ea719262d155 100644
--- a/bolt/test/X86/bb-with-two-tail-calls.s
+++ b/bolt/test/X86/bb-with-two-tail-calls.s
@@ -10,8 +10,9 @@
# RUN: %clang %cflags %t.o -o %t.exe -Wl,-q -nostdlib
# RUN: llvm-bolt %t.exe -o %t.out --data %t.fdata --lite=0 --dyno-stats \
# RUN:--print-sctc --print-only=_start -enable-bat 2>&1 | FileCheck %s
-# RUN: llvm-objdump --syms %t.out | FileCheck %s --check-prefix=CHECK-NM
-# RUN: llvm-bat-dump %t.out --dump-all | FileCheck %s --check-prefix=CHECK-BAT
+# RUN: llvm-objdump --syms %t.out > %t.log
+# RUN: llvm-bat-dump %t.out --dump-all >> %t.log
+# RUN: FileCheck %s --input-file %t.log --check-prefix=CHECK-BAT
# CHECK-NOT: Assertion `BranchInfo.size() == 2 && "could only be called for
blocks with 2 successors"' failed.
# Two tail calls in the same basic block after SCTC:
@@ -19,9 +20,9 @@
# CHECK-NEXT:{{.*}}: jmp {{.*}} # TAILCALL # Offset: 12
# Confirm that a deleted basic block is emitted at function end offset (0xe)
-# CHECK-NM: 0060 g .text 000e _start
-# CHECK-BAT: Function Address: 0x60, hash: 0xf8bf620b266cdc1b
-# CHECK-BAT: 0xe -> 0xc hash: 0x823623240f000c
+# CHECK-BAT: [[#%x,ADDR:]] g .text [[#%x,SIZE:]] _start
+# CHECK-BAT: Function Address: 0x[[#%x,ADDR]]
+# CHECK-BAT: 0x[[#%x,SIZE]]
# CHECK-BAT: NumBlocks: 5
.globl _start
>From 8cf2305cbd12d6667b586fdb8125bc1310fce0be Mon Sep 17 00:00:00 2001
From: Amir Ayupov
Date: Sun, 12 May 2024 17:46:54 -0700
Subject: [PATCH 2/2] updated tests
Created using spr 1.3.4
---
bolt/test/X86/bolt-address-translation-yaml.test | 2 +-
bolt/test/X86/bolt-address-translation.test | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/bolt/test/X86/bolt-address-translation-yaml.test
b/bolt/test/X86/bolt-address-translation-yaml.test
index e21513b7dfe59..e28ca5c6c3488 100644
--- a/bolt/test/X86/bolt-address-translation-yaml.test
+++ b/bolt/test/X86/bolt-address-translation-yaml.test
@@ -40,7 +40,7 @@ RUN: | FileCheck --check-prefix CHECK-BOLT-YAML %s
WRITE-BAT-CHECK: BOLT-INFO: Wrote 5 BAT maps
WRITE-BAT-CHECK: BOLT-INFO: Wrote 4 function and 22 basic block hashes
-WRITE-BAT-CHECK: BOLT-INFO: BAT section size (bytes): 384
+WRITE-BAT-CHECK: BOLT-INFO: BAT section size (bytes): 404
READ-BAT-CHECK-NOT: BOLT-ERROR: unable to save profile in YAML format for
input file processed by BOLT
READ-BAT-CHECK: BOLT-INFO: Parsed 5 BAT entries
diff --git a/bolt/test/X86/bolt-address-translation.test
b/bolt/test/X86/bolt-address-translation.test
index e6b21c14077b4..dfdd1eea32333 100644
--- a/bolt/test/X86/bolt-address-translation.test
+++ b/bolt/test/X86/bolt-address-translation.test
@@ -37,7 +37,7 @@
# CHECK: BOLT: 3 out of 7 functions were overwritten.
# CHECK: BOLT-INFO: Wrote 6 BAT maps
# CHECK: BOLT-INFO: Wrote 3 function and 58 basic block hashes
-# CHECK: BOLT-INFO: BAT section size (bytes): 928
+# CHECK: BOLT-INFO: BAT section size (bytes): 940
#
# usqrt mappings (hot part). We match against any key (left side containing
# the bolted binary offsets) because BOLT may change where it puts instructions
___
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] [BOLT][BAT] Add entries for deleted basic blocks (PR #91906)
https://github.com/aaupov updated
https://github.com/llvm/llvm-project/pull/91906
>From 972047a832f4fe67170f08f4f75bd3c0bb614021 Mon Sep 17 00:00:00 2001
From: Amir Ayupov
Date: Sun, 12 May 2024 17:37:48 -0700
Subject: [PATCH 1/2] fix test
Created using spr 1.3.4
---
bolt/test/X86/bb-with-two-tail-calls.s | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/bolt/test/X86/bb-with-two-tail-calls.s
b/bolt/test/X86/bb-with-two-tail-calls.s
index c0b01e1894a49..8ea719262d155 100644
--- a/bolt/test/X86/bb-with-two-tail-calls.s
+++ b/bolt/test/X86/bb-with-two-tail-calls.s
@@ -10,8 +10,9 @@
# RUN: %clang %cflags %t.o -o %t.exe -Wl,-q -nostdlib
# RUN: llvm-bolt %t.exe -o %t.out --data %t.fdata --lite=0 --dyno-stats \
# RUN:--print-sctc --print-only=_start -enable-bat 2>&1 | FileCheck %s
-# RUN: llvm-objdump --syms %t.out | FileCheck %s --check-prefix=CHECK-NM
-# RUN: llvm-bat-dump %t.out --dump-all | FileCheck %s --check-prefix=CHECK-BAT
+# RUN: llvm-objdump --syms %t.out > %t.log
+# RUN: llvm-bat-dump %t.out --dump-all >> %t.log
+# RUN: FileCheck %s --input-file %t.log --check-prefix=CHECK-BAT
# CHECK-NOT: Assertion `BranchInfo.size() == 2 && "could only be called for
blocks with 2 successors"' failed.
# Two tail calls in the same basic block after SCTC:
@@ -19,9 +20,9 @@
# CHECK-NEXT:{{.*}}: jmp {{.*}} # TAILCALL # Offset: 12
# Confirm that a deleted basic block is emitted at function end offset (0xe)
-# CHECK-NM: 0060 g .text 000e _start
-# CHECK-BAT: Function Address: 0x60, hash: 0xf8bf620b266cdc1b
-# CHECK-BAT: 0xe -> 0xc hash: 0x823623240f000c
+# CHECK-BAT: [[#%x,ADDR:]] g .text [[#%x,SIZE:]] _start
+# CHECK-BAT: Function Address: 0x[[#%x,ADDR]]
+# CHECK-BAT: 0x[[#%x,SIZE]]
# CHECK-BAT: NumBlocks: 5
.globl _start
>From 8cf2305cbd12d6667b586fdb8125bc1310fce0be Mon Sep 17 00:00:00 2001
From: Amir Ayupov
Date: Sun, 12 May 2024 17:46:54 -0700
Subject: [PATCH 2/2] updated tests
Created using spr 1.3.4
---
bolt/test/X86/bolt-address-translation-yaml.test | 2 +-
bolt/test/X86/bolt-address-translation.test | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/bolt/test/X86/bolt-address-translation-yaml.test
b/bolt/test/X86/bolt-address-translation-yaml.test
index e21513b7dfe59..e28ca5c6c3488 100644
--- a/bolt/test/X86/bolt-address-translation-yaml.test
+++ b/bolt/test/X86/bolt-address-translation-yaml.test
@@ -40,7 +40,7 @@ RUN: | FileCheck --check-prefix CHECK-BOLT-YAML %s
WRITE-BAT-CHECK: BOLT-INFO: Wrote 5 BAT maps
WRITE-BAT-CHECK: BOLT-INFO: Wrote 4 function and 22 basic block hashes
-WRITE-BAT-CHECK: BOLT-INFO: BAT section size (bytes): 384
+WRITE-BAT-CHECK: BOLT-INFO: BAT section size (bytes): 404
READ-BAT-CHECK-NOT: BOLT-ERROR: unable to save profile in YAML format for
input file processed by BOLT
READ-BAT-CHECK: BOLT-INFO: Parsed 5 BAT entries
diff --git a/bolt/test/X86/bolt-address-translation.test
b/bolt/test/X86/bolt-address-translation.test
index e6b21c14077b4..dfdd1eea32333 100644
--- a/bolt/test/X86/bolt-address-translation.test
+++ b/bolt/test/X86/bolt-address-translation.test
@@ -37,7 +37,7 @@
# CHECK: BOLT: 3 out of 7 functions were overwritten.
# CHECK: BOLT-INFO: Wrote 6 BAT maps
# CHECK: BOLT-INFO: Wrote 3 function and 58 basic block hashes
-# CHECK: BOLT-INFO: BAT section size (bytes): 928
+# CHECK: BOLT-INFO: BAT section size (bytes): 940
#
# usqrt mappings (hot part). We match against any key (left side containing
# the bolted binary offsets) because BOLT may change where it puts instructions
___
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] [BOLT][NFC] Rename DataAggregator::BranchInfo to TakenBranchInfo (PR #92017)
https://github.com/aaupov edited https://github.com/llvm/llvm-project/pull/92017 ___ 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] [BOLT][NFC] Rename DataAggregator::BranchInfo to TakenInfo (PR #92017)
https://github.com/aaupov updated
https://github.com/llvm/llvm-project/pull/92017
>From 096f5cc4cae69a428629a8c05f5e4ce373ca7d60 Mon Sep 17 00:00:00 2001
From: Amir Ayupov
Date: Thu, 16 May 2024 23:00:50 -0400
Subject: [PATCH] TakenBranchInfo
Created using spr 1.3.5
---
bolt/include/bolt/Profile/DataAggregator.h | 4 ++--
bolt/lib/Profile/DataAggregator.cpp| 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/bolt/include/bolt/Profile/DataAggregator.h
b/bolt/include/bolt/Profile/DataAggregator.h
index 48f01511f4827..c158a9bb3e3f2 100644
--- a/bolt/include/bolt/Profile/DataAggregator.h
+++ b/bolt/include/bolt/Profile/DataAggregator.h
@@ -122,14 +122,14 @@ class DataAggregator : public DataReader {
uint64_t ExternCount{0};
};
- struct TakenInfo {
+ struct TakenBranchInfo {
uint64_t TakenCount{0};
uint64_t MispredCount{0};
};
/// Intermediate storage for profile data. We save the results of parsing
/// and use them later for processing and assigning profile.
- std::unordered_map BranchLBRs;
+ std::unordered_map BranchLBRs;
std::unordered_map FallthroughLBRs;
std::vector AggregatedLBRs;
std::unordered_map BasicSamples;
diff --git a/bolt/lib/Profile/DataAggregator.cpp
b/bolt/lib/Profile/DataAggregator.cpp
index 0e11963c676f0..e06debcee741e 100644
--- a/bolt/lib/Profile/DataAggregator.cpp
+++ b/bolt/lib/Profile/DataAggregator.cpp
@@ -1464,7 +1464,7 @@ uint64_t DataAggregator::parseLBRSample(const
PerfBranchSample ,
uint64_t To = getBinaryFunctionContainingAddress(LBR.To) ? LBR.To : 0;
if (!From && !To)
continue;
-TakenInfo = BranchLBRs[Trace(From, To)];
+TakenBranchInfo = BranchLBRs[Trace(From, To)];
++Info.TakenCount;
Info.MispredCount += LBR.Mispred;
}
@@ -1609,7 +1609,7 @@ void DataAggregator::processBranchEvents() {
for (const auto : BranchLBRs) {
const Trace = AggrLBR.first;
-const TakenInfo = AggrLBR.second;
+const TakenBranchInfo = AggrLBR.second;
doBranch(Loc.From, Loc.To, Info.TakenCount, Info.MispredCount);
}
}
___
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] [lldb] ebb9f82 - Revert "[lldb] Include SBLanguages in the SWIG bindings (#92470)"
Author: Jonas Devlieghere
Date: 2024-05-16T19:58:44-07:00
New Revision: ebb9f82e4c6f9b7c6f627da71ffbfb858f655d1e
URL:
https://github.com/llvm/llvm-project/commit/ebb9f82e4c6f9b7c6f627da71ffbfb858f655d1e
DIFF:
https://github.com/llvm/llvm-project/commit/ebb9f82e4c6f9b7c6f627da71ffbfb858f655d1e.diff
LOG: Revert "[lldb] Include SBLanguages in the SWIG bindings (#92470)"
This reverts commit ebf283162f5a0e7e9392c3a825e060856eee0991.
Added:
Modified:
lldb/bindings/CMakeLists.txt
lldb/bindings/headers.swig
lldb/bindings/interfaces.swig
Removed:
diff --git a/lldb/bindings/CMakeLists.txt b/lldb/bindings/CMakeLists.txt
index bec694e43bd7b..296eae1ae77f8 100644
--- a/lldb/bindings/CMakeLists.txt
+++ b/lldb/bindings/CMakeLists.txt
@@ -3,7 +3,6 @@ file(GLOB_RECURSE SWIG_SOURCES *.swig)
file(GLOB SWIG_HEADERS
${LLDB_SOURCE_DIR}/include/lldb/API/*.h
${LLDB_SOURCE_DIR}/include/lldb/*.h
- ${LLDB_BINARY_DIR}/include/lldb/API/SBLanguages.h
)
file(GLOB SWIG_PRIVATE_HEADERS
${LLDB_SOURCE_DIR}/include/lldb/lldb-private*.h
@@ -31,7 +30,6 @@ set(SWIG_COMMON_FLAGS
-w361,362,509
-features autodoc
-I${LLDB_SOURCE_DIR}/include
- -I${LLDB_BINARY_DIR}/include
-I${CMAKE_CURRENT_SOURCE_DIR}
${DARWIN_EXTRAS}
)
diff --git a/lldb/bindings/headers.swig b/lldb/bindings/headers.swig
index ffdc3c31ec883..e8d0cda288141 100644
--- a/lldb/bindings/headers.swig
+++ b/lldb/bindings/headers.swig
@@ -36,7 +36,6 @@
#include "lldb/API/SBHostOS.h"
#include "lldb/API/SBInstruction.h"
#include "lldb/API/SBInstructionList.h"
-#include "lldb/API/SBLanguages.h"
#include "lldb/API/SBLanguageRuntime.h"
#include "lldb/API/SBLaunchInfo.h"
#include "lldb/API/SBLineEntry.h"
diff --git a/lldb/bindings/interfaces.swig b/lldb/bindings/interfaces.swig
index 2a29a8dd7ef0b..a31a0b4af1eb6 100644
--- a/lldb/bindings/interfaces.swig
+++ b/lldb/bindings/interfaces.swig
@@ -114,7 +114,6 @@
%include "lldb/API/SBHostOS.h"
%include "lldb/API/SBInstruction.h"
%include "lldb/API/SBInstructionList.h"
-%include "lldb/API/SBLanguages.h"
%include "lldb/API/SBLanguageRuntime.h"
%include "lldb/API/SBLaunchInfo.h"
%include "lldb/API/SBLineEntry.h"
___
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] [BOLT][NFC] Rename DataAggregator::BranchInfo to TakenInfo (PR #92017)
https://github.com/aaupov updated https://github.com/llvm/llvm-project/pull/92017 ___ 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] [BOLT][NFC] Rename DataAggregator::BranchInfo to TakenInfo (PR #92017)
https://github.com/aaupov updated https://github.com/llvm/llvm-project/pull/92017 ___ 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: InstCombine: Process addrspacecast uses in PointerReplacer (#91953) (PR #92479)
llvmbot wrote:
@llvm/pr-subscribers-llvm-transforms
Author: AtariDreams (AtariDreams)
Changes
This was looking through an addrspacecast, and not finding a later unfoldable
cast to another address space. Fixes improperly deleting a required alloca +
memcpy and introducing an illegal addrspacecast.
This also required fixing some worklist management issues with addrspacecast,
and assuming that only memcpy sources could need replacement.
Regresses one test function, but this looks like it optimized before by
accident. It never saw the pointer use by the call to readonly_callee, which
should require insertion of a new cast.
Fixes #68120
(cherry picked from commit 847c83f7cceeaec6676f33291081912d6b8fda5e)
---
Full diff: https://github.com/llvm/llvm-project/pull/92479.diff
3 Files Affected:
- (modified) llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
(+18-15)
- (added) llvm/test/Transforms/InstCombine/AMDGPU/issue68120.ll (+81)
- (modified) llvm/test/Transforms/InstCombine/ptr-replace-alloca.ll (+5-1)
``diff
diff --git a/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
b/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
index 1254a050027a4..b6a68c03f6306 100644
--- a/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
+++ b/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
@@ -342,9 +342,13 @@ bool PointerReplacer::collectUsersRecursive(Instruction
) {
Worklist.insert(Inst);
} else if (isEqualOrValidAddrSpaceCast(Inst, FromAS)) {
Worklist.insert(Inst);
+ if (!collectUsersRecursive(*Inst))
+return false;
} else if (Inst->isLifetimeStartOrEnd()) {
continue;
} else {
+ // TODO: For arbitrary uses with address space mismatches, should we
check
+ // if we can introduce a valid addrspacecast?
LLVM_DEBUG(dbgs() << "Cannot handle pointer user: " << *U << '\n');
return false;
}
@@ -406,20 +410,18 @@ void PointerReplacer::replace(Instruction *I) {
NewSI->takeName(SI);
WorkMap[SI] = NewSI;
} else if (auto *MemCpy = dyn_cast(I)) {
-auto *SrcV = getReplacement(MemCpy->getRawSource());
-// The pointer may appear in the destination of a copy, but we don't want
to
-// replace it.
-if (!SrcV) {
- assert(getReplacement(MemCpy->getRawDest()) &&
- "destination not in replace list");
- return;
-}
+auto *DestV = MemCpy->getRawDest();
+auto *SrcV = MemCpy->getRawSource();
+
+if (auto *DestReplace = getReplacement(DestV))
+ DestV = DestReplace;
+if (auto *SrcReplace = getReplacement(SrcV))
+ SrcV = SrcReplace;
IC.Builder.SetInsertPoint(MemCpy);
auto *NewI = IC.Builder.CreateMemTransferInst(
-MemCpy->getIntrinsicID(), MemCpy->getRawDest(), MemCpy->getDestAlign(),
-SrcV, MemCpy->getSourceAlign(), MemCpy->getLength(),
-MemCpy->isVolatile());
+MemCpy->getIntrinsicID(), DestV, MemCpy->getDestAlign(), SrcV,
+MemCpy->getSourceAlign(), MemCpy->getLength(), MemCpy->isVolatile());
AAMDNodes AAMD = MemCpy->getAAMetadata();
if (AAMD)
NewI->setAAMetadata(AAMD);
@@ -432,16 +434,17 @@ void PointerReplacer::replace(Instruction *I) {
assert(isEqualOrValidAddrSpaceCast(
ASC, V->getType()->getPointerAddressSpace()) &&
"Invalid address space cast!");
-auto *NewV = V;
+
if (V->getType()->getPointerAddressSpace() !=
ASC->getType()->getPointerAddressSpace()) {
auto *NewI = new AddrSpaceCastInst(V, ASC->getType(), "");
NewI->takeName(ASC);
IC.InsertNewInstWith(NewI, ASC->getIterator());
- NewV = NewI;
+ WorkMap[ASC] = NewI;
+} else {
+ WorkMap[ASC] = V;
}
-IC.replaceInstUsesWith(*ASC, NewV);
-IC.eraseInstFromFunction(*ASC);
+
} else {
llvm_unreachable("should never reach here");
}
diff --git a/llvm/test/Transforms/InstCombine/AMDGPU/issue68120.ll
b/llvm/test/Transforms/InstCombine/AMDGPU/issue68120.ll
new file mode 100644
index 0..346c64f096ba3
--- /dev/null
+++ b/llvm/test/Transforms/InstCombine/AMDGPU/issue68120.ll
@@ -0,0 +1,81 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
UTC_ARGS: --version 4
+; RUN: opt -S -mtriple=amdgcn-amd-amdhsa -passes=instcombine %s | FileCheck %s
+
+; It is illegal to pass ptr addrspace(4) in %arg by addrspacecasting
+; to ptr addrspace(5) to pass off to the stack argument. A temporary
+; alloca and memcpy is necessary.
+define void @issue68120_invalid_addrspacecast_introduced_0(ptr addrspace(4)
byref([56 x i8]) %arg) {
+; CHECK-LABEL: define void @issue68120_invalid_addrspacecast_introduced_0(
+; CHECK-SAME: ptr addrspace(4) byref([56 x i8]) [[ARG:%.*]]) {
+; CHECK-NEXT:[[ADDRSPACECAST_0_TO_5:%.*]] = alloca [56 x i8], align 1,
addrspace(5)
+; CHECK-NEXT:call void @llvm.memcpy.p5.p4.i64(ptr addrspace(5) noundef
align 1
[llvm-branch-commits] [llvm] release/18.x: InstCombine: Process addrspacecast uses in PointerReplacer (#91953) (PR #92479)
https://github.com/AtariDreams created
https://github.com/llvm/llvm-project/pull/92479
This was looking through an addrspacecast, and not finding a later unfoldable
cast to another address space. Fixes improperly deleting a required alloca +
memcpy and introducing an illegal addrspacecast.
This also required fixing some worklist management issues with addrspacecast,
and assuming that only memcpy sources could need replacement.
Regresses one test function, but this looks like it optimized before by
accident. It never saw the pointer use by the call to readonly_callee, which
should require insertion of a new cast.
Fixes #68120
(cherry picked from commit 847c83f7cceeaec6676f33291081912d6b8fda5e)
>From 51155b3138ed1d7e6418069dbf9557dda3ae6ea9 Mon Sep 17 00:00:00 2001
From: Matt Arsenault
Date: Wed, 15 May 2024 07:02:31 +0200
Subject: [PATCH] InstCombine: Process addrspacecast uses in PointerReplacer
(#91953)
This was looking through an addrspacecast, and not finding a later
unfoldable cast to another address space. Fixes improperly deleting
a required alloca + memcpy and introducing an illegal addrspacecast.
This also required fixing some worklist management issues with
addrspacecast, and assuming that only memcpy sources could need
replacement.
Regresses one test function, but this looks like it optimized
before by accident. It never saw the pointer use by the call
to readonly_callee, which should require insertion of a new cast.
Fixes #68120
(cherry picked from commit 847c83f7cceeaec6676f33291081912d6b8fda5e)
---
.../InstCombineLoadStoreAlloca.cpp| 33
.../InstCombine/AMDGPU/issue68120.ll | 81 +++
.../InstCombine/ptr-replace-alloca.ll | 6 +-
3 files changed, 104 insertions(+), 16 deletions(-)
create mode 100644 llvm/test/Transforms/InstCombine/AMDGPU/issue68120.ll
diff --git a/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
b/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
index 1254a050027a4..b6a68c03f6306 100644
--- a/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
+++ b/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
@@ -342,9 +342,13 @@ bool PointerReplacer::collectUsersRecursive(Instruction
) {
Worklist.insert(Inst);
} else if (isEqualOrValidAddrSpaceCast(Inst, FromAS)) {
Worklist.insert(Inst);
+ if (!collectUsersRecursive(*Inst))
+return false;
} else if (Inst->isLifetimeStartOrEnd()) {
continue;
} else {
+ // TODO: For arbitrary uses with address space mismatches, should we
check
+ // if we can introduce a valid addrspacecast?
LLVM_DEBUG(dbgs() << "Cannot handle pointer user: " << *U << '\n');
return false;
}
@@ -406,20 +410,18 @@ void PointerReplacer::replace(Instruction *I) {
NewSI->takeName(SI);
WorkMap[SI] = NewSI;
} else if (auto *MemCpy = dyn_cast(I)) {
-auto *SrcV = getReplacement(MemCpy->getRawSource());
-// The pointer may appear in the destination of a copy, but we don't want
to
-// replace it.
-if (!SrcV) {
- assert(getReplacement(MemCpy->getRawDest()) &&
- "destination not in replace list");
- return;
-}
+auto *DestV = MemCpy->getRawDest();
+auto *SrcV = MemCpy->getRawSource();
+
+if (auto *DestReplace = getReplacement(DestV))
+ DestV = DestReplace;
+if (auto *SrcReplace = getReplacement(SrcV))
+ SrcV = SrcReplace;
IC.Builder.SetInsertPoint(MemCpy);
auto *NewI = IC.Builder.CreateMemTransferInst(
-MemCpy->getIntrinsicID(), MemCpy->getRawDest(), MemCpy->getDestAlign(),
-SrcV, MemCpy->getSourceAlign(), MemCpy->getLength(),
-MemCpy->isVolatile());
+MemCpy->getIntrinsicID(), DestV, MemCpy->getDestAlign(), SrcV,
+MemCpy->getSourceAlign(), MemCpy->getLength(), MemCpy->isVolatile());
AAMDNodes AAMD = MemCpy->getAAMetadata();
if (AAMD)
NewI->setAAMetadata(AAMD);
@@ -432,16 +434,17 @@ void PointerReplacer::replace(Instruction *I) {
assert(isEqualOrValidAddrSpaceCast(
ASC, V->getType()->getPointerAddressSpace()) &&
"Invalid address space cast!");
-auto *NewV = V;
+
if (V->getType()->getPointerAddressSpace() !=
ASC->getType()->getPointerAddressSpace()) {
auto *NewI = new AddrSpaceCastInst(V, ASC->getType(), "");
NewI->takeName(ASC);
IC.InsertNewInstWith(NewI, ASC->getIterator());
- NewV = NewI;
+ WorkMap[ASC] = NewI;
+} else {
+ WorkMap[ASC] = V;
}
-IC.replaceInstUsesWith(*ASC, NewV);
-IC.eraseInstFromFunction(*ASC);
+
} else {
llvm_unreachable("should never reach here");
}
diff --git a/llvm/test/Transforms/InstCombine/AMDGPU/issue68120.ll
b/llvm/test/Transforms/InstCombine/AMDGPU/issue68120.ll
new file mode 100644
index 0..346c64f096ba3
--- /dev/null
+++ b/llvm/test/Transforms/InstCombine/AMDGPU/issue68120.ll
[llvm-branch-commits] [lld] [llvm] release/18.x: [lld] Fix -ObjC load behavior with LTO (#92162) (PR #92478)
llvmbot wrote:
@llvm/pr-subscribers-lld-macho
Author: AtariDreams (AtariDreams)
Changes
When -ObjC is passed, the linker must force load any object files that contain
special sections that store Objective-C / Swift information that is used at
runtime.
This should work regadless if input files are bitcode or native, but it was not
working with bitcode. This is because the sections that identify an object file
that should be loaded were inconsistent when dealing with a native file vs
bitcode file. In particular, bitcode files were not searched for
`__TEXT,__swift` prefixed sections, while native files were.
This means LLD wasn't loading certain bitcode files and forcing the user to
introduce --force-load to their linker invocation for that archive.
---
Full diff: https://github.com/llvm/llvm-project/pull/92478.diff
2 Files Affected:
- (modified) lld/test/MachO/objc.s (+20-3)
- (modified) llvm/lib/Bitcode/Reader/BitcodeReader.cpp (+2-1)
``diff
diff --git a/lld/test/MachO/objc.s b/lld/test/MachO/objc.s
index e7074141f0113..dbb9f1df27571 100644
--- a/lld/test/MachO/objc.s
+++ b/lld/test/MachO/objc.s
@@ -5,12 +5,14 @@
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin
%t/has-objc-category.s -o %t/has-objc-category.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin
%t/has-objc-symbol-and-category.s -o %t/has-objc-symbol-and-category.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/has-swift.s -o
%t/has-swift.o
+# RUN: llvm-as %t/has-swift-ir-loaded.ll -o %t/has-swift-ir-loaded.o
+# RUN: llvm-as %t/has-swift-ir-not-loaded.ll -o %t/has-swift-ir-not-loaded.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/has-swift-proto.s
-o %t/has-swift-proto.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/no-objc.s -o
%t/no-objc.o
## Make sure we don't mis-parse a 32-bit file as 64-bit
# RUN: llvm-mc -filetype=obj -triple=armv7-apple-watchos %t/no-objc.s -o
%t/wrong-arch.o
-# RUN: llvm-ar rcs %t/libHasSomeObjC.a %t/no-objc.o %t/has-objc-symbol.o
%t/has-objc-category.o %t/has-swift.o %t/has-swift-proto.o %t/wrong-arch.o
-# RUN: llvm-ar rcs %t/libHasSomeObjC2.a %t/no-objc.o
%t/has-objc-symbol-and-category.o %t/has-swift.o %t/has-swift-proto.o
%t/wrong-arch.o
+# RUN: llvm-ar rcs %t/libHasSomeObjC.a %t/no-objc.o %t/has-objc-symbol.o
%t/has-objc-category.o %t/has-swift.o %t/has-swift-proto.o
%t/has-swift-ir-loaded.o %t/has-swift-ir-not-loaded.o %t/wrong-arch.o
+# RUN: llvm-ar rcs %t/libHasSomeObjC2.a %t/no-objc.o
%t/has-objc-symbol-and-category.o %t/has-swift.o %t/has-swift-proto.o
%t/has-swift-ir-loaded.o %t/has-swift-ir-not-loaded.o %t/wrong-arch.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/test.s -o %t/test.o
@@ -20,7 +22,7 @@
# RUN: %lld -lSystem %t/test.o -o %t/test -L%t -lHasSomeObjC2 -ObjC
# RUN: llvm-objdump --section-headers --syms %t/test | FileCheck %s
--check-prefix=OBJC
-# RUN: %no-fatal-warnings-lld -lSystem %t/test.o -o %t/test --start-lib
%t/no-objc.o %t/has-objc-symbol.o %t/has-objc-category.o %t/has-swift.o
%t/has-swift-proto.o %t/wrong-arch.o --end-lib -ObjC 2>&1 \
+# RUN: %no-fatal-warnings-lld -lSystem %t/test.o -o %t/test --start-lib
%t/no-objc.o %t/has-objc-symbol.o %t/has-objc-category.o %t/has-swift.o
%t/has-swift-proto.o %t/has-swift-ir-loaded.o %t/has-swift-ir-not-loaded.o
%t/wrong-arch.o --end-lib -ObjC 2>&1 \
# RUN: | FileCheck -check-prefix=WARNING %s
# RUN: llvm-objdump --section-headers --syms %t/test | FileCheck %s
--check-prefix=OBJC
@@ -36,6 +38,7 @@
# OBJC-NEXT:4 has_objc_symbol {{.*}} DATA
# OBJC-EMPTY:
# OBJC-NEXT: SYMBOL TABLE:
+# OBJC-DAG: g O __TEXT,__swift _foo
# OBJC-DAG: g F __TEXT,__text _main
# OBJC-DAG: g F __TEXT,__text _OBJC_CLASS_$_MyObject
# OBJC-DAG: g O __TEXT,__swift5_fieldmd $s7somelib4Blah_pMF
@@ -100,6 +103,20 @@ _has_dup:
.section __TEXT,__swift
.quad 0x1234
+#--- has-swift-ir-loaded.ll
+target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
+target triple = "x86_64-apple-darwin"
+
+@foo = global i64 1234, section "__TEXT,__swift"
+@llvm.used = appending global [1 x ptr] [ptr @foo]
+
+#--- has-swift-ir-not-loaded.ll
+target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
+target triple = "x86_64-apple-darwin"
+
+@bar = global i64 1234
+@llvm.used = appending global [1 x ptr] [ptr @bar]
+
#--- has-swift-proto.s
.section __TEXT,__swift5_fieldmd
.globl $s7somelib4Blah_pMF
diff --git a/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
b/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
index a027d0c21ba0b..db1bd457f83d1 100644
--- a/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
+++ b/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
@@ -294,7 +294,8 @@ static Expected
hasObjCCategoryInModule(BitstreamCursor ) {
return error("Invalid section name record");
// Check for the i386 and other (x86_64, ARM) conventions
if (S.find("__DATA,__objc_catlist") != std::string::npos ||
-
[llvm-branch-commits] [lld] [llvm] release/18.x: [lld] Fix -ObjC load behavior with LTO (#92162) (PR #92478)
https://github.com/AtariDreams updated
https://github.com/llvm/llvm-project/pull/92478
>From 8c9c7a49a36eccaca8867b2535988cf12ba6b41d Mon Sep 17 00:00:00 2001
From: Nuri Amari
Date: Wed, 15 May 2024 09:21:02 -0700
Subject: [PATCH] [lld] Fix -ObjC load behavior with LTO (#92162)
When -ObjC is passed, the linker must force load any object files that
contain special sections that store Objective-C / Swift information that
is used at runtime.
This should work regadless if input files are bitcode or native, but it
was not working with bitcode. This is because the sections that identify
an object file that should be loaded were inconsistent when dealing with
a native file vs bitcode file. In particular, bitcode files were not
searched for `__TEXT,__swift` prefixed sections, while native files
were.
This means LLD wasn't loading certain bitcode files and forcing the user
to introduce --force-load to their linker invocation for that archive.
Co-authored-by: Nuri Amari
---
lld/test/MachO/objc.s | 23 ---
llvm/lib/Bitcode/Reader/BitcodeReader.cpp | 3 ++-
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/lld/test/MachO/objc.s b/lld/test/MachO/objc.s
index e7074141f0113..dbb9f1df27571 100644
--- a/lld/test/MachO/objc.s
+++ b/lld/test/MachO/objc.s
@@ -5,12 +5,14 @@
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin
%t/has-objc-category.s -o %t/has-objc-category.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin
%t/has-objc-symbol-and-category.s -o %t/has-objc-symbol-and-category.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/has-swift.s -o
%t/has-swift.o
+# RUN: llvm-as %t/has-swift-ir-loaded.ll -o %t/has-swift-ir-loaded.o
+# RUN: llvm-as %t/has-swift-ir-not-loaded.ll -o %t/has-swift-ir-not-loaded.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/has-swift-proto.s
-o %t/has-swift-proto.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/no-objc.s -o
%t/no-objc.o
## Make sure we don't mis-parse a 32-bit file as 64-bit
# RUN: llvm-mc -filetype=obj -triple=armv7-apple-watchos %t/no-objc.s -o
%t/wrong-arch.o
-# RUN: llvm-ar rcs %t/libHasSomeObjC.a %t/no-objc.o %t/has-objc-symbol.o
%t/has-objc-category.o %t/has-swift.o %t/has-swift-proto.o %t/wrong-arch.o
-# RUN: llvm-ar rcs %t/libHasSomeObjC2.a %t/no-objc.o
%t/has-objc-symbol-and-category.o %t/has-swift.o %t/has-swift-proto.o
%t/wrong-arch.o
+# RUN: llvm-ar rcs %t/libHasSomeObjC.a %t/no-objc.o %t/has-objc-symbol.o
%t/has-objc-category.o %t/has-swift.o %t/has-swift-proto.o
%t/has-swift-ir-loaded.o %t/has-swift-ir-not-loaded.o %t/wrong-arch.o
+# RUN: llvm-ar rcs %t/libHasSomeObjC2.a %t/no-objc.o
%t/has-objc-symbol-and-category.o %t/has-swift.o %t/has-swift-proto.o
%t/has-swift-ir-loaded.o %t/has-swift-ir-not-loaded.o %t/wrong-arch.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/test.s -o %t/test.o
@@ -20,7 +22,7 @@
# RUN: %lld -lSystem %t/test.o -o %t/test -L%t -lHasSomeObjC2 -ObjC
# RUN: llvm-objdump --section-headers --syms %t/test | FileCheck %s
--check-prefix=OBJC
-# RUN: %no-fatal-warnings-lld -lSystem %t/test.o -o %t/test --start-lib
%t/no-objc.o %t/has-objc-symbol.o %t/has-objc-category.o %t/has-swift.o
%t/has-swift-proto.o %t/wrong-arch.o --end-lib -ObjC 2>&1 \
+# RUN: %no-fatal-warnings-lld -lSystem %t/test.o -o %t/test --start-lib
%t/no-objc.o %t/has-objc-symbol.o %t/has-objc-category.o %t/has-swift.o
%t/has-swift-proto.o %t/has-swift-ir-loaded.o %t/has-swift-ir-not-loaded.o
%t/wrong-arch.o --end-lib -ObjC 2>&1 \
# RUN: | FileCheck -check-prefix=WARNING %s
# RUN: llvm-objdump --section-headers --syms %t/test | FileCheck %s
--check-prefix=OBJC
@@ -36,6 +38,7 @@
# OBJC-NEXT:4 has_objc_symbol {{.*}} DATA
# OBJC-EMPTY:
# OBJC-NEXT: SYMBOL TABLE:
+# OBJC-DAG: g O __TEXT,__swift _foo
# OBJC-DAG: g F __TEXT,__text _main
# OBJC-DAG: g F __TEXT,__text _OBJC_CLASS_$_MyObject
# OBJC-DAG: g O __TEXT,__swift5_fieldmd $s7somelib4Blah_pMF
@@ -100,6 +103,20 @@ _has_dup:
.section __TEXT,__swift
.quad 0x1234
+#--- has-swift-ir-loaded.ll
+target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
+target triple = "x86_64-apple-darwin"
+
+@foo = global i64 1234, section "__TEXT,__swift"
+@llvm.used = appending global [1 x ptr] [ptr @foo]
+
+#--- has-swift-ir-not-loaded.ll
+target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
+target triple = "x86_64-apple-darwin"
+
+@bar = global i64 1234
+@llvm.used = appending global [1 x ptr] [ptr @bar]
+
#--- has-swift-proto.s
.section __TEXT,__swift5_fieldmd
.globl $s7somelib4Blah_pMF
diff --git a/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
b/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
index a027d0c21ba0b..db1bd457f83d1 100644
--- a/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
+++ b/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
@@ -294,7 +294,8 @@ static Expected
hasObjCCategoryInModule(BitstreamCursor ) {
return error("Invalid
[llvm-branch-commits] [lld] [llvm] release/18.x: [lld] Fix -ObjC load behavior with LTO (#92162) (PR #92478)
https://github.com/AtariDreams created
https://github.com/llvm/llvm-project/pull/92478
When -ObjC is passed, the linker must force load any object files that contain
special sections that store Objective-C / Swift information that is used at
runtime.
This should work regadless if input files are bitcode or native, but it was not
working with bitcode. This is because the sections that identify an object file
that should be loaded were inconsistent when dealing with a native file vs
bitcode file. In particular, bitcode files were not searched for
`__TEXT,__swift` prefixed sections, while native files were.
This means LLD wasn't loading certain bitcode files and forcing the user to
introduce --force-load to their linker invocation for that archive.
>From f32e6b29b8c805e897f64397ea5ea4f28174dc79 Mon Sep 17 00:00:00 2001
From: Nuri Amari
Date: Wed, 15 May 2024 09:21:02 -0700
Subject: [PATCH] [lld] Fix -ObjC load behavior with LTO (#92162)
When -ObjC is passed, the linker must force load any object files that
contain special sections that store Objective-C / Swift information that
is used at runtime.
This should work regadless if input files are bitcode or native, but it
was not working with bitcode. This is because the sections that identify
an object file that should be loaded were inconsistent when dealing with
a native file vs bitcode file. In particular, bitcode files were not
searched for `__TEXT,__swift` prefixed sections, while native files
were.
This means LLD wasn't loading certain bitcode files and forcing the user
to introduce --force-load to their linker invocation for that archive.
Co-authored-by: Nuri Amari
---
lld/test/MachO/objc.s | 23 ---
llvm/lib/Bitcode/Reader/BitcodeReader.cpp | 3 ++-
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/lld/test/MachO/objc.s b/lld/test/MachO/objc.s
index e7074141f0113..dbb9f1df27571 100644
--- a/lld/test/MachO/objc.s
+++ b/lld/test/MachO/objc.s
@@ -5,12 +5,14 @@
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin
%t/has-objc-category.s -o %t/has-objc-category.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin
%t/has-objc-symbol-and-category.s -o %t/has-objc-symbol-and-category.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/has-swift.s -o
%t/has-swift.o
+# RUN: llvm-as %t/has-swift-ir-loaded.ll -o %t/has-swift-ir-loaded.o
+# RUN: llvm-as %t/has-swift-ir-not-loaded.ll -o %t/has-swift-ir-not-loaded.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/has-swift-proto.s
-o %t/has-swift-proto.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/no-objc.s -o
%t/no-objc.o
## Make sure we don't mis-parse a 32-bit file as 64-bit
# RUN: llvm-mc -filetype=obj -triple=armv7-apple-watchos %t/no-objc.s -o
%t/wrong-arch.o
-# RUN: llvm-ar rcs %t/libHasSomeObjC.a %t/no-objc.o %t/has-objc-symbol.o
%t/has-objc-category.o %t/has-swift.o %t/has-swift-proto.o %t/wrong-arch.o
-# RUN: llvm-ar rcs %t/libHasSomeObjC2.a %t/no-objc.o
%t/has-objc-symbol-and-category.o %t/has-swift.o %t/has-swift-proto.o
%t/wrong-arch.o
+# RUN: llvm-ar rcs %t/libHasSomeObjC.a %t/no-objc.o %t/has-objc-symbol.o
%t/has-objc-category.o %t/has-swift.o %t/has-swift-proto.o
%t/has-swift-ir-loaded.o %t/has-swift-ir-not-loaded.o %t/wrong-arch.o
+# RUN: llvm-ar rcs %t/libHasSomeObjC2.a %t/no-objc.o
%t/has-objc-symbol-and-category.o %t/has-swift.o %t/has-swift-proto.o
%t/has-swift-ir-loaded.o %t/has-swift-ir-not-loaded.o %t/wrong-arch.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/test.s -o %t/test.o
@@ -20,7 +22,7 @@
# RUN: %lld -lSystem %t/test.o -o %t/test -L%t -lHasSomeObjC2 -ObjC
# RUN: llvm-objdump --section-headers --syms %t/test | FileCheck %s
--check-prefix=OBJC
-# RUN: %no-fatal-warnings-lld -lSystem %t/test.o -o %t/test --start-lib
%t/no-objc.o %t/has-objc-symbol.o %t/has-objc-category.o %t/has-swift.o
%t/has-swift-proto.o %t/wrong-arch.o --end-lib -ObjC 2>&1 \
+# RUN: %no-fatal-warnings-lld -lSystem %t/test.o -o %t/test --start-lib
%t/no-objc.o %t/has-objc-symbol.o %t/has-objc-category.o %t/has-swift.o
%t/has-swift-proto.o %t/has-swift-ir-loaded.o %t/has-swift-ir-not-loaded.o
%t/wrong-arch.o --end-lib -ObjC 2>&1 \
# RUN: | FileCheck -check-prefix=WARNING %s
# RUN: llvm-objdump --section-headers --syms %t/test | FileCheck %s
--check-prefix=OBJC
@@ -36,6 +38,7 @@
# OBJC-NEXT:4 has_objc_symbol {{.*}} DATA
# OBJC-EMPTY:
# OBJC-NEXT: SYMBOL TABLE:
+# OBJC-DAG: g O __TEXT,__swift _foo
# OBJC-DAG: g F __TEXT,__text _main
# OBJC-DAG: g F __TEXT,__text _OBJC_CLASS_$_MyObject
# OBJC-DAG: g O __TEXT,__swift5_fieldmd $s7somelib4Blah_pMF
@@ -100,6 +103,20 @@ _has_dup:
.section __TEXT,__swift
.quad 0x1234
+#--- has-swift-ir-loaded.ll
+target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
+target triple = "x86_64-apple-darwin"
+
+@foo = global i64 1234, section "__TEXT,__swift"
+@llvm.used =
[llvm-branch-commits] [LoongArch] Suppress the unnecessary extensions for arguments in makeLibCall (PR #92376)
https://github.com/wangleiat updated https://github.com/llvm/llvm-project/pull/92376 ___ 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] [LoongArch] Suppress the unnecessary extensions for arguments in makeLibCall (PR #92376)
https://github.com/wangleiat updated https://github.com/llvm/llvm-project/pull/92376 ___ 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] [LoongArch] Use sign extend for i32 arguments in makeLibCall on LA64 (PR #92375)
https://github.com/wangleiat updated https://github.com/llvm/llvm-project/pull/92375 ___ 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] [LoongArch] Use sign extend for i32 arguments in makeLibCall on LA64 (PR #92375)
https://github.com/wangleiat updated https://github.com/llvm/llvm-project/pull/92375 ___ 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: [GlobalOpt] Don't replace aliasee with alias that has weak linkage (#91483) (PR #92468)
DianQK wrote: Per https://github.com/llvm/llvm-project/pull/91483#issuecomment-2116394616, we still need to further investigate this issue, but it won't stop us from backporting it. cc @MaskRay https://github.com/llvm/llvm-project/pull/92468 ___ 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: [GlobalOpt] Don't replace aliasee with alias that has weak linkage (#91483) (PR #92468)
DianQK wrote: Release note (maybe): Do not replace an aliasee with an alias that has weak linkage, as this prevents the selection of incorrect symbols during the linking time. @tstellar https://github.com/llvm/llvm-project/pull/92468 ___ 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: [GlobalOpt] Don't replace aliasee with alias that has weak linkage (#91483) (PR #92468)
DianQK wrote: > As noted on the original pull request, this also affects some cases which > might be safe to optimize (a weak alias where the aliasee is an internal > symbol with no other references). But "optimizing" those cases doesn't really > have any useful effect, anyway: it doesn't unblock any additional > optimizations, and the resulting ELF is basically identical. Yes, and it looks like only this case can be optimized. I am not considering submitting this part of the change for now. But, I will add some comments and remove this `Ret` variable. https://github.com/llvm/llvm-project/pull/92468 ___ 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: [GlobalOpt] Don't replace aliasee with alias that has weak linkage (#91483) (PR #92468)
https://github.com/efriedma-quic approved this pull request. LGTM This only affects optimizations on weak aliases, and the logic is very simple: just don't optimize them. As noted on the original pull request, this also affects some cases which might be safe to optimize (a weak alias where the aliasee is an internal symbol with no other references). But "optimizing" those cases doesn't really have any useful effect, anyway: it doesn't unblock any additional optimizations, and the resulting ELF is basically identical. https://github.com/llvm/llvm-project/pull/92468 ___ 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: [GlobalOpt] Don't replace aliasee with alias that has weak linkage (#91483) (PR #92468)
llvmbot wrote:
@llvm/pr-subscribers-llvm-transforms
Author: None (llvmbot)
Changes
Backport c79690040acf5bb3d857558b0878db47f7f23dc3
Requested by: @DianQK
---
Full diff: https://github.com/llvm/llvm-project/pull/92468.diff
2 Files Affected:
- (modified) llvm/lib/Transforms/IPO/GlobalOpt.cpp (+3)
- (added) llvm/test/Transforms/GlobalOpt/alias-weak.ll (+57)
``diff
diff --git a/llvm/lib/Transforms/IPO/GlobalOpt.cpp
b/llvm/lib/Transforms/IPO/GlobalOpt.cpp
index 951372adcfa93..619b3f612f25f 100644
--- a/llvm/lib/Transforms/IPO/GlobalOpt.cpp
+++ b/llvm/lib/Transforms/IPO/GlobalOpt.cpp
@@ -2212,6 +2212,9 @@ static bool mayHaveOtherReferences(GlobalValue , const
LLVMUsed ) {
static bool hasUsesToReplace(GlobalAlias , const LLVMUsed ,
bool ) {
+ if (GA.isWeakForLinker())
+return false;
+
RenameTarget = false;
bool Ret = false;
if (hasUseOtherThanLLVMUsed(GA, U))
diff --git a/llvm/test/Transforms/GlobalOpt/alias-weak.ll
b/llvm/test/Transforms/GlobalOpt/alias-weak.ll
new file mode 100644
index 0..aec2a56313b12
--- /dev/null
+++ b/llvm/test/Transforms/GlobalOpt/alias-weak.ll
@@ -0,0 +1,57 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
UTC_ARGS: --check-globals all --include-generated-funcs --version 4
+; RUN: opt < %s -passes=globalopt -S | FileCheck %s
+
+@f1_alias = linkonce_odr hidden alias void (), ptr @f1
+@f2_alias = linkonce_odr hidden alias void (), ptr @f2
+
+define void @foo() {
+ call void @f1_alias()
+ ret void
+}
+
+define void @bar() {
+ call void @f1()
+ ret void
+}
+
+define void @baz() {
+ call void @f2_alias()
+ ret void
+}
+
+; We cannot use `f1_alias` to replace `f1` because they are both in use
+; and `f1_alias` could be replaced at link time.
+define internal void @f1() {
+ ret void
+}
+
+; FIXME: We can use `f2_alias` to replace `f2` because `b2` is not in use.
+define internal void @f2() {
+ ret void
+}
+;.
+; CHECK: @f1_alias = linkonce_odr hidden alias void (), ptr @f1
+; CHECK: @f2_alias = linkonce_odr hidden alias void (), ptr @f2
+;.
+; CHECK-LABEL: define void @foo() local_unnamed_addr {
+; CHECK-NEXT:call void @f1_alias()
+; CHECK-NEXT:ret void
+;
+;
+; CHECK-LABEL: define void @bar() local_unnamed_addr {
+; CHECK-NEXT:call void @f1()
+; CHECK-NEXT:ret void
+;
+;
+; CHECK-LABEL: define void @baz() local_unnamed_addr {
+; CHECK-NEXT:call void @f2_alias()
+; CHECK-NEXT:ret void
+;
+;
+; CHECK-LABEL: define internal void @f1() {
+; CHECK-NEXT:ret void
+;
+;
+; CHECK-LABEL: define internal void @f2() {
+; CHECK-NEXT:ret void
+;
``
https://github.com/llvm/llvm-project/pull/92468
___
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: [GlobalOpt] Don't replace aliasee with alias that has weak linkage (#91483) (PR #92468)
llvmbot wrote: @efriedma-quic What do you think about merging this PR to the release branch? https://github.com/llvm/llvm-project/pull/92468 ___ 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: [GlobalOpt] Don't replace aliasee with alias that has weak linkage (#91483) (PR #92468)
https://github.com/llvmbot milestoned https://github.com/llvm/llvm-project/pull/92468 ___ 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: [GlobalOpt] Don't replace aliasee with alias that has weak linkage (#91483) (PR #92468)
https://github.com/llvmbot created
https://github.com/llvm/llvm-project/pull/92468
Backport c79690040acf5bb3d857558b0878db47f7f23dc3
Requested by: @DianQK
>From 012e13b1594ba19058294d793993ad8da14c9159 Mon Sep 17 00:00:00 2001
From: DianQK
Date: Fri, 17 May 2024 05:51:49 +0800
Subject: [PATCH] [GlobalOpt] Don't replace aliasee with alias that has weak
linkage (#91483)
Fixes #91312.
Don't perform the transform if the alias may be replaced at link time.
(cherry picked from commit c79690040acf5bb3d857558b0878db47f7f23dc3)
---
llvm/lib/Transforms/IPO/GlobalOpt.cpp| 3 ++
llvm/test/Transforms/GlobalOpt/alias-weak.ll | 57
2 files changed, 60 insertions(+)
create mode 100644 llvm/test/Transforms/GlobalOpt/alias-weak.ll
diff --git a/llvm/lib/Transforms/IPO/GlobalOpt.cpp
b/llvm/lib/Transforms/IPO/GlobalOpt.cpp
index 951372adcfa93..619b3f612f25f 100644
--- a/llvm/lib/Transforms/IPO/GlobalOpt.cpp
+++ b/llvm/lib/Transforms/IPO/GlobalOpt.cpp
@@ -2212,6 +2212,9 @@ static bool mayHaveOtherReferences(GlobalValue , const
LLVMUsed ) {
static bool hasUsesToReplace(GlobalAlias , const LLVMUsed ,
bool ) {
+ if (GA.isWeakForLinker())
+return false;
+
RenameTarget = false;
bool Ret = false;
if (hasUseOtherThanLLVMUsed(GA, U))
diff --git a/llvm/test/Transforms/GlobalOpt/alias-weak.ll
b/llvm/test/Transforms/GlobalOpt/alias-weak.ll
new file mode 100644
index 0..aec2a56313b12
--- /dev/null
+++ b/llvm/test/Transforms/GlobalOpt/alias-weak.ll
@@ -0,0 +1,57 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
UTC_ARGS: --check-globals all --include-generated-funcs --version 4
+; RUN: opt < %s -passes=globalopt -S | FileCheck %s
+
+@f1_alias = linkonce_odr hidden alias void (), ptr @f1
+@f2_alias = linkonce_odr hidden alias void (), ptr @f2
+
+define void @foo() {
+ call void @f1_alias()
+ ret void
+}
+
+define void @bar() {
+ call void @f1()
+ ret void
+}
+
+define void @baz() {
+ call void @f2_alias()
+ ret void
+}
+
+; We cannot use `f1_alias` to replace `f1` because they are both in use
+; and `f1_alias` could be replaced at link time.
+define internal void @f1() {
+ ret void
+}
+
+; FIXME: We can use `f2_alias` to replace `f2` because `b2` is not in use.
+define internal void @f2() {
+ ret void
+}
+;.
+; CHECK: @f1_alias = linkonce_odr hidden alias void (), ptr @f1
+; CHECK: @f2_alias = linkonce_odr hidden alias void (), ptr @f2
+;.
+; CHECK-LABEL: define void @foo() local_unnamed_addr {
+; CHECK-NEXT:call void @f1_alias()
+; CHECK-NEXT:ret void
+;
+;
+; CHECK-LABEL: define void @bar() local_unnamed_addr {
+; CHECK-NEXT:call void @f1()
+; CHECK-NEXT:ret void
+;
+;
+; CHECK-LABEL: define void @baz() local_unnamed_addr {
+; CHECK-NEXT:call void @f2_alias()
+; CHECK-NEXT:ret void
+;
+;
+; CHECK-LABEL: define internal void @f1() {
+; CHECK-NEXT:ret void
+;
+;
+; CHECK-LABEL: define internal void @f2() {
+; CHECK-NEXT: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: [RISCV] Re-separate unaligned scalar and vector memory features in the backend. (PR #92143)
https://github.com/asb approved this pull request. https://github.com/llvm/llvm-project/pull/92143 ___ 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: [RISCV] Re-separate unaligned scalar and vector memory features in the backend. (PR #92143)
asb wrote: My thoughts: * Thanks to @negge and others for clarifying who this is affecting and how * It's very unfortunate we've broken some use cases here. Though as, by my understand, this is affecting people using internal flags as opposed to documented top-level flags I feel there's not a _strong_ obligation to fix the issue in a point release. * That said, if we can fix it with minimal risk of introducing more problems then it would be nice to do so as long as the release managers are happy * I think the solution of keeping fast-unaligned-access and adding +unaligned-scalar-mem is pragmatic * Patch LGTM. https://github.com/llvm/llvm-project/pull/92143 ___ 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: [RISCV] Re-separate unaligned scalar and vector memory features in the backend. (PR #92143)
tstellar wrote: @topperc The plan is to release Friday. Do we have agreement on merging this updated patch? https://github.com/llvm/llvm-project/pull/92143 ___ 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: [RISCV] Re-separate unaligned scalar and vector memory features in the backend. (PR #92143)
topperc wrote: > @topperc Can this be merged as is? There might not be time to get an updated > patch merged before the last release. I just pushed a modified patch. What is the timeline for the last release? https://github.com/llvm/llvm-project/pull/92143 ___ 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: [RISCV] Re-separate unaligned scalar and vector memory features in the backend. (PR #92143)
https://github.com/topperc edited https://github.com/llvm/llvm-project/pull/92143 ___ 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: [RISCV] Re-separate unaligned scalar and vector memory features in the backend. (PR #92143)
https://github.com/topperc updated
https://github.com/llvm/llvm-project/pull/92143
>From e18e442947da7801c915c04e34e397464eca5034 Mon Sep 17 00:00:00 2001
From: Craig Topper
Date: Thu, 16 May 2024 12:27:05 -0700
Subject: [PATCH] [RISCV] Add a unaligned-scalar-mem feature like we had in
clang 17.
This is ORed with the fast-unaligned-access feature which applies
to scalar and vector together.:
---
llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp | 5 +++--
llvm/lib/Target/RISCV/RISCVFeatures.td | 5 +
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 9 ++---
llvm/test/CodeGen/RISCV/memcpy-inline.ll | 4
llvm/test/CodeGen/RISCV/memcpy.ll| 4
llvm/test/CodeGen/RISCV/memset-inline.ll | 4
llvm/test/CodeGen/RISCV/pr56110.ll | 1 +
llvm/test/CodeGen/RISCV/unaligned-load-store.ll | 4
8 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp
b/llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp
index 0a314fdd41cbe..89207640ee54a 100644
--- a/llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp
+++ b/llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp
@@ -317,8 +317,9 @@ bool
RISCVExpandPseudo::expandRV32ZdinxStore(MachineBasicBlock ,
.addReg(MBBI->getOperand(1).getReg())
.add(MBBI->getOperand(2));
if (MBBI->getOperand(2).isGlobal() || MBBI->getOperand(2).isCPI()) {
-// FIXME: Zdinx RV32 can not work on unaligned memory.
-assert(!STI->hasFastUnalignedAccess());
+// FIXME: Zdinx RV32 can not work on unaligned scalar memory.
+assert(!STI->hasFastUnalignedAccess() &&
+ !STI->enableUnalignedScalarMem());
assert(MBBI->getOperand(2).getOffset() % 8 == 0);
MBBI->getOperand(2).setOffset(MBBI->getOperand(2).getOffset() + 4);
diff --git a/llvm/lib/Target/RISCV/RISCVFeatures.td
b/llvm/lib/Target/RISCV/RISCVFeatures.td
index 26451c80f57b4..1bb6b6a561f4a 100644
--- a/llvm/lib/Target/RISCV/RISCVFeatures.td
+++ b/llvm/lib/Target/RISCV/RISCVFeatures.td
@@ -1025,6 +1025,11 @@ def FeatureFastUnalignedAccess
"true", "Has reasonably performant unaligned "
"loads and stores (both scalar and vector)">;
+def FeatureUnalignedScalarMem
+ : SubtargetFeature<"unaligned-scalar-mem", "EnableUnalignedScalarMem",
+ "true", "Has reasonably performant unaligned scalar "
+ "loads and stores">;
+
def FeaturePostRAScheduler : SubtargetFeature<"use-postra-scheduler",
"UsePostRAScheduler", "true", "Schedule again after register allocation">;
diff --git a/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
b/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
index d46093b9e260a..3fe7ddfdd4279 100644
--- a/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
+++ b/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
@@ -1883,7 +1883,8 @@ bool
RISCVTargetLowering::shouldConvertConstantLoadToIntImm(const APInt ,
// replace. If we don't support unaligned scalar mem, prefer the constant
// pool.
// TODO: Can the caller pass down the alignment?
- if (!Subtarget.hasFastUnalignedAccess())
+ if (!Subtarget.hasFastUnalignedAccess() &&
+ !Subtarget.enableUnalignedScalarMem())
return true;
// Prefer to keep the load if it would require many instructions.
@@ -19772,8 +19773,10 @@ bool
RISCVTargetLowering::allowsMisalignedMemoryAccesses(
unsigned *Fast) const {
if (!VT.isVector()) {
if (Fast)
- *Fast = Subtarget.hasFastUnalignedAccess();
-return Subtarget.hasFastUnalignedAccess();
+ *Fast = Subtarget.hasFastUnalignedAccess() ||
+ Subtarget.enableUnalignedScalarMem();
+return Subtarget.hasFastUnalignedAccess() ||
+ Subtarget.enableUnalignedScalarMem();
}
// All vector implementations must support element alignment
diff --git a/llvm/test/CodeGen/RISCV/memcpy-inline.ll
b/llvm/test/CodeGen/RISCV/memcpy-inline.ll
index 343695ee37da8..709b8264b5833 100644
--- a/llvm/test/CodeGen/RISCV/memcpy-inline.ll
+++ b/llvm/test/CodeGen/RISCV/memcpy-inline.ll
@@ -7,6 +7,10 @@
; RUN: | FileCheck %s --check-prefixes=RV32-BOTH,RV32-FAST
; RUN: llc < %s -mtriple=riscv64 -mattr=+fast-unaligned-access \
; RUN: | FileCheck %s --check-prefixes=RV64-BOTH,RV64-FAST
+; RUN: llc < %s -mtriple=riscv32 -mattr=+unaligned-scalar-mem \
+; RUN: | FileCheck %s --check-prefixes=RV32-BOTH,RV32-FAST
+; RUN: llc < %s -mtriple=riscv64 -mattr=+unaligned-scalar-mem \
+; RUN: | FileCheck %s --check-prefixes=RV64-BOTH,RV64-FAST
; --
; Fully unaligned cases
diff --git a/llvm/test/CodeGen/RISCV/memcpy.ll
b/llvm/test/CodeGen/RISCV/memcpy.ll
index 12ec0881b20d9..f8f5d25947d7f 100644
--- a/llvm/test/CodeGen/RISCV/memcpy.ll
+++ b/llvm/test/CodeGen/RISCV/memcpy.ll
@@ -7,6 +7,10 @@
; RUN: | FileCheck %s --check-prefixes=RV32-BOTH,RV32-FAST
; RUN: llc < %s -mtriple=riscv64
[llvm-branch-commits] [libcxx] release/18.x: change the visibility of libc++ header to public in libcxx module (PR #91182)
tstellar wrote: Is there a similar change that is proposed for the main branch? https://github.com/llvm/llvm-project/pull/91182 ___ 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: [RISCV] Re-separate unaligned scalar and vector memory features in the backend. (PR #92143)
tstellar wrote: @topperc Can this be merged as is? There might not be time to get an updated patch merged before the last release. https://github.com/llvm/llvm-project/pull/92143 ___ 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: [InstCombine] Drop nuw flag when CtlzOp is a sub nuw (#91776) (PR #91917)
tstellar wrote: @dtcxzyw (or anyone else). If you would like to add a note about this fix in the release notes (completely optional). Please reply to this comment with a one or two sentence description of the fix. When you are done, please add the release:note label to this PR. https://github.com/llvm/llvm-project/pull/91917 ___ 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: [InstCombine] Drop nuw flag when CtlzOp is a sub nuw (#91776) (PR #91917)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/91917 ___ 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] 2a4a0bf - Update llvm/test/Transforms/InstCombine/bit_ceil.ll
Author: Tom Stellard
Date: 2024-05-16T11:42:50-07:00
New Revision: 2a4a0bf1db8b828f104123de52d9f9cace020ed0
URL:
https://github.com/llvm/llvm-project/commit/2a4a0bf1db8b828f104123de52d9f9cace020ed0
DIFF:
https://github.com/llvm/llvm-project/commit/2a4a0bf1db8b828f104123de52d9f9cace020ed0.diff
LOG: Update llvm/test/Transforms/InstCombine/bit_ceil.ll
Co-authored-by: Yingwei Zheng
Added:
Modified:
llvm/test/Transforms/InstCombine/bit_ceil.ll
Removed:
diff --git a/llvm/test/Transforms/InstCombine/bit_ceil.ll
b/llvm/test/Transforms/InstCombine/bit_ceil.ll
index 63a5ae012eeb6..2c459a8c9d6db 100644
--- a/llvm/test/Transforms/InstCombine/bit_ceil.ll
+++ b/llvm/test/Transforms/InstCombine/bit_ceil.ll
@@ -287,7 +287,7 @@ define <4 x i32> @bit_ceil_v4i32(<4 x i32> %x) {
define i32 @pr91691(i32 %0) {
; CHECK-LABEL: @pr91691(
; CHECK-NEXT:[[TMP2:%.*]] = sub i32 -2, [[TMP0:%.*]]
-; CHECK-NEXT:[[TMP3:%.*]] = tail call range(i32 0, 33) i32
@llvm.ctlz.i32(i32 [[TMP2]], i1 false)
+; CHECK-NEXT:[[TMP3:%.*]] = tail call i32 @llvm.ctlz.i32(i32 [[TMP2]], i1
false), !range [[RNG0]]
; CHECK-NEXT:[[TMP4:%.*]] = sub nsw i32 0, [[TMP3]]
; CHECK-NEXT:[[TMP5:%.*]] = and i32 [[TMP4]], 31
; CHECK-NEXT:[[TMP6:%.*]] = shl nuw i32 1, [[TMP5]]
@@ -305,7 +305,7 @@ define i32 @pr91691(i32 %0) {
define i32 @pr91691_keep_nsw(i32 %0) {
; CHECK-LABEL: @pr91691_keep_nsw(
; CHECK-NEXT:[[TMP2:%.*]] = sub nsw i32 -2, [[TMP0:%.*]]
-; CHECK-NEXT:[[TMP3:%.*]] = tail call range(i32 0, 33) i32
@llvm.ctlz.i32(i32 [[TMP2]], i1 false)
+; CHECK-NEXT:[[TMP3:%.*]] = tail call i32 @llvm.ctlz.i32(i32 [[TMP2]], i1
false), !range [[RNG0]]
; CHECK-NEXT:[[TMP4:%.*]] = sub nsw i32 0, [[TMP3]]
; CHECK-NEXT:[[TMP5:%.*]] = and i32 [[TMP4]], 31
; CHECK-NEXT:[[TMP6:%.*]] = shl nuw i32 1, [[TMP5]]
___
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] 26ccc6b - [InstCombine] Drop nuw flag when CtlzOp is a sub nuw (#91776)
Author: Yingwei Zheng
Date: 2024-05-16T11:42:50-07:00
New Revision: 26ccc6b5c1c73a92e5d08299065709e1d163b6c2
URL:
https://github.com/llvm/llvm-project/commit/26ccc6b5c1c73a92e5d08299065709e1d163b6c2
DIFF:
https://github.com/llvm/llvm-project/commit/26ccc6b5c1c73a92e5d08299065709e1d163b6c2.diff
LOG: [InstCombine] Drop nuw flag when CtlzOp is a sub nuw (#91776)
See the following case:
```
define i32 @src1(i32 %x) {
%dec = sub nuw i32 -2, %x
%ctlz = tail call i32 @llvm.ctlz.i32(i32 %dec, i1 false)
%sub = sub nsw i32 32, %ctlz
%shl = shl i32 1, %sub
%ugt = icmp ult i32 %x, -2
%sel = select i1 %ugt, i32 %shl, i32 1
ret i32 %sel
}
define i32 @tgt1(i32 %x) {
%dec = sub nuw i32 -2, %x
%ctlz = tail call i32 @llvm.ctlz.i32(i32 %dec, i1 false)
%sub = sub nsw i32 32, %ctlz
%and = and i32 %sub, 31
%shl = shl nuw i32 1, %and
ret i32 %shl
}
```
`nuw` in `%dec` should be dropped after the select instruction is
eliminated.
Alive2: https://alive2.llvm.org/ce/z/7S9529
Fixes https://github.com/llvm/llvm-project/issues/91691.
(cherry picked from commit b5f4210e9f51f938ae517f219f04f9ab431a2684)
Added:
Modified:
llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
llvm/test/Transforms/InstCombine/bit_ceil.ll
Removed:
diff --git a/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
b/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
index 8cc7901cbac7f..86a39cf2ee93f 100644
--- a/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
+++ b/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
@@ -3201,7 +3201,8 @@ Instruction
*InstCombinerImpl::foldSelectOfBools(SelectInst ) {
// pattern.
static bool isSafeToRemoveBitCeilSelect(ICmpInst::Predicate Pred, Value *Cond0,
const APInt *Cond1, Value *CtlzOp,
-unsigned BitWidth) {
+unsigned BitWidth,
+bool ) {
// The challenge in recognizing std::bit_ceil(X) is that the operand is used
// for the CTLZ proper and select condition, each possibly with some
// operation like add and sub.
@@ -3224,6 +3225,8 @@ static bool
isSafeToRemoveBitCeilSelect(ICmpInst::Predicate Pred, Value *Cond0,
ConstantRange CR = ConstantRange::makeExactICmpRegion(
CmpInst::getInversePredicate(Pred), *Cond1);
+ ShouldDropNUW = false;
+
// Match the operation that's used to compute CtlzOp from CommonAncestor. If
// CtlzOp == CommonAncestor, return true as no operation is needed. If a
// match is found, execute the operation on CR, update CR, and return true.
@@ -3237,6 +3240,7 @@ static bool
isSafeToRemoveBitCeilSelect(ICmpInst::Predicate Pred, Value *Cond0,
return true;
}
if (match(CtlzOp, m_Sub(m_APInt(C), m_Specific(CommonAncestor {
+ ShouldDropNUW = true;
CR = ConstantRange(*C).sub(CR);
return true;
}
@@ -3306,14 +3310,20 @@ static Instruction *foldBitCeil(SelectInst ,
IRBuilderBase ) {
Pred = CmpInst::getInversePredicate(Pred);
}
+ bool ShouldDropNUW;
+
if (!match(FalseVal, m_One()) ||
!match(TrueVal,
m_OneUse(m_Shl(m_One(), m_OneUse(m_Sub(m_SpecificInt(BitWidth),
m_Value(Ctlz)) ||
!match(Ctlz, m_Intrinsic(m_Value(CtlzOp), m_Zero())) ||
- !isSafeToRemoveBitCeilSelect(Pred, Cond0, Cond1, CtlzOp, BitWidth))
+ !isSafeToRemoveBitCeilSelect(Pred, Cond0, Cond1, CtlzOp, BitWidth,
+ ShouldDropNUW))
return nullptr;
+ if (ShouldDropNUW)
+cast(CtlzOp)->setHasNoUnsignedWrap(false);
+
// Build 1 << (-CTLZ & (BitWidth-1)). The negation likely corresponds to a
// single hardware instruction as opposed to BitWidth - CTLZ, where BitWidth
// is an integer constant. Masking with BitWidth-1 comes free on some
diff --git a/llvm/test/Transforms/InstCombine/bit_ceil.ll
b/llvm/test/Transforms/InstCombine/bit_ceil.ll
index 52e70c78ba542..63a5ae012eeb6 100644
--- a/llvm/test/Transforms/InstCombine/bit_ceil.ll
+++ b/llvm/test/Transforms/InstCombine/bit_ceil.ll
@@ -284,6 +284,42 @@ define <4 x i32> @bit_ceil_v4i32(<4 x i32> %x) {
ret <4 x i32> %sel
}
+define i32 @pr91691(i32 %0) {
+; CHECK-LABEL: @pr91691(
+; CHECK-NEXT:[[TMP2:%.*]] = sub i32 -2, [[TMP0:%.*]]
+; CHECK-NEXT:[[TMP3:%.*]] = tail call range(i32 0, 33) i32
@llvm.ctlz.i32(i32 [[TMP2]], i1 false)
+; CHECK-NEXT:[[TMP4:%.*]] = sub nsw i32 0, [[TMP3]]
+; CHECK-NEXT:[[TMP5:%.*]] = and i32 [[TMP4]], 31
+; CHECK-NEXT:[[TMP6:%.*]] = shl nuw i32 1, [[TMP5]]
+; CHECK-NEXT:ret i32 [[TMP6]]
+;
+ %2 = sub nuw i32 -2, %0
+ %3 = tail call i32 @llvm.ctlz.i32(i32 %2, i1 false)
+ %4 = sub i32 32, %3
+ %5 = shl i32 1, %4
+ %6 = icmp ult i32 %0, -2
+ %7 = select i1 %6, i32 %5, i32 1
+ ret i32 %7
+}
+
[llvm-branch-commits] [clang] [llvm] release/18.x: [RISCV] Re-separate unaligned scalar and vector memory features in the backend. (PR #92143)
topperc wrote: > I'm not strongly opposed to this or anything, but it feels questionable to be > doing a backport to change the target-feature syntax. My understand is that > these are purely internal names. This isn't a documented public interface. It isn't documented, but some users were using `-Xclang -target-feature -Xclang -unaligned-scalar-mem` with clang 17 to get this functionality. -mno-strict-align does not exist in clang 17. I'm going to experiment with reworking this patch to make `-Xclang -target-feature -Xclang -unaligned-scalar-mem` work and also leave `fast-unaligned-access` working to cover both scalar and vector. https://github.com/llvm/llvm-project/pull/92143 ___ 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: [RISCV] Re-separate unaligned scalar and vector memory features in the backend. (PR #92143)
preames wrote: I'm not strongly opposed to this or anything, but it feels questionable to be doing a backport to change the target-feature syntax. My understand is that these are purely internal names. This isn't a documented public interface. https://github.com/llvm/llvm-project/pull/92143 ___ 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: [RISCV] Re-separate unaligned scalar and vector memory features in the backend. (PR #92143)
negge wrote: I can confirm that bus error on unaligned vector access also happens on the recently released Banana Pi BPI-F3 when using clang-18.1.5. Note the BPI-F3 (https://docs.banana-pi.org/en/BPI-F3/BananaPi_BPI-F3) is a different SOC from the K230 and right now these are the only two devices available with the RISC-V Vector 1.0 extension. I expect other people will soon run into this issue. https://github.com/llvm/llvm-project/pull/92143 ___ 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] [LoongArch] Suppress the unnecessary extensions for arguments in makeLibCall (PR #92376)
https://github.com/SixWeining approved this pull request. https://github.com/llvm/llvm-project/pull/92376 ___ 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] [LoongArch] Use sign extend for i32 arguments in makeLibCall on LA64 (PR #92375)
https://github.com/SixWeining approved this pull request. LGTM. I think this fix should be check-picked to 18.x. https://github.com/llvm/llvm-project/pull/92375 ___ 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] [LoongArch] Suppress the unnecessary extensions for arguments in makeLibCall (PR #92376)
https://github.com/heiher approved this pull request. https://github.com/llvm/llvm-project/pull/92376 ___ 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] [LoongArch] Use sign extend for i32 arguments in makeLibCall on LA64 (PR #92375)
https://github.com/heiher approved this pull request. https://github.com/llvm/llvm-project/pull/92375 ___ 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] [LoongArch] Use sign extend for i32 arguments in makeLibCall on LA64 (PR #92375)
llvmbot wrote:
@llvm/pr-subscribers-backend-loongarch
Author: wanglei (wangleiat)
Changes
The 32 bits arguments and returns on LA64 are always sign extended to
i64. So we should be taking this into account around libcalls.
---
Full diff: https://github.com/llvm/llvm-project/pull/92375.diff
6 Files Affected:
- (modified) llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp (+8)
- (modified) llvm/lib/Target/LoongArch/LoongArchISelLowering.h (+1)
- (modified) llvm/test/CodeGen/LoongArch/calling-conv-lp64s.ll (+1-1)
- (modified) llvm/test/CodeGen/LoongArch/libcall-extend.ll (-3)
- (modified) llvm/test/CodeGen/LoongArch/sextw-removal.ll (+8-8)
- (modified) llvm/test/CodeGen/LoongArch/soft-fp-to-int.ll (+1-1)
``diff
diff --git a/llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp
b/llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp
index 6740563b90b45..6a0db9c27defe 100644
--- a/llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp
+++ b/llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp
@@ -4983,3 +4983,11 @@ ISD::NodeType
LoongArchTargetLowering::getExtendForAtomicCmpSwapArg() const {
// TODO: LAMCAS will use amcas{_DB,}.[bhwd] which does not require extension.
return ISD::SIGN_EXTEND;
}
+
+bool LoongArchTargetLowering::shouldSignExtendTypeInLibCall(
+EVT Type, bool IsSigned) const {
+ if (Subtarget.is64Bit() && Type == MVT::i32)
+return true;
+
+ return IsSigned;
+}
diff --git a/llvm/lib/Target/LoongArch/LoongArchISelLowering.h
b/llvm/lib/Target/LoongArch/LoongArchISelLowering.h
index 31b4d65195634..a344eadee8667 100644
--- a/llvm/lib/Target/LoongArch/LoongArchISelLowering.h
+++ b/llvm/lib/Target/LoongArch/LoongArchISelLowering.h
@@ -239,6 +239,7 @@ class LoongArchTargetLowering : public TargetLowering {
return false;
}
bool shouldConsiderGEPOffsetSplit() const override { return true; }
+ bool shouldSignExtendTypeInLibCall(EVT Type, bool IsSigned) const override;
private:
/// Target-specific function used to lower LoongArch calling conventions.
diff --git a/llvm/test/CodeGen/LoongArch/calling-conv-lp64s.ll
b/llvm/test/CodeGen/LoongArch/calling-conv-lp64s.ll
index f577435114967..184ba7363e1b3 100644
--- a/llvm/test/CodeGen/LoongArch/calling-conv-lp64s.ll
+++ b/llvm/test/CodeGen/LoongArch/calling-conv-lp64s.ll
@@ -10,7 +10,7 @@ define i64 @callee_float_in_regs(i64 %a, float %b) nounwind {
; CHECK-NEXT:st.d $ra, $sp, 8 # 8-byte Folded Spill
; CHECK-NEXT:st.d $fp, $sp, 0 # 8-byte Folded Spill
; CHECK-NEXT:move $fp, $a0
-; CHECK-NEXT:bstrpick.d $a0, $a1, 31, 0
+; CHECK-NEXT:addi.w $a0, $a1, 0
; CHECK-NEXT:bl %plt(__fixsfdi)
; CHECK-NEXT:add.d $a0, $fp, $a0
; CHECK-NEXT:ld.d $fp, $sp, 0 # 8-byte Folded Reload
diff --git a/llvm/test/CodeGen/LoongArch/libcall-extend.ll
b/llvm/test/CodeGen/LoongArch/libcall-extend.ll
index 957a15141802d..3cc8a6645f368 100644
--- a/llvm/test/CodeGen/LoongArch/libcall-extend.ll
+++ b/llvm/test/CodeGen/LoongArch/libcall-extend.ll
@@ -8,7 +8,6 @@ define signext i32 @convert_float_to_i32(i32 %tmp, float %a)
nounwind {
; CHECK-NEXT:st.d $ra, $sp, 8 # 8-byte Folded Spill
; CHECK-NEXT:bstrpick.d $a0, $a1, 31, 0
; CHECK-NEXT:bl %plt(__fixsfsi)
-; CHECK-NEXT:addi.w $a0, $a0, 0
; CHECK-NEXT:ld.d $ra, $sp, 8 # 8-byte Folded Reload
; CHECK-NEXT:addi.d $sp, $sp, 16
; CHECK-NEXT:ret
@@ -23,7 +22,6 @@ define signext i32 @convert_double_to_i32(i32 %tmp, double
%a) nounwind {
; CHECK-NEXT:st.d $ra, $sp, 8 # 8-byte Folded Spill
; CHECK-NEXT:move $a0, $a1
; CHECK-NEXT:bl %plt(__fixdfsi)
-; CHECK-NEXT:addi.w $a0, $a0, 0
; CHECK-NEXT:ld.d $ra, $sp, 8 # 8-byte Folded Reload
; CHECK-NEXT:addi.d $sp, $sp, 16
; CHECK-NEXT:ret
@@ -39,7 +37,6 @@ define signext i32 @convert_fp128_to_i32(i32 %tmp, fp128 %a)
nounwind {
; CHECK-NEXT:move $a0, $a1
; CHECK-NEXT:move $a1, $a2
; CHECK-NEXT:bl %plt(__fixtfsi)
-; CHECK-NEXT:addi.w $a0, $a0, 0
; CHECK-NEXT:ld.d $ra, $sp, 8 # 8-byte Folded Reload
; CHECK-NEXT:addi.d $sp, $sp, 16
; CHECK-NEXT:ret
diff --git a/llvm/test/CodeGen/LoongArch/sextw-removal.ll
b/llvm/test/CodeGen/LoongArch/sextw-removal.ll
index 7708873e264d9..c9f3ed5237aa1 100644
--- a/llvm/test/CodeGen/LoongArch/sextw-removal.ll
+++ b/llvm/test/CodeGen/LoongArch/sextw-removal.ll
@@ -257,11 +257,11 @@ define void @test6(i32 signext %arg, i32 signext %arg1)
nounwind {
; CHECK-NEXT:# =>This Inner Loop Header: Depth=1
; CHECK-NEXT:addi.w $a0, $fp, 0
; CHECK-NEXT:bl %plt(baz)
-; CHECK-NEXT:bstrpick.d $s0, $a0, 31, 0
-; CHECK-NEXT:move $a0, $s0
+; CHECK-NEXT:move $s0, $a0
+; CHECK-NEXT:bstrpick.d $a0, $a0, 31, 0
; CHECK-NEXT:bl %plt(__fixsfsi)
; CHECK-NEXT:move $fp, $a0
-; CHECK-NEXT:move $a0, $s0
+; CHECK-NEXT:addi.w $a0, $s0, 0
; CHECK-NEXT:move $a1, $zero
; CHECK-NEXT:bl %plt(__nesf2)
; CHECK-NEXT:bnez $a0, .LBB5_1
@@ -284,11 +284,11 @@
[llvm-branch-commits] [LoongArch] Suppress the unnecessary extensions for arguments in makeLibCall (PR #92376)
llvmbot wrote:
@llvm/pr-subscribers-backend-loongarch
Author: wanglei (wangleiat)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/92376.diff
7 Files Affected:
- (modified) llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp (+9)
- (modified) llvm/lib/Target/LoongArch/LoongArchISelLowering.h (+1)
- (modified) llvm/lib/Target/LoongArch/LoongArchSubtarget.h (+4)
- (modified) llvm/test/CodeGen/LoongArch/calling-conv-lp64s.ll (+1-1)
- (modified) llvm/test/CodeGen/LoongArch/libcall-extend.ll (+1-1)
- (modified) llvm/test/CodeGen/LoongArch/sextw-removal.ll (+2-6)
- (modified) llvm/test/CodeGen/LoongArch/soft-fp-to-int.ll (-2)
``diff
diff --git a/llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp
b/llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp
index 6a0db9c27defe..fe2c613b1b30f 100644
--- a/llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp
+++ b/llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp
@@ -4991,3 +4991,12 @@ bool
LoongArchTargetLowering::shouldSignExtendTypeInLibCall(
return IsSigned;
}
+
+bool LoongArchTargetLowering::shouldExtendTypeInLibCall(EVT Type) const {
+ // Return false to suppress the unnecessary extensions if the LibCall
+ // arguments or return value is a float narrower than GRLEN on a soft FP ABI.
+ if (Subtarget.isSoftFPABI() && (Type.isFloatingPoint() && !Type.isVector() &&
+ Type.getSizeInBits() < Subtarget.getGRLen()))
+return false;
+ return true;
+}
diff --git a/llvm/lib/Target/LoongArch/LoongArchISelLowering.h
b/llvm/lib/Target/LoongArch/LoongArchISelLowering.h
index a344eadee8667..de3f45172e25a 100644
--- a/llvm/lib/Target/LoongArch/LoongArchISelLowering.h
+++ b/llvm/lib/Target/LoongArch/LoongArchISelLowering.h
@@ -240,6 +240,7 @@ class LoongArchTargetLowering : public TargetLowering {
}
bool shouldConsiderGEPOffsetSplit() const override { return true; }
bool shouldSignExtendTypeInLibCall(EVT Type, bool IsSigned) const override;
+ bool shouldExtendTypeInLibCall(EVT Type) const override;
private:
/// Target-specific function used to lower LoongArch calling conventions.
diff --git a/llvm/lib/Target/LoongArch/LoongArchSubtarget.h
b/llvm/lib/Target/LoongArch/LoongArchSubtarget.h
index bfdfdcf36d66e..b87ea6e2ec32b 100644
--- a/llvm/lib/Target/LoongArch/LoongArchSubtarget.h
+++ b/llvm/lib/Target/LoongArch/LoongArchSubtarget.h
@@ -91,6 +91,10 @@ class LoongArchSubtarget : public LoongArchGenSubtargetInfo {
MVT getGRLenVT() const { return GRLenVT; }
unsigned getGRLen() const { return GRLen; }
LoongArchABI::ABI getTargetABI() const { return TargetABI; }
+ bool isSoftFPABI() const {
+return TargetABI == LoongArchABI::ABI_LP64S ||
+ TargetABI == LoongArchABI::ABI_ILP32S;
+ }
bool isXRaySupported() const override { return is64Bit(); }
Align getPrefFunctionAlignment() const { return PrefFunctionAlignment; }
Align getPrefLoopAlignment() const { return PrefLoopAlignment; }
diff --git a/llvm/test/CodeGen/LoongArch/calling-conv-lp64s.ll
b/llvm/test/CodeGen/LoongArch/calling-conv-lp64s.ll
index 184ba7363e1b3..8158c387f7b6b 100644
--- a/llvm/test/CodeGen/LoongArch/calling-conv-lp64s.ll
+++ b/llvm/test/CodeGen/LoongArch/calling-conv-lp64s.ll
@@ -10,7 +10,7 @@ define i64 @callee_float_in_regs(i64 %a, float %b) nounwind {
; CHECK-NEXT:st.d $ra, $sp, 8 # 8-byte Folded Spill
; CHECK-NEXT:st.d $fp, $sp, 0 # 8-byte Folded Spill
; CHECK-NEXT:move $fp, $a0
-; CHECK-NEXT:addi.w $a0, $a1, 0
+; CHECK-NEXT:move $a0, $a1
; CHECK-NEXT:bl %plt(__fixsfdi)
; CHECK-NEXT:add.d $a0, $fp, $a0
; CHECK-NEXT:ld.d $fp, $sp, 0 # 8-byte Folded Reload
diff --git a/llvm/test/CodeGen/LoongArch/libcall-extend.ll
b/llvm/test/CodeGen/LoongArch/libcall-extend.ll
index 3cc8a6645f368..7ca69811a7d57 100644
--- a/llvm/test/CodeGen/LoongArch/libcall-extend.ll
+++ b/llvm/test/CodeGen/LoongArch/libcall-extend.ll
@@ -6,7 +6,7 @@ define signext i32 @convert_float_to_i32(i32 %tmp, float %a)
nounwind {
; CHECK: # %bb.0:
; CHECK-NEXT:addi.d $sp, $sp, -16
; CHECK-NEXT:st.d $ra, $sp, 8 # 8-byte Folded Spill
-; CHECK-NEXT:bstrpick.d $a0, $a1, 31, 0
+; CHECK-NEXT:move $a0, $a1
; CHECK-NEXT:bl %plt(__fixsfsi)
; CHECK-NEXT:ld.d $ra, $sp, 8 # 8-byte Folded Reload
; CHECK-NEXT:addi.d $sp, $sp, 16
diff --git a/llvm/test/CodeGen/LoongArch/sextw-removal.ll
b/llvm/test/CodeGen/LoongArch/sextw-removal.ll
index c9f3ed5237aa1..d95a5bd298f58 100644
--- a/llvm/test/CodeGen/LoongArch/sextw-removal.ll
+++ b/llvm/test/CodeGen/LoongArch/sextw-removal.ll
@@ -258,10 +258,9 @@ define void @test6(i32 signext %arg, i32 signext %arg1)
nounwind {
; CHECK-NEXT:addi.w $a0, $fp, 0
; CHECK-NEXT:bl %plt(baz)
; CHECK-NEXT:move $s0, $a0
-; CHECK-NEXT:bstrpick.d $a0, $a0, 31, 0
; CHECK-NEXT:bl %plt(__fixsfsi)
; CHECK-NEXT:move $fp, $a0
-; CHECK-NEXT:addi.w $a0, $s0, 0
+; CHECK-NEXT:move $a0, $s0
;
[llvm-branch-commits] [LoongArch] Suppress the unnecessary extensions for arguments in makeLibCall (PR #92376)
https://github.com/wangleiat created https://github.com/llvm/llvm-project/pull/92376 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] [LoongArch] Use sign extend for i32 arguments in makeLibCall on LA64 (PR #92375)
https://github.com/wangleiat created https://github.com/llvm/llvm-project/pull/92375 The 32 bits arguments and returns on LA64 are always sign extended to i64. So we should be taking this into account around libcalls. ___ 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] [LoongArch] Refactor LoongArchABI::computeTargetABI (PR #92223)
https://github.com/xen0n approved this pull request. https://github.com/llvm/llvm-project/pull/92223 ___ 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] [LoongArch] Refactor LoongArchABI::computeTargetABI (PR #92223)
https://github.com/SixWeining approved this pull request. https://github.com/llvm/llvm-project/pull/92223 ___ 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] [LoongArch] Refactor LoongArchABI::computeTargetABI (PR #92223)
https://github.com/wangleiat updated https://github.com/llvm/llvm-project/pull/92223 ___ 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] [LoongArch] Refactor LoongArchABI::computeTargetABI (PR #92223)
https://github.com/wangleiat updated https://github.com/llvm/llvm-project/pull/92223 ___ 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] [LoongArch] Refactor LoongArchABI::computeTargetABI (PR #92223)
@@ -49,63 +50,127 @@ static ABI checkABIStandardized(ABI Abi) {
return Abi;
}
-ABI computeTargetABI(const Triple , StringRef ABIName) {
- ABI ArgProvidedABI = getTargetABI(ABIName);
+static ABI getTripleABI(const Triple ) {
bool Is64Bit = TT.isArch64Bit();
ABI TripleABI;
-
- // Figure out the ABI explicitly requested via the triple's environment type.
switch (TT.getEnvironment()) {
case llvm::Triple::EnvironmentType::GNUSF:
-TripleABI = Is64Bit ? LoongArchABI::ABI_LP64S : LoongArchABI::ABI_ILP32S;
+TripleABI = Is64Bit ? ABI_LP64S : ABI_ILP32S;
break;
case llvm::Triple::EnvironmentType::GNUF32:
-TripleABI = Is64Bit ? LoongArchABI::ABI_LP64F : LoongArchABI::ABI_ILP32F;
+TripleABI = Is64Bit ? ABI_LP64F : ABI_ILP32F;
break;
-
// Let the fallback case behave like {ILP32,LP64}D.
case llvm::Triple::EnvironmentType::GNUF64:
default:
-TripleABI = Is64Bit ? LoongArchABI::ABI_LP64D : LoongArchABI::ABI_ILP32D;
+TripleABI = Is64Bit ? ABI_LP64D : ABI_ILP32D;
break;
}
+ return TripleABI;
+}
- switch (ArgProvidedABI) {
- case LoongArchABI::ABI_Unknown:
-// Fallback to the triple-implied ABI if ABI name is not specified or
-// invalid.
-if (!ABIName.empty())
- errs() << "'" << ABIName
- << "' is not a recognized ABI for this target, ignoring and using
"
-"triple-implied ABI\n";
-return checkABIStandardized(TripleABI);
+ABI computeTargetABI(const Triple , const FeatureBitset ,
+ StringRef ABIName) {
+ bool Is64Bit = TT.isArch64Bit();
+ ABI ArgProvidedABI = getTargetABI(ABIName);
+ ABI TripleABI = getTripleABI(TT);
+
+ auto GetFeatureABI = [=]() {
SixWeining wrote:
Maybe move it to where it is called (i.e. line 173) for better readability?
https://github.com/llvm/llvm-project/pull/92223
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
