[llvm-branch-commits] [clang] release/19.x: [C++20] [Modules] Fix the duplicated static initializer problem (#114193) (PR #114197)
ChuanqiXu9 wrote: > @ChuanqiXu9 is this one ready to be merged? Yes, I believe this is ready to be merged. https://github.com/llvm/llvm-project/pull/114197 ___ 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] 16d9aa3 - Revert "[PowerPC] Add error for incorrect use of memory operands (#114277)"
Author: Jake Egan
Date: 2024-11-12T03:44:08-05:00
New Revision: 16d9aa346bab9afbaceb45a836f4721c24d012b2
URL:
https://github.com/llvm/llvm-project/commit/16d9aa346bab9afbaceb45a836f4721c24d012b2
DIFF:
https://github.com/llvm/llvm-project/commit/16d9aa346bab9afbaceb45a836f4721c24d012b2.diff
LOG: Revert "[PowerPC] Add error for incorrect use of memory operands (#114277)"
This reverts commit 93589057830b2c3c35500ee8cac25c717a1e98f9.
Added:
Modified:
llvm/lib/Target/PowerPC/AsmParser/PPCAsmParser.cpp
llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h
llvm/lib/Target/PowerPC/PPCInstr64Bit.td
llvm/lib/Target/PowerPC/PPCInstrFormats.td
llvm/lib/Target/PowerPC/PPCInstrInfo.h
llvm/lib/Target/PowerPC/PPCInstrInfo.td
llvm/lib/Target/PowerPC/PPCInstrP10.td
llvm/lib/Target/PowerPC/PPCInstrSPE.td
llvm/test/CodeGen/PowerPC/2007-01-31-InlineAsmAddrMode.ll
llvm/test/CodeGen/PowerPC/2009-07-16-InlineAsm-M-Operand.ll
llvm/test/MC/PowerPC/ppc64-errors.s
Removed:
diff --git a/llvm/lib/Target/PowerPC/AsmParser/PPCAsmParser.cpp
b/llvm/lib/Target/PowerPC/AsmParser/PPCAsmParser.cpp
index 52cc8f82f50b6e..abb6bd31c9c599 100644
--- a/llvm/lib/Target/PowerPC/AsmParser/PPCAsmParser.cpp
+++ b/llvm/lib/Target/PowerPC/AsmParser/PPCAsmParser.cpp
@@ -8,7 +8,6 @@
#include "MCTargetDesc/PPCMCExpr.h"
#include "MCTargetDesc/PPCMCTargetDesc.h"
-#include "PPCInstrInfo.h"
#include "PPCTargetStreamer.h"
#include "TargetInfo/PowerPCTargetInfo.h"
#include "llvm/ADT/STLExtras.h"
@@ -183,7 +182,6 @@ struct PPCOperand : public MCParsedAsmOperand {
struct ImmOp {
int64_t Val;
-bool IsMemOpBase;
};
struct ExprOp {
@@ -244,9 +242,6 @@ struct PPCOperand : public MCParsedAsmOperand {
/// isPPC64 - True if this operand is for an instruction in 64-bit mode.
bool isPPC64() const { return IsPPC64; }
- /// isMemOpBase - True if this operand is the base of a memory operand.
- bool isMemOpBase() const { return Kind == Immediate && Imm.IsMemOpBase; }
-
int64_t getImm() const {
assert(Kind == Immediate && "Invalid access!");
return Imm.Val;
@@ -699,11 +694,9 @@ struct PPCOperand : public MCParsedAsmOperand {
}
static std::unique_ptr CreateImm(int64_t Val, SMLoc S, SMLoc E,
- bool IsPPC64,
- bool IsMemOpBase = false) {
+ bool IsPPC64) {
auto Op = std::make_unique(Immediate);
Op->Imm.Val = Val;
-Op->Imm.IsMemOpBase = IsMemOpBase;
Op->StartLoc = S;
Op->EndLoc = E;
Op->IsPPC64 = IsPPC64;
@@ -1257,29 +1250,14 @@ void PPCAsmParser::processInstruction(MCInst &Inst,
static std::string PPCMnemonicSpellCheck(StringRef S, const FeatureBitset &FBS,
unsigned VariantID = 0);
-// Check that the register+immediate memory operand is in the right position
and
-// is expected by the instruction. Returns true if the memory operand syntax is
-// valid; otherwise, returns false.
-static bool validateMemOp(const OperandVector &Operands, bool isMemriOp) {
- for (size_t idx = 0; idx < Operands.size(); ++idx) {
-const PPCOperand &Op = static_cast(*Operands[idx]);
-if (Op.isMemOpBase() != (idx == 3 && isMemriOp))
- return false;
- }
- return true;
-}
-
bool PPCAsmParser::matchAndEmitInstruction(SMLoc IDLoc, unsigned &Opcode,
OperandVector &Operands,
MCStreamer &Out, uint64_t
&ErrorInfo,
bool MatchingInlineAsm) {
MCInst Inst;
- const PPCInstrInfo *TII = static_cast(&MII);
switch (MatchInstructionImpl(Operands, Inst, ErrorInfo, MatchingInlineAsm)) {
case Match_Success:
-if (!validateMemOp(Operands, TII->isMemriOp(Inst.getOpcode(
- return Error(IDLoc, "invalid operand for instruction");
// Post-process instructions (typically extended mnemonics)
processInstruction(Inst, Operands);
Inst.setLoc(IDLoc);
@@ -1637,8 +1615,7 @@ bool PPCAsmParser::parseOperand(OperandVector &Operands) {
E = Parser.getTok().getLoc();
if (parseToken(AsmToken::RParen, "missing ')'"))
return true;
-Operands.push_back(
-PPCOperand::CreateImm(IntVal, S, E, isPPC64(), /*IsMemOpBase=*/true));
+Operands.push_back(PPCOperand::CreateImm(IntVal, S, E, isPPC64()));
}
return false;
diff --git a/llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h
b/llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h
index 579ee5e8facb60..1625990aa1 100644
--- a/llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h
+++ b/llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h
@@ -171,9 +171,7 @@ enum {
/// This instruction produced a sign extended result.
SExt32To64 = 0x1 << (NewDef_Shif
[llvm-branch-commits] [llvm] release/19.x: [llvm] Fix __builtin_object_size interaction between Negative Offset … (#111827) (PR #114786)
nikic wrote: Yeah, I don't think we should backport this. A backportable variant of this fix would be to disable the phi handling entirely. https://github.com/llvm/llvm-project/pull/114786 ___ 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/19.x: [loongarch][DAG][FREEZE] Fix crash when FREEZE a half(f16) type on loongarch (#107791) (PR #109093)
nikic wrote: I'd still prefer not to backport this. We're changing many targets to use softPromoteHalfType in LLVM 20 (hopefully all if someone gets around to it...), with the ABI changes that implies. I don't think it makes sense to backport this just for loongarch, and I also don't want to backport this for all targets where this change is made. https://github.com/llvm/llvm-project/pull/109093 ___ 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] [libcxxabi] release/19.x: [libc++] Fix broken configuration system-libcxxabi on Apple (#110920) (PR #115892)
https://github.com/llvmbot milestoned https://github.com/llvm/llvm-project/pull/115892 ___ 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/19.x: [llvm] Fix __builtin_object_size interaction between Negative Offset … (#111827) (PR #114786)
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/114786
>From fb70629e196c516ebd5083f8624ba614f746ef67 Mon Sep 17 00:00:00 2001
From: serge-sans-paille
Date: Sat, 2 Nov 2024 09:14:35 +
Subject: [PATCH 1/2] =?UTF-8?q?[llvm]=20Fix=20=5F=5Fbuiltin=5Fobject=5Fsiz?=
=?UTF-8?q?e=20interaction=20between=20Negative=20Offset=20=E2=80=A6=20(#1?=
=?UTF-8?q?11827)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
…and Select/Phi
When picking a SizeOffsetAPInt through combineSizeOffset, the behavior
differs if we're going to apply a constant offset that's positive or
negative: If it's positive, then we need to compare the remaining bytes
(i.e. Size
- Offset), but if it's negative, we need to compare the preceding bytes
(i.e. Offset).
Fix #111709
(cherry picked from commit 01a103b0b9c449e8dec17950835991757d1c4f88)
---
llvm/include/llvm/Analysis/MemoryBuiltins.h | 71 +++--
llvm/lib/Analysis/MemoryBuiltins.cpp | 145 +-
.../builtin-object-size-phi.ll| 254 ++
.../objectsize_basic.ll | 24 ++
4 files changed, 405 insertions(+), 89 deletions(-)
diff --git a/llvm/include/llvm/Analysis/MemoryBuiltins.h
b/llvm/include/llvm/Analysis/MemoryBuiltins.h
index bb282a1b73d320..a21f116db7e70d 100644
--- a/llvm/include/llvm/Analysis/MemoryBuiltins.h
+++ b/llvm/include/llvm/Analysis/MemoryBuiltins.h
@@ -222,21 +222,43 @@ struct SizeOffsetAPInt : public SizeOffsetType {
static bool known(const APInt &V) { return V.getBitWidth() > 1; }
};
+/// OffsetSpan - Used internally by \p ObjectSizeOffsetVisitor. Represents a
+/// point in memory as a pair of allocated bytes before and after it.
+struct OffsetSpan {
+ APInt Before; /// Number of allocated bytes before this point.
+ APInt After; /// Number of allocated bytes after this point.
+
+ OffsetSpan() = default;
+ OffsetSpan(APInt Before, APInt After) : Before(Before), After(After) {}
+
+ bool knownBefore() const { return known(Before); }
+ bool knownAfter() const { return known(After); }
+ bool anyKnown() const { return knownBefore() || knownAfter(); }
+ bool bothKnown() const { return knownBefore() && knownAfter(); }
+
+ bool operator==(const OffsetSpan &RHS) const {
+return Before == RHS.Before && After == RHS.After;
+ }
+ bool operator!=(const OffsetSpan &RHS) const { return !(*this == RHS); }
+
+ static bool known(const APInt &V) { return V.getBitWidth() > 1; }
+};
+
/// Evaluate the size and offset of an object pointed to by a Value*
/// statically. Fails if size or offset are not known at compile time.
class ObjectSizeOffsetVisitor
-: public InstVisitor {
+: public InstVisitor {
const DataLayout &DL;
const TargetLibraryInfo *TLI;
ObjectSizeOpts Options;
unsigned IntTyBits;
APInt Zero;
- SmallDenseMap SeenInsts;
+ SmallDenseMap SeenInsts;
unsigned InstructionsVisited;
APInt align(APInt Size, MaybeAlign Align);
- static SizeOffsetAPInt unknown() { return SizeOffsetAPInt(); }
+ static OffsetSpan unknown() { return OffsetSpan(); }
public:
ObjectSizeOffsetVisitor(const DataLayout &DL, const TargetLibraryInfo *TLI,
@@ -246,29 +268,30 @@ class ObjectSizeOffsetVisitor
// These are "private", except they can't actually be made private. Only
// compute() should be used by external users.
- SizeOffsetAPInt visitAllocaInst(AllocaInst &I);
- SizeOffsetAPInt visitArgument(Argument &A);
- SizeOffsetAPInt visitCallBase(CallBase &CB);
- SizeOffsetAPInt visitConstantPointerNull(ConstantPointerNull &);
- SizeOffsetAPInt visitExtractElementInst(ExtractElementInst &I);
- SizeOffsetAPInt visitExtractValueInst(ExtractValueInst &I);
- SizeOffsetAPInt visitGlobalAlias(GlobalAlias &GA);
- SizeOffsetAPInt visitGlobalVariable(GlobalVariable &GV);
- SizeOffsetAPInt visitIntToPtrInst(IntToPtrInst &);
- SizeOffsetAPInt visitLoadInst(LoadInst &I);
- SizeOffsetAPInt visitPHINode(PHINode &);
- SizeOffsetAPInt visitSelectInst(SelectInst &I);
- SizeOffsetAPInt visitUndefValue(UndefValue &);
- SizeOffsetAPInt visitInstruction(Instruction &I);
+ OffsetSpan visitAllocaInst(AllocaInst &I);
+ OffsetSpan visitArgument(Argument &A);
+ OffsetSpan visitCallBase(CallBase &CB);
+ OffsetSpan visitConstantPointerNull(ConstantPointerNull &);
+ OffsetSpan visitExtractElementInst(ExtractElementInst &I);
+ OffsetSpan visitExtractValueInst(ExtractValueInst &I);
+ OffsetSpan visitGlobalAlias(GlobalAlias &GA);
+ OffsetSpan visitGlobalVariable(GlobalVariable &GV);
+ OffsetSpan visitIntToPtrInst(IntToPtrInst &);
+ OffsetSpan visitLoadInst(LoadInst &I);
+ OffsetSpan visitPHINode(PHINode &);
+ OffsetSpan visitSelectInst(SelectInst &I);
+ OffsetSpan visitUndefValue(UndefValue &);
+ OffsetSpan visitInstruction(Instruction &I);
private:
- SizeOffsetAPInt findLoadSizeOffset(
- LoadInst &LoadFrom, BasicBlock &BB, BasicBlock::iterator From,
- SmallDenseMap &VisitedBlocks,
-
[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
https://github.com/h-vetinari commented: I did a first pass, and this looks like great work to me overall (though note that I'm not necessarily the most qualified to judge there). But from what I can see this will greatly improve a couple of existing pain points. There's a bunch of places that need to rename `flang-new` to `flang`, but I just saw that it's already planned to fix this once this gets rebased on main. https://github.com/llvm/llvm-project/pull/110217 ___ 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] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
@@ -290,11 +290,15 @@ static void processVSRuntimeLibrary(const ToolChain &TC,
const ArgList &Args,
ArgStringList &CmdArgs) {
assert(TC.getTriple().isKnownWindowsMSVCEnvironment() &&
"can only add VS runtime library on Windows!");
- // if -fno-fortran-main has been passed, skip linking Fortran_main.a
- if (TC.getTriple().isKnownWindowsMSVCEnvironment()) {
-CmdArgs.push_back(Args.MakeArgString(
-"--dependent-lib=" + TC.getCompilerRTBasename(Args, "builtins")));
- }
+
+ // Flang/Clang (including clang-cl) -compiled programs targeting the MSVC ABI
+ // should only depend on msv(u)crt. LLVM still emits libgcc/compiler-rt
+ // functions in some cases like 128-bit integer math (__udivti3, __modti3,
+ // __fixsfti, __floattidf, ...) that msvc does not support. We are injecting
a
+ // dependency to Compiler-RT's builtin library where these are implemented.
h-vetinari wrote:
This is great! :)
https://github.com/llvm/llvm-project/pull/110217
___
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] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
@@ -0,0 +1,198 @@ + + +# Fortran Runtime (flang-rt) + +Flang-rt is the runtime library for code emitted by the Flang compiler +(https://flang.llvm.org). + + +## Getting Started + +There are two build modes for the flang-rt. The bootstrap build, also +called the in-tree build, and the runtime-only build, also called the +out-of-tree build. +Not to be confused with the terms +[in-source and out-of-source](https://cmake.org/cmake/help/latest/manual/cmake.1.html#introduction-to-cmake-buildsystems) +builds as defined by CMake. In an in-source build, the source directory and the +build directory are identical, whereas with an out-of-source build the +build artifacts are stored somewhere else, possibly in a subdirectory of the +source directory. LLVM does not support in-source builds. + + +### Requirements + +Requirements: + * [Same as LLVM](https://llvm.org/docs/GettingStarted.html#requirements). + + +### Bootstrap/In-Tree Build + +The bootstrap build will first build Clang and Flang, then use these compilers +to compile flang-rt. CMake will create a secondary build tree in +configured with these just-built compilers. The secondary build will reuse the +same build options (Flags, Debug/Release, ...) as the primary build. It will +also ensure that once built, flang-rt is found by Flang from either +the build- or install-prefix. To enable, add `flang-rt` to +`LLVM_ENABLE_RUNTIMES`: + +```bash +cmake -S /llvm\ + -DNinja \ + -DLLVM_ENABLE_PROJECTS=flang \ + -DLLVM_ENABLE_RUNTIMES=flang-rt \ + ... +``` + +It is recommended to enable building OpenMP alongside Flang and flang-rt +as well. This will build `omp_lib.mod` required to use OpenMP from Fortran. +Building Compiler-RT may also be required, particularly on platforms that do +not provide all C-ABI functionality (such as Windows). + +```bash +cmake -S /llvm \ + -DNinja \ + -DCMAKE_BUILD_TYPE=Release \ + -DLLVM_ENABLE_PROJECTS="flang;openmp" \ + -DLLVM_ENABLE_RUNTIMES="compiler-rt;flang-rt" \ + ... +``` + +By default, the enabled runtimes will only be built for the host platform +(`-DLLVM_RUNTIME_TARGETS=default`). To add additional targets to support +cross-compilation via `flang-new --target=`, add more triples to h-vetinari wrote: ```suggestion cross-compilation via `flang --target=`, add more triples to ``` https://github.com/llvm/llvm-project/pull/110217 ___ 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] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
https://github.com/h-vetinari edited https://github.com/llvm/llvm-project/pull/110217 ___ 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] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
@@ -89,6 +91,9 @@ function(llvm_ExternalProject_Add name source_dir) if(NOT ARG_TOOLCHAIN_TOOLS) set(ARG_TOOLCHAIN_TOOLS clang) +if (ARG_ENABLE_FORTRAN) + list(APPEND ARG_TOOLCHAIN_TOOLS flang-new) h-vetinari wrote: ```suggestion list(APPEND ARG_TOOLCHAIN_TOOLS flang) ``` https://github.com/llvm/llvm-project/pull/110217 ___ 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] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
@@ -0,0 +1,210 @@
+#===-- CMakeLists.txt
--===#
+#
+# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+# See https://llvm.org/LICENSE.txt for license information.
+# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+#
+#======#
+#
+# Build instructions for the flang-rt library. This is file is intended to be
+# included using the LLVM_ENABLE_RUNTIMES mechanism.
+#
+#======#
+
+set(LLVM_SUBPROJECT_TITLE "Fortran Runtime")
+set(FLANG_RT_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}")
+set(FLANG_RT_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}")
+set(FLANG_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../flang")
+
+
+# CMake 3.24 is the first version of CMake that directly recognizes Flang.
+# LLVM's requirement is only CMake 3.20, teach CMake 3.20-3.23 how to use
Flang.
+if (CMAKE_VERSION VERSION_LESS "3.24")
+ cmake_path(GET CMAKE_Fortran_COMPILER STEM _Fortran_COMPILER_STEM)
+ if (_Fortran_COMPILER_STEM STREQUAL "flang-new" OR _Fortran_COMPILER_STEM
STREQUAL "flang")
+include(CMakeForceCompiler)
+CMAKE_FORCE_Fortran_COMPILER("${CMAKE_Fortran_COMPILER}" "LLVMFlang")
+
+set(CMAKE_Fortran_COMPILER_ID "LLVMFlang")
+set(CMAKE_Fortran_COMPILER_VERSION "20.0")
+
+set(CMAKE_Fortran_SUBMODULE_SEP "-")
+set(CMAKE_Fortran_SUBMODULE_EXT ".mod")
+
+set(CMAKE_Fortran_PREPROCESS_SOURCE
+ " -cpp-E
> ")
+
+set(CMAKE_Fortran_FORMAT_FIXED_FLAG "-ffixed-form")
+set(CMAKE_Fortran_FORMAT_FREE_FLAG "-ffree-form")
+
+set(CMAKE_Fortran_MODDIR_FLAG "-module-dir")
+
+set(CMAKE_Fortran_COMPILE_OPTIONS_PREPROCESS_ON "-cpp")
+set(CMAKE_Fortran_COMPILE_OPTIONS_PREPROCESS_OFF "-nocpp")
+set(CMAKE_Fortran_POSTPROCESS_FLAG "-ffixed-line-length-72")
+
+set(CMAKE_Fortran_COMPILE_OPTIONS_TARGET "--target=")
+
+set(CMAKE_Fortran_LINKER_WRAPPER_FLAG "-Wl,")
+set(CMAKE_Fortran_LINKER_WRAPPER_FLAG_SEP ",")
+ endif ()
+endif ()
+enable_language(Fortran)
+
+
+list(APPEND CMAKE_MODULE_PATH
+"${FLANG_RT_SOURCE_DIR}/cmake/modules"
+"${FLANG_SOURCE_DIR}/cmake/modules"
+ )
+include(AddFlangRT)
+include(FlangCommon)
+
+
+
+# Build Mode Introspection #
+
+
+# Setting these variables from an LLVM build is sufficient that flang-rt can
+# construct the output paths, so it can behave as if it were in-tree here.
+set(LLVM_TREE_AVAILABLE OFF)
+if (LLVM_LIBRARY_OUTPUT_INTDIR AND LLVM_RUNTIME_OUTPUT_INTDIR AND
PACKAGE_VERSION)
+ # This is a bootstap build
+ set(LLVM_TREE_AVAILABLE ON)
+endif()
+
+if (LLVM_TREE_AVAILABLE)
+ # Despite Clang in the name, get_clang_resource_dir does not depend on Clang
being added to the build
+ # flang-new uses the same resource dir as clang.
+ include(GetClangResourceDir)
+ get_clang_resource_dir(FLANG_RT_BUILD_LIB_DIR PREFIX
"${LLVM_LIBRARY_OUTPUT_INTDIR}/.." SUBDIR "lib${LLVM_LIBDIR_SUFFIX}")
+ get_clang_resource_dir(FLANG_RT_INSTALL_LIB_DIR SUBDIR
"lib${LLVM_LIBDIR_SUFFIX}") # No prefix, CMake's install command finds the
install prefix itself
+else ()
+ set(FLANG_RT_BUILD_LIB_DIR "${LLVM_LIBRARY_OUTPUT_INTDIR}")
+ set(FLANG_RT_INSTALL_LIB_DIR "lib${LLVM_LIBDIR_SUFFIX}")
+endif ()
+
+if (DEFINED WIN32)
+ set(FLANG_RT_BUILD_LIB_DIR "${FLANG_RT_BUILD_LIB_DIR}/windows")
+ set(FLANG_RT_INSTALL_LIB_DIR "${FLANG_RT_INSTALL_LIB_DIR}/windows")
+elseif (LLVM_ENABLE_PER_TARGET_RUNTIME_DIR)
+ set(FLANG_RT_BUILD_LIB_DIR "${FLANG_RT_BUILD_LIB_DIR}/${LLVM_TARGET_TRIPLE}")
+ set(FLANG_RT_INSTALL_LIB_DIR
"${FLANG_RT_INSTALL_LIB_DIR}/${LLVM_TARGET_TRIPLE}")
+endif ()
+
+
+#
+# Build Options #
+#
+
+# Important: flang-rt user options must be prefixed with "FLANG_RT_". Variables
+# with this prefix will be forwarded in bootstrap builds.
+
+option(FLANG_RT_INCLUDE_TESTS "Generate build targets for the flang-rt unit
and regression-tests." "${LLVM_INCLUDE_TESTS}")
+
+
+set(FLANG_RT_EXPERIMENTAL_OFFLOAD_SUPPORT "" CACHE STRING "Compile flang-rt
with GPU support (CUDA or OpenMP)")
+set_property(CACHE FLANG_RT_EXPERIMENTAL_OFFLOAD_SUPPORT PROPERTY STRINGS
+""
+CUDA
+OpenMP
+ )
+if (NOT FLANG_RT_EXPERIMENTAL_OFFLOAD_SUPPORT)
+elseif (FLANG_RT_EXPERIMENTAL_OFFLOAD_SUPPORT STREQUAL "CUDA")
h-vetinari wrote:
If the first if branch is intentionally empty, maybe add a comment to that
effect?
https://github.com/llvm/llvm-project/pull/110217
___
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] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
@@ -179,19 +179,18 @@ like this: ``` $ flang -v -o example example.o -"/usr/bin/ld" [...] example.o [...] "-lFortranRuntime" "-lFortranDecimal" [...] +"/usr/bin/ld" [...] example.o [...] "-lflang_rt" [...] ``` The automatically added libraries are: -* `FortranRuntime`: Provides most of the Flang runtime library. -* `FortranDecimal`: Provides operations for decimal numbers. +* `flang_rt`: Provides most of the Flang runtime library. If the code is C/C++ based and invokes Fortran routines, one can either use Clang or Flang as the linker driver. If Clang is used, it will automatically all required runtime libraries needed by C++ (e.g., for STL) to the linker invocation. -In this case, one has to explicitly provide the Fortran runtime libraries -`FortranRuntime` and/or `FortranDecimal`. An alternative is to use Flang to link. +In this case, one has to explicitly provide the Fortran runtime library +`flang_ty`. An alternative is to use Flang to link. h-vetinari wrote: ```suggestion `flang_rt`. An alternative is to use Flang to link. ``` https://github.com/llvm/llvm-project/pull/110217 ___ 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] release/19.x: [OpenMP] Create versioned libgomp softlinks (#112973) (PR #115944)
shiltian wrote: Are we still releasing 19? https://github.com/llvm/llvm-project/pull/115944 ___ 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] [CGData] Refactor Global Merge Functions (PR #115750)
ellishg wrote: > Hit an assertion in `ignoreOp` when testing the refactored code. > > ``` > Assertion failed: (OpIdx < I->getNumOperands() && "Invalid operand index"), > function ignoreOp, file GlobalMergeFunctions.cpp, line 129. > Stop reason: hit program assert > expr I->dump() > %6 = tail call ptr @objc_retain(ptr %5), !dbg !576 > > p I->getNumOperands() > > (unsigned int) 2 > p OpIdx > > (unsigned int) 4 > ``` Do we know why `OpIdx` is 4 here? This is confusing to me because it looks like there is only one argument, `%5`. https://github.com/llvm/llvm-project/pull/115750 ___ 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] [TySan] Fixed false positive when accessing offset member variables (PR #95387)
https://github.com/gbMattN updated
https://github.com/llvm/llvm-project/pull/95387
>From 8099113d68bd7c47c29f635bb10a048ddb99833b Mon Sep 17 00:00:00 2001
From: Matthew Nagy
Date: Fri, 28 Jun 2024 16:12:31 +
Subject: [PATCH 1/2] [TySan] Fixed false positive when accessing global
object's member variables
---
compiler-rt/lib/tysan/tysan.cpp | 19 +++-
.../test/tysan/global-struct-members.c| 31 +++
2 files changed, 49 insertions(+), 1 deletion(-)
create mode 100644 compiler-rt/test/tysan/global-struct-members.c
diff --git a/compiler-rt/lib/tysan/tysan.cpp b/compiler-rt/lib/tysan/tysan.cpp
index f627851d049e6a..8235b0ec2b55e7 100644
--- a/compiler-rt/lib/tysan/tysan.cpp
+++ b/compiler-rt/lib/tysan/tysan.cpp
@@ -221,7 +221,24 @@ __tysan_check(void *addr, int size, tysan_type_descriptor
*td, int flags) {
OldTDPtr -= i;
OldTD = *OldTDPtr;
-if (!isAliasingLegal(td, OldTD))
+// When shadow memory is set for global objects, the entire object is
tagged with the struct type
+// This means that when you access a member variable, tysan reads that as
you accessing a struct midway
+// through, with 'i' being the offset
+// Therefore, if you are accessing a struct, we need to find the member
type. We can go through the
+// members of the struct type and see if there is a member at the offset
you are accessing the struct by.
+// If there is indeed a member starting at offset 'i' in the struct, we
should check aliasing legality
+// with that type. If there isn't, we run alias checking on the struct
with will give us the correct error.
+tysan_type_descriptor *InternalMember = OldTD;
+if (OldTD->Tag == TYSAN_STRUCT_TD) {
+ for (int j = 0; j < OldTD->Struct.MemberCount; j++) {
+if (OldTD->Struct.Members[j].Offset == i) {
+ InternalMember = OldTD->Struct.Members[j].Type;
+ break;
+}
+ }
+}
+
+if (!isAliasingLegal(td, InternalMember))
reportError(addr, size, td, OldTD, AccessStr,
"accesses part of an existing object", -i, pc, bp, sp);
diff --git a/compiler-rt/test/tysan/global-struct-members.c
b/compiler-rt/test/tysan/global-struct-members.c
new file mode 100644
index 00..76ea3c431dd7bc
--- /dev/null
+++ b/compiler-rt/test/tysan/global-struct-members.c
@@ -0,0 +1,31 @@
+// RUN: %clang_tysan -O0 %s -o %t && %run %t >%t.out 2>&1
+// RUN: FileCheck %s < %t.out
+
+#include
+
+struct X {
+ int a, b, c;
+} x;
+
+static struct X xArray[2];
+
+int main() {
+ x.a = 1;
+ x.b = 2;
+ x.c = 3;
+
+ printf("%d %d %d\n", x.a, x.b, x.c);
+ // CHECK-NOT: ERROR: TypeSanitizer: type-aliasing-violation
+
+ for (size_t i = 0; i < 2; i++) {
+xArray[i].a = 1;
+xArray[i].b = 1;
+xArray[i].c = 1;
+ }
+
+ struct X *xPtr = (struct X *)&(xArray[0].c);
+ xPtr->a = 1;
+ // CHECK: ERROR: TypeSanitizer: type-aliasing-violation
+ // CHECK: WRITE of size 4 at {{.*}} with type int (in X at offset 0)
accesses an existing object of type int (in X at offset 8)
+ // CHECK: {{#0 0x.* in main .*struct-members.c:}}[[@LINE-3]]
+}
>From be4f4c552dfdd4dbe1fa9495dd6265d2d2d83056 Mon Sep 17 00:00:00 2001
From: gbMattN
Date: Tue, 12 Nov 2024 16:52:27 +
Subject: [PATCH 2/2] [style] Tidied up comments, formatting, and polished test
---
compiler-rt/lib/tysan/tysan.cpp | 24 ++-
.../test/tysan/global-struct-members.c| 7 +++---
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/compiler-rt/lib/tysan/tysan.cpp b/compiler-rt/lib/tysan/tysan.cpp
index 8235b0ec2b55e7..96110ea2243892 100644
--- a/compiler-rt/lib/tysan/tysan.cpp
+++ b/compiler-rt/lib/tysan/tysan.cpp
@@ -221,24 +221,26 @@ __tysan_check(void *addr, int size, tysan_type_descriptor
*td, int flags) {
OldTDPtr -= i;
OldTD = *OldTDPtr;
-// When shadow memory is set for global objects, the entire object is
tagged with the struct type
-// This means that when you access a member variable, tysan reads that as
you accessing a struct midway
-// through, with 'i' being the offset
-// Therefore, if you are accessing a struct, we need to find the member
type. We can go through the
-// members of the struct type and see if there is a member at the offset
you are accessing the struct by.
-// If there is indeed a member starting at offset 'i' in the struct, we
should check aliasing legality
-// with that type. If there isn't, we run alias checking on the struct
with will give us the correct error.
-tysan_type_descriptor *InternalMember = OldTD;
+// When shadow memory is set for global objects, the entire object is
tagged
+// with the struct type This means that when you access a member variable,
+// tysan reads that as you accessing a struct midway through, with 'i'
being
+// the offset Therefore, if you are accessing a struct, we need to find the
+// member type. We can
[llvm-branch-commits] [llvm] release/19.x: [llvm] Fix __builtin_object_size interaction between Negative Offset … (#111827) (PR #114786)
hvdijk wrote: Also cc @serge-sans-paille for the chance to comment since this now includes changes of mine and is no longer a straightforward backport. https://github.com/llvm/llvm-project/pull/114786 ___ 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] release/19.x: [OpenMP] Create versioned libgomp softlinks (#112973) (PR #115944)
https://github.com/llvmbot created
https://github.com/llvm/llvm-project/pull/115944
Backport eccdb2489483ca58d2cb35bc38967a8e33117575
Requested by: @ye-luo
>From b82797185fcc335c0f517df8d2dd34658674e2df Mon Sep 17 00:00:00 2001
From: Ye Luo
Date: Fri, 25 Oct 2024 13:19:58 -0500
Subject: [PATCH] [OpenMP] Create versioned libgomp softlinks (#112973)
Add libgomp.1.dylib for MacOS and libgomp.so.1 for Linux
Linkers on Mac and Linux pick up versioned libgomp dynamic library
files. The existing softlinks (libgomp.dylib for MacOS and libgomp.so
for Linux) are insufficient. This helps alleviate the issue of mixing
libgomp and libomp at runtime.
(cherry picked from commit eccdb2489483ca58d2cb35bc38967a8e33117575)
---
openmp/runtime/src/CMakeLists.txt | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/openmp/runtime/src/CMakeLists.txt
b/openmp/runtime/src/CMakeLists.txt
index f106694841ce8d..a02aa6df937243 100644
--- a/openmp/runtime/src/CMakeLists.txt
+++ b/openmp/runtime/src/CMakeLists.txt
@@ -244,6 +244,17 @@ if(NOT WIN32)
libiomp5${LIBOMP_LIBRARY_SUFFIX}
WORKING_DIRECTORY ${LIBOMP_LIBRARY_DIR}
)
+ if(LIBOMP_ENABLE_SHARED)
+if(APPLE)
+ set(VERSIONED_LIBGOMP_NAME libgomp.1${LIBOMP_LIBRARY_SUFFIX})
+else()
+ set(VERSIONED_LIBGOMP_NAME libgomp${LIBOMP_LIBRARY_SUFFIX}.1)
+endif()
+add_custom_command(TARGET omp POST_BUILD
+ COMMAND ${CMAKE_COMMAND} -E create_symlink ${LIBOMP_LIB_FILE}
${VERSIONED_LIBGOMP_NAME}
+ WORKING_DIRECTORY ${LIBOMP_LIBRARY_DIR}
+)
+ endif()
endif()
# Definitions for testing, for reuse when testing libomptarget-nvptx.
@@ -430,13 +441,18 @@ else()
if(${LIBOMP_INSTALL_ALIASES})
# Create aliases (symlinks) of the library for backwards compatibility
+extend_path(outdir "${CMAKE_INSTALL_PREFIX}" "${OPENMP_INSTALL_LIBDIR}")
set(LIBOMP_ALIASES "libgomp;libiomp5")
foreach(alias IN LISTS LIBOMP_ALIASES)
- extend_path(outdir "${CMAKE_INSTALL_PREFIX}" "${OPENMP_INSTALL_LIBDIR}")
install(CODE "execute_process(COMMAND \"\${CMAKE_COMMAND}\" -E
create_symlink \"${LIBOMP_LIB_FILE}\"
\"${alias}${LIBOMP_LIBRARY_SUFFIX}\" WORKING_DIRECTORY
\"\$ENV{DESTDIR}${outdir}\")")
endforeach()
+if(LIBOMP_ENABLE_SHARED)
+ install(CODE "execute_process(COMMAND \"\${CMAKE_COMMAND}\" -E
create_symlink \"${LIBOMP_LIB_FILE}\"
+\"${VERSIONED_LIBGOMP_NAME}\" WORKING_DIRECTORY
+\"\$ENV{DESTDIR}${outdir}\")")
+endif()
endif()
endif()
install(
___
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] release/19.x: [OpenMP] Create versioned libgomp softlinks (#112973) (PR #115944)
https://github.com/llvmbot milestoned https://github.com/llvm/llvm-project/pull/115944 ___ 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] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
jhuber6 wrote: This patch doesn't apply cleanly for me https://github.com/llvm/llvm-project/pull/110217 ___ 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][draft] Support 1:N dialect conversion (PR #112141)
https://github.com/matthias-springer edited https://github.com/llvm/llvm-project/pull/112141 ___ 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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 8a49434df62e394cd109f0189349b4d28dafa525
b59db4636891df96b7569c9737e361431f898909 --extensions cpp,h --
mlir/include/mlir/IR/Builders.h
mlir/include/mlir/Transforms/DialectConversion.h
mlir/lib/Dialect/Func/Transforms/DecomposeCallGraphTypes.cpp
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorCodegen.cpp
mlir/lib/Dialect/SparseTensor/Transforms/Utils/SparseTensorDescriptor.cpp
mlir/lib/IR/Builders.cpp mlir/lib/Transforms/Utils/DialectConversion.cpp
``
View the diff from clang-format here.
``diff
diff --git a/mlir/lib/Transforms/Utils/DialectConversion.cpp
b/mlir/lib/Transforms/Utils/DialectConversion.cpp
index 23d7b05982..a0cf52b462 100644
--- a/mlir/lib/Transforms/Utils/DialectConversion.cpp
+++ b/mlir/lib/Transforms/Utils/DialectConversion.cpp
@@ -1443,16 +1443,15 @@ void ConversionPatternRewriterImpl::notifyOpReplaced(
// Remap result to replacement value.
if (repl.empty())
continue;
-
+
if (repl.size() == 1) {
// Single replacement value: replace directly.
mapping.map(result, repl.front());
} else {
// Multiple replacement values: insert N:1 materialization.
- insertNTo1Materialization(OpBuilder::InsertPoint::after(repl, &domInfo),
-result.getLoc(),
-/*replacements=*/repl, /*outputValue=*/result,
-currentTypeConverter);
+ insertNTo1Materialization(
+ OpBuilder::InsertPoint::after(repl, &domInfo), result.getLoc(),
+ /*replacements=*/repl, /*outputValue=*/result, currentTypeConverter);
}
}
``
https://github.com/llvm/llvm-project/pull/115816
___
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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
River707 wrote: > > The only very high level conern I have is the use and need of > > `InsertionPoint::after`. As I understand, this is a not-yet-implemented > > optimization for the future for the purpose of reusing materializations by > > calculating a better insertion point where it may dominate more operations > > which might need exactly that materialization after pattern application as > > well. > > Yes, that's correct. But this optimization is already implemented. And it is > actually quite deeply ingrained into the dialect conversion driver. > > SSA values are not replaced directly, but in a delayed fashion. The > replacement value is stored in the `ConversionValueMapping` (a kind of > `IRMapping`). We store not only user-specified replacement values but also > materializations in there. The data structure is kind of a linked list: for > an original value, we store a list of replacement values: the specified > replacement value and materializations to a different type. In the "finalize" > phase, the driver goes through that list to find a > replacement/materialization value with the correct type. We cannot store more > than one replacement/materialization value with the same type; the driver > would just pick the first one that matches. So we always reuse. > > Note: Computing an insertion point for a 1:1 materialization (or a 1:N block > signature conversion) is much easier because there is only one SSA value (or > one block). That's why computing the insertion point was trivial until now. > > > Is the current complexity of calculating the insertion point (and > > potentially calculatin the post-dom tree, a O(n log n) operation) worth the > > gain of the optimization? I am thinking that the better insertion point > > insertion logic should probably be post-poned until we can measure its > > effectivness (and avoid the risk of a premature optimization) and have > > something simpler and working that does not worsen the status-quo for now > > instead. > > This PR also makes the `DominanceInfo` argument to `InsertPoint::after` > optional in case of a single SSA value. (And no `DominanceInfo` is passed in > that case.) For the most frequent case of 1:1 replacements, we do not compute > a dominator tree at all. (And we are not doing any extra work.) > > In case of N:1 materializations, the implementation uses `DominanceInfo` and > we create it during `ConversionPatternRewriter::replaceOpWithMultiple`. > Unfortunately, it is not safe to reuse the same `DominanceInfo` object > because a pattern could have made IR changes that invalidate the dominator > tree. > > However, I believe `DominanceInfo` is quite "cheap" to use. The dominator > tree is built lazily and it is built on a per-region basis. E.g., creating a > new `DominanceInfo` and querying dominance for two ops in the same region > will just build the dominator tree for that region (and only if the ops are > in different blocks). In case of two ops from different regions (or different > blocks in the same region), the implementation will find the common ancestors > (in the same region) and then compute the dominator tree only for that region. > > Long term, the `ConversionValueMapping` is going to disappear with the > One-Shot Dialect Conversion. As part of that, I'm also thinking of removing > the "materialization caching" mechanism and just building duplicate > materializations (in the form of `unrealized_conversion_cast`, i.e., not > calling the callback). These can then be CSE'd before calling the > materialization callback. The CSE-ing will require `DominanceInfo`, but the > same `DominanceInfo` can be reused for the entire dialect conversion because > at this point of time we are done with pattern applications. One question I have here is why not just insert right before the operation that is being replaced? What is the need for trying to insert after one of the values? https://github.com/llvm/llvm-project/pull/115816 ___ 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] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
h-vetinari wrote: > This patch doesn't apply cleanly for me That's because it's a series of patches (see OP), so you have to apply them all in order (or simply check out the branch that represents this PR) https://github.com/llvm/llvm-project/pull/110217 ___ 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] 86e5163 - Revert "[clang][flang] Support -time in both clang and flang"
Author: Tarun Prabhu
Date: 2024-11-12T15:48:07-07:00
New Revision: 86e5163d2403cebb179815ea8ee012f13d273efd
URL:
https://github.com/llvm/llvm-project/commit/86e5163d2403cebb179815ea8ee012f13d273efd
DIFF:
https://github.com/llvm/llvm-project/commit/86e5163d2403cebb179815ea8ee012f13d273efd.diff
LOG: Revert "[clang][flang] Support -time in both clang and flang"
This reverts commit f5396748c7da3d9f278fcd42e2a10a3214920d82.
Added:
Modified:
clang/include/clang/Driver/Options.td
clang/lib/Driver/Compilation.cpp
clang/lib/Driver/Driver.cpp
Removed:
clang/test/Driver/time.c
flang/test/Driver/time.f90
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index 0bbab21120f2b6..9fb7f8bb6489b0 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5896,7 +5896,6 @@ def print_enabled_extensions : Flag<["-", "--"],
"print-enabled-extensions">,
def : Flag<["-"], "mcpu=help">, Alias;
def : Flag<["-"], "mtune=help">, Alias;
def time : Flag<["-"], "time">,
- Visibility<[ClangOption, CLOption, DXCOption, FlangOption]>,
HelpText<"Time individual commands">;
def traditional_cpp : Flag<["-", "--"], "traditional-cpp">,
Visibility<[ClangOption, CC1Option]>,
diff --git a/clang/lib/Driver/Compilation.cpp
b/clang/lib/Driver/Compilation.cpp
index 6965e59367c95d..ad077d5bbfa69a 100644
--- a/clang/lib/Driver/Compilation.cpp
+++ b/clang/lib/Driver/Compilation.cpp
@@ -21,9 +21,6 @@
#include "llvm/Option/OptSpecifier.h"
#include "llvm/Option/Option.h"
#include "llvm/Support/FileSystem.h"
-#include "llvm/Support/Format.h"
-#include "llvm/Support/Path.h"
-#include "llvm/Support/Timer.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/TargetParser/Triple.h"
#include
@@ -197,28 +194,11 @@ int Compilation::ExecuteCommand(const Command &C,
if (LogOnly)
return 0;
- // We don't use any timers or llvm::TimeGroup's because those are tied into
- // the global static timer list which, in principle, could be cleared without
- // us knowing about it.
- llvm::TimeRecord StartTime;
- if (getArgs().hasArg(options::OPT_time))
-StartTime = llvm::TimeRecord::getCurrentTime(/*Start=*/true);
-
std::string Error;
bool ExecutionFailed;
int Res = C.Execute(Redirects, &Error, &ExecutionFailed);
if (PostCallback)
PostCallback(C, Res);
-
- if (getArgs().hasArg(options::OPT_time)) {
-llvm::TimeRecord Time = llvm::TimeRecord::getCurrentTime(/*Start=*/false);
-Time -= StartTime;
-llvm::StringRef Name = llvm::sys::path::filename(C.getExecutable());
-llvm::errs() << "# " << Name << " "
- << llvm::format("%0.2f", Time.getUserTime()) << " "
- << llvm::format("%0.2f", Time.getSystemTime()) << "\n";
- }
-
if (!Error.empty()) {
assert(Res && "Error string set with 0 result code!");
getDriver().Diag(diag::err_drv_command_failure) << Error;
diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index a0fd459967a6b2..93e85f7dffe35a 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -1315,9 +1315,6 @@ Compilation *Driver::BuildCompilation(ArrayRef ArgList) {
// Ignore -pipe.
Args.ClaimAllArgs(options::OPT_pipe);
- // Ignore -time.
- Args.ClaimAllArgs(options::OPT_time);
-
// Extract -ccc args.
//
// FIXME: We need to figure out where this behavior should live. Most of it
diff --git a/clang/test/Driver/time.c b/clang/test/Driver/time.c
deleted file mode 100644
index a9a95b073afb73..00
--- a/clang/test/Driver/time.c
+++ /dev/null
@@ -1,33 +0,0 @@
-// The -time option prints timing information for the various subcommands in a
-// format similar to that used by gcc. When compiling and linking, this will
-// include the time to call clang-${LLVM_VERSION_MAJOR} and the linker. Since
-// the name of the linker could vary across platforms, and name of the compiler
-// could be something
diff erent, just check that whatever is printed to stderr
-// looks like timing information.
-
-// Ideally, this should be tested on various platforms, but that requires the
-// the full toolchain, including a linker to be present. The initial author of
-// the test only had access to Linux on x86 which is why this is only enabled
-// there. More platforms ought to be added if possible.
-
-// REQUIRES: x86-registered-target
-// REQUIRES: x86_64-linux
-
-// RUN: %clang --target=x86_64-pc-linux -time -c -o /dev/null %s 2>&1 \
-// RUN: | FileCheck %s --check-prefix=COMPILE-ONLY
-// RUN: %clang --target=x86_64-pc-linux -time -S -emit-llvm -o /dev/null %s
2>&1 \
-// RUN: | FileCheck %s --check-prefix=COMPILE-ONLY
-// RUN: %clang --target=x86_64-pc-linux -time -S -o /dev/null %s 2>&1 \
-// RUN: | FileCheck %s --check-prefix=COMPILE-ONLY
-// RUN: %clang --target=x86_64-pc-linux -time -o /dev/null %s
[llvm-branch-commits] [llvm] release/19.x: [llvm] Fix __builtin_object_size interaction between Negative Offset … (#111827) (PR #114786)
serge-sans-paille wrote: For the record, I've just submitted https://github.com/llvm/llvm-project/pull/115504 that fixes a few issues related to the same kind of issues... https://github.com/llvm/llvm-project/pull/114786 ___ 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] release/19.x: [OpenMP] Create versioned libgomp softlinks (#112973) (PR #115944)
llvmbot wrote: @shiltian What do you think about merging this PR to the release branch? https://github.com/llvm/llvm-project/pull/115944 ___ 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] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
@@ -0,0 +1,210 @@
+#===-- CMakeLists.txt
--===#
+#
+# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+# See https://llvm.org/LICENSE.txt for license information.
+# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+#
+#======#
+#
+# Build instructions for the flang-rt library. This is file is intended to be
+# included using the LLVM_ENABLE_RUNTIMES mechanism.
+#
+#======#
+
+set(LLVM_SUBPROJECT_TITLE "Fortran Runtime")
+set(FLANG_RT_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}")
+set(FLANG_RT_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}")
+set(FLANG_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../flang")
+
+
+# CMake 3.24 is the first version of CMake that directly recognizes Flang.
+# LLVM's requirement is only CMake 3.20, teach CMake 3.20-3.23 how to use
Flang.
+if (CMAKE_VERSION VERSION_LESS "3.24")
+ cmake_path(GET CMAKE_Fortran_COMPILER STEM _Fortran_COMPILER_STEM)
+ if (_Fortran_COMPILER_STEM STREQUAL "flang-new" OR _Fortran_COMPILER_STEM
STREQUAL "flang")
+include(CMakeForceCompiler)
+CMAKE_FORCE_Fortran_COMPILER("${CMAKE_Fortran_COMPILER}" "LLVMFlang")
+
+set(CMAKE_Fortran_COMPILER_ID "LLVMFlang")
+set(CMAKE_Fortran_COMPILER_VERSION "20.0")
h-vetinari wrote:
Shouldn't this version be picked up dynamically? Hardcoding this to 20 doesn't
sound ideal IMO.
https://github.com/llvm/llvm-project/pull/110217
___
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] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
jhuber6 wrote: > > This patch doesn't apply cleanly for me > > That's because it's a series of patches (see OP), so you have to apply them > all in order (or simply check out the branch that represents this PR) I thought that's what happens by default when you use https://patch-diff.githubusercontent.com/raw/llvm/llvm-project/pull/110217.diff https://github.com/llvm/llvm-project/pull/110217 ___ 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/19.x: [llvm] Fix __builtin_object_size interaction between Negative Offset … (#111827) (PR #114786)
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/114786
>From fb70629e196c516ebd5083f8624ba614f746ef67 Mon Sep 17 00:00:00 2001
From: serge-sans-paille
Date: Sat, 2 Nov 2024 09:14:35 +
Subject: [PATCH 1/2] =?UTF-8?q?[llvm]=20Fix=20=5F=5Fbuiltin=5Fobject=5Fsiz?=
=?UTF-8?q?e=20interaction=20between=20Negative=20Offset=20=E2=80=A6=20(#1?=
=?UTF-8?q?11827)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
…and Select/Phi
When picking a SizeOffsetAPInt through combineSizeOffset, the behavior
differs if we're going to apply a constant offset that's positive or
negative: If it's positive, then we need to compare the remaining bytes
(i.e. Size
- Offset), but if it's negative, we need to compare the preceding bytes
(i.e. Offset).
Fix #111709
(cherry picked from commit 01a103b0b9c449e8dec17950835991757d1c4f88)
---
llvm/include/llvm/Analysis/MemoryBuiltins.h | 71 +++--
llvm/lib/Analysis/MemoryBuiltins.cpp | 145 +-
.../builtin-object-size-phi.ll| 254 ++
.../objectsize_basic.ll | 24 ++
4 files changed, 405 insertions(+), 89 deletions(-)
diff --git a/llvm/include/llvm/Analysis/MemoryBuiltins.h
b/llvm/include/llvm/Analysis/MemoryBuiltins.h
index bb282a1b73d320..a21f116db7e70d 100644
--- a/llvm/include/llvm/Analysis/MemoryBuiltins.h
+++ b/llvm/include/llvm/Analysis/MemoryBuiltins.h
@@ -222,21 +222,43 @@ struct SizeOffsetAPInt : public SizeOffsetType {
static bool known(const APInt &V) { return V.getBitWidth() > 1; }
};
+/// OffsetSpan - Used internally by \p ObjectSizeOffsetVisitor. Represents a
+/// point in memory as a pair of allocated bytes before and after it.
+struct OffsetSpan {
+ APInt Before; /// Number of allocated bytes before this point.
+ APInt After; /// Number of allocated bytes after this point.
+
+ OffsetSpan() = default;
+ OffsetSpan(APInt Before, APInt After) : Before(Before), After(After) {}
+
+ bool knownBefore() const { return known(Before); }
+ bool knownAfter() const { return known(After); }
+ bool anyKnown() const { return knownBefore() || knownAfter(); }
+ bool bothKnown() const { return knownBefore() && knownAfter(); }
+
+ bool operator==(const OffsetSpan &RHS) const {
+return Before == RHS.Before && After == RHS.After;
+ }
+ bool operator!=(const OffsetSpan &RHS) const { return !(*this == RHS); }
+
+ static bool known(const APInt &V) { return V.getBitWidth() > 1; }
+};
+
/// Evaluate the size and offset of an object pointed to by a Value*
/// statically. Fails if size or offset are not known at compile time.
class ObjectSizeOffsetVisitor
-: public InstVisitor {
+: public InstVisitor {
const DataLayout &DL;
const TargetLibraryInfo *TLI;
ObjectSizeOpts Options;
unsigned IntTyBits;
APInt Zero;
- SmallDenseMap SeenInsts;
+ SmallDenseMap SeenInsts;
unsigned InstructionsVisited;
APInt align(APInt Size, MaybeAlign Align);
- static SizeOffsetAPInt unknown() { return SizeOffsetAPInt(); }
+ static OffsetSpan unknown() { return OffsetSpan(); }
public:
ObjectSizeOffsetVisitor(const DataLayout &DL, const TargetLibraryInfo *TLI,
@@ -246,29 +268,30 @@ class ObjectSizeOffsetVisitor
// These are "private", except they can't actually be made private. Only
// compute() should be used by external users.
- SizeOffsetAPInt visitAllocaInst(AllocaInst &I);
- SizeOffsetAPInt visitArgument(Argument &A);
- SizeOffsetAPInt visitCallBase(CallBase &CB);
- SizeOffsetAPInt visitConstantPointerNull(ConstantPointerNull &);
- SizeOffsetAPInt visitExtractElementInst(ExtractElementInst &I);
- SizeOffsetAPInt visitExtractValueInst(ExtractValueInst &I);
- SizeOffsetAPInt visitGlobalAlias(GlobalAlias &GA);
- SizeOffsetAPInt visitGlobalVariable(GlobalVariable &GV);
- SizeOffsetAPInt visitIntToPtrInst(IntToPtrInst &);
- SizeOffsetAPInt visitLoadInst(LoadInst &I);
- SizeOffsetAPInt visitPHINode(PHINode &);
- SizeOffsetAPInt visitSelectInst(SelectInst &I);
- SizeOffsetAPInt visitUndefValue(UndefValue &);
- SizeOffsetAPInt visitInstruction(Instruction &I);
+ OffsetSpan visitAllocaInst(AllocaInst &I);
+ OffsetSpan visitArgument(Argument &A);
+ OffsetSpan visitCallBase(CallBase &CB);
+ OffsetSpan visitConstantPointerNull(ConstantPointerNull &);
+ OffsetSpan visitExtractElementInst(ExtractElementInst &I);
+ OffsetSpan visitExtractValueInst(ExtractValueInst &I);
+ OffsetSpan visitGlobalAlias(GlobalAlias &GA);
+ OffsetSpan visitGlobalVariable(GlobalVariable &GV);
+ OffsetSpan visitIntToPtrInst(IntToPtrInst &);
+ OffsetSpan visitLoadInst(LoadInst &I);
+ OffsetSpan visitPHINode(PHINode &);
+ OffsetSpan visitSelectInst(SelectInst &I);
+ OffsetSpan visitUndefValue(UndefValue &);
+ OffsetSpan visitInstruction(Instruction &I);
private:
- SizeOffsetAPInt findLoadSizeOffset(
- LoadInst &LoadFrom, BasicBlock &BB, BasicBlock::iterator From,
- SmallDenseMap &VisitedBlocks,
-
[llvm-branch-commits] [openmp] release/19.x: [OpenMP] Create versioned libgomp softlinks (#112973) (PR #115944)
ye-luo wrote: > Are we still releasing 19? yes. Point releases 19.1.x https://github.com/llvm/llvm-project/pull/115944 ___ 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] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
@@ -155,162 +50,131 @@ set(sources
product.cpp
pseudo-unit.cpp
ragged.cpp
- random.cpp
- reduce.cpp
- reduction.cpp
stat.cpp
- stop.cpp
sum.cpp
support.cpp
- temporary-stack.cpp
terminator.cpp
- time-intrinsic.cpp
tools.cpp
transformational.cpp
type-code.cpp
type-info.cpp
- unit-map.cpp
unit.cpp
+ unit-map.cpp
utf.cpp
- ${FORTRAN_MODULE_OBJECTS}
)
-include(AddFlangOffloadRuntime)
+# List of source not used for GPU offloading.
+set(host_sources
+ ${FLANG_SOURCE_DIR}/lib/Common/binary-to-decimal.cpp
+ ${FLANG_SOURCE_DIR}/lib/Common/decimal-to-binary.cpp
+ command.cpp
+ complex-powi.cpp
+ complex-reduction.c
+ exceptions.cpp
+ execute.cpp
+ extensions.cpp
+ ${FLANG_SOURCE_DIR}/module/iso_fortran_env_impl.f90
+ main.cpp
+ random.cpp
+ reduce.cpp
+ reduction.cpp
+ stop.cpp
+ temporary-stack.cpp
+ time-intrinsic.cpp
+)
-# List of files that are buildable for all devices.
-set(supported_files
- ISO_Fortran_binding.cpp
- allocatable.cpp
- allocator-registry.cpp
- array-constructor.cpp
- assign.cpp
- buffer.cpp
- character.cpp
- connection.cpp
- copy.cpp
- derived-api.cpp
- derived.cpp
- descriptor.cpp
- descriptor-io.cpp
- dot-product.cpp
- edit-input.cpp
- edit-output.cpp
- environment.cpp
- extrema.cpp
- external-unit.cpp
- file.cpp
- findloc.cpp
- format.cpp
- inquiry.cpp
- internal-unit.cpp
- io-api.cpp
- io-api-minimal.cpp
- io-error.cpp
- io-stmt.cpp
- iostat.cpp
- matmul-transpose.cpp
- matmul.cpp
- memory.cpp
- misc-intrinsic.cpp
- namelist.cpp
- non-tbp-dio.cpp
- numeric.cpp
- pointer.cpp
- product.cpp
- pseudo-unit.cpp
- ragged.cpp
- stat.cpp
- sum.cpp
- support.cpp
- terminator.cpp
- tools.cpp
- transformational.cpp
- type-code.cpp
- type-info.cpp
- unit.cpp
- utf.cpp
+file(GLOB_RECURSE public_headers
+ "${FLANG_RT_SOURCE_DIR}/include/flang/Runtime/*.h"
+ "${FLANG_RT_SOURCE_DIR}/include/flang/Common/*.h"
)
-enable_cuda_compilation(FortranRuntime "${supported_files}")
-enable_omp_offload_compilation("${supported_files}")
+file(GLOB_RECURSE private_headers
+ "${FLANG_RT_SOURCE_DIR}/lib/Runtime/*.h"
+ "${FLANG_RT_SOURCE_DIR}/lib/Common/*.h"
+ )
-if (NOT TARGET FortranFloat128Math)
- # If FortranFloat128Math is not defined, then we are not building
- # standalone FortranFloat128Math library. Instead, include
- # the relevant sources into FortranRuntime itself.
- # The information is provided via FortranFloat128MathILib
- # interface library.
- get_target_property(f128_sources
-FortranFloat128MathILib INTERFACE_SOURCES
+
+# Import changes from sibling FortranFloat128Math
+get_target_property(f128_sources
+ FortranFloat128MathILib INTERFACE_SOURCES
+ )
+if (f128_sources)
+ # The interface may define special macros for Float128Math files,
+ # so we need to propagate them.
+ get_target_property(f128_defs
+FortranFloat128MathILib INTERFACE_COMPILE_DEFINITIONS
)
- if (f128_sources)
-# The interface may define special macros for Float128Math files,
-# so we need to propagate them.
-get_target_property(f128_defs
- FortranFloat128MathILib INTERFACE_COMPILE_DEFINITIONS
- )
-set_property(SOURCE ${f128_sources}
- APPEND PROPERTY COMPILE_DEFINITIONS
- ${f128_defs}
- )
-list(APPEND sources ${f128_sources})
- endif()
-endif()
+ set_property(SOURCE ${f128_sources}
+APPEND PROPERTY COMPILE_DEFINITIONS
+${f128_defs}
+)
+else ()
+ set(f128_sources "")
+endif ()
-if (NOT DEFINED MSVC)
- add_flang_library(FortranRuntime
-${sources}
-LINK_LIBS
-FortranDecimal
+set(sources ${supported_sources} ${host_sources} ${f128_sources})
+
+if (NOT WIN32)
+ add_flangrt_library(flang_rt STATIC
+${sources}
INSTALL_WITH_TOOLCHAIN
+ADDITIONAL_HEADERS ${public_headers} ${private_headers}
)
+
+ enable_cuda_compilation(flang_rt "${supported_sources}")
+ enable_omp_offload_compilation(flang_rt "${supported_sources}")
+
+ # For unittests that depend on flang_rt. Should link to the static version
+ # of the library.
+ add_library(flang_rt.static ALIAS flang_rt)
+ add_library(flang_rt.unittest ALIAS flang_rt)
else()
- add_flang_library(FortranRuntime
-${sources}
-LINK_LIBS
-FortranDecimal
- )
- set(CMAKE_MSVC_RUNTIME_LIBRARY MultiThreaded)
- add_flang_library(FortranRuntime.static ${sources}
-LINK_LIBS
-FortranDecimal.static
-INSTALL_WITH_TOOLCHAIN)
- set_target_properties(FortranRuntime.static PROPERTIES FOLDER "Flang/Runtime
Libraries")
- set(CMAKE_MSVC_RUNTIME_LIBRARY MultiThreadedDLL)
- add_flang_library(FortranRuntime.dynamic ${sources}
-LINK_LIBS
-FortranDecimal.dynamic
-INSTALL_WITH_TOOLCHAIN)
- set_target_properties(FortranRuntime.dynamic PROPERTIES FOLDER
"Flang/Runtime Libraries")
- set(CMAKE_MSVC_RUNTIME_LIBRARY MultiThreadedDebug)
- add_flang_library(FortranRuntime.static_dbg ${sources}
-LINK_LIBS
-FortranDecimal.st
[llvm-branch-commits] [mlir] [mlir][Transforms] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
https://github.com/matthias-springer updated
https://github.com/llvm/llvm-project/pull/115816
>From b425caab826e5d9ad2f078d6f548f3215005bf7f Mon Sep 17 00:00:00 2001
From: Matthias Springer
Date: Tue, 12 Nov 2024 05:14:43 +0100
Subject: [PATCH 1/2] replace with multiple
---
mlir/include/mlir/IR/Builders.h | 2 +-
.../mlir/Transforms/DialectConversion.h | 24 ++-
.../Transforms/DecomposeCallGraphTypes.cpp| 40 ++---
.../Transforms/SparseTensorCodegen.cpp| 48 +++---
.../Utils/SparseTensorDescriptor.cpp | 21 ++-
mlir/lib/IR/Builders.cpp | 16 +-
.../Transforms/Utils/DialectConversion.cpp| 153 --
7 files changed, 186 insertions(+), 118 deletions(-)
diff --git a/mlir/include/mlir/IR/Builders.h b/mlir/include/mlir/IR/Builders.h
index 7ef03b87179523..78729376507208 100644
--- a/mlir/include/mlir/IR/Builders.h
+++ b/mlir/include/mlir/IR/Builders.h
@@ -353,7 +353,7 @@ class OpBuilder : public Builder {
/// selected insertion point. (E.g., because they are defined in a nested
/// region or because they are not visible in an IsolatedFromAbove region.)
static InsertPoint after(ArrayRef values,
- const PostDominanceInfo &domInfo);
+ const PostDominanceInfo *domInfo = nullptr);
/// Returns true if this insert point is set.
bool isSet() const { return (block != nullptr); }
diff --git a/mlir/include/mlir/Transforms/DialectConversion.h
b/mlir/include/mlir/Transforms/DialectConversion.h
index 5e5957170e646c..e461b7d11602a0 100644
--- a/mlir/include/mlir/Transforms/DialectConversion.h
+++ b/mlir/include/mlir/Transforms/DialectConversion.h
@@ -795,12 +795,32 @@ class ConversionPatternRewriter final : public
PatternRewriter {
/// patterns even if a failure is encountered during the rewrite step.
bool canRecoverFromRewriteFailure() const override { return true; }
- /// PatternRewriter hook for replacing an operation.
+ /// Replace the given operation with the new values. The number of op results
+ /// and replacement values must match. The types may differ: the dialect
+ /// conversion driver will reconcile any surviving type mismatches at the end
+ /// of the conversion process with source materializations. The given
+ /// operation is erased.
void replaceOp(Operation *op, ValueRange newValues) override;
- /// PatternRewriter hook for replacing an operation.
+ /// Replace the given operation with the results of the new op. The number of
+ /// op results must match. The types may differ: the dialect conversion
+ /// driver will reconcile any surviving type mismatches at the end of the
+ /// conversion process with source materializations. The original operation
+ /// is erased.
void replaceOp(Operation *op, Operation *newOp) override;
+ /// Replace the given operation with the new value range. The number of op
+ /// results and value ranges must match. If an original SSA value is replaced
+ /// by multiple SSA values (i.e., value range has more than 1 element), the
+ /// conversion driver will insert an argument materialization to convert the
+ /// N SSA values back into 1 SSA value of the original type. The given
+ /// operation is erased.
+ ///
+ /// Note: The argument materialization is a workaround until we have full 1:N
+ /// support in the dialect conversion. (It is going to disappear from both
+ /// `replaceOpWithMultiple` and `applySignatureConversion`.)
+ void replaceOpWithMultiple(Operation *op, ArrayRef newValues);
+
/// PatternRewriter hook for erasing a dead operation. The uses of this
/// operation *must* be made dead by the end of the conversion process,
/// otherwise an assert will be issued.
diff --git a/mlir/lib/Dialect/Func/Transforms/DecomposeCallGraphTypes.cpp
b/mlir/lib/Dialect/Func/Transforms/DecomposeCallGraphTypes.cpp
index de4aba2ed327db..a08764326a80b6 100644
--- a/mlir/lib/Dialect/Func/Transforms/DecomposeCallGraphTypes.cpp
+++ b/mlir/lib/Dialect/Func/Transforms/DecomposeCallGraphTypes.cpp
@@ -141,47 +141,31 @@ struct DecomposeCallGraphTypesForCallOp : public
OpConversionPattern {
getTypeConverter()));
}
-// Create the new result types for the new `CallOp` and track the indices
in
-// the new call op's results that correspond to the old call op's results.
-//
-// expandedResultIndices[i] = "list of new result indices that old result i
-// expanded to".
+// Create the new result types for the new `CallOp` and track the number of
+// replacement types for each original op result.
SmallVector newResultTypes;
-SmallVector, 4> expandedResultIndices;
+SmallVector expandedResultSizes;
for (Type resultType : op.getResultTypes()) {
unsigned oldSize = newResultTypes.size();
if (failed(typeConverter->convertType(resultType, newResultTypes)))
return failure();
-
[llvm-branch-commits] [mlir] [mlir][Transforms] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
matthias-springer wrote: > One question I have here is why not just insert right before the operation > that is being replaced? What is the need for trying to insert after one of > the values? Wouldnt' that remove the need for all of this complexity? It > gives you a singular place to insert. Actually, I think you are right. I was thinking of a case where two ops (in different locations) were replaced with the same 1:N replacement values. And I thought that we store one mapping pair in that case. But we actually store one per original value (and not per replacement value). I just noticed this as I was trying to write down a counter-example... Let me update the PR, I think this will simplify things quite a bit. https://github.com/llvm/llvm-project/pull/115816 ___ 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/19.x: [WebAssembly] Fix rethrow's index calculation (#114693) (PR #115844)
dschuff wrote: oh nevermind, I was confused; #114693 is closed, but this is the PR that implements the backport. https://github.com/llvm/llvm-project/pull/115844 ___ 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] [RISCV] Set DisableLatencyHeuristic to true (PR #115858)
mshockwave wrote: > This helps reduce register pressure for some cases. Is it possible to provide some numbers to back this up? Preferably using some well known benchmarks like SPEC and/or llvm-test-suite https://github.com/llvm/llvm-project/pull/115858 ___ 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] [NVPTX] Promote v2i8 to v2i16 (#111189) (PR #115081)
https://github.com/Artem-B updated
https://github.com/llvm/llvm-project/pull/115081
>From ed0fe30e7d4da94b13018e563971524e013c512f Mon Sep 17 00:00:00 2001
From: Manasij Mukherjee
Date: Fri, 4 Oct 2024 15:15:30 -0600
Subject: [PATCH] [NVPTX] Promote v2i8 to v2i16 (#89)
Promote v2i8 to v2i16, fixes a crash.
Re-enable a test in NVPTX/vector-returns.ll
Partial cherry-pick of fda2fea w/o the test which does not exist in release/19.x
https://github.com/llvm/llvm-project/issues/104864
---
llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp
b/llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp
index 6975412ce5d35b..b2153a7afe7365 100644
--- a/llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp
+++ b/llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp
@@ -229,6 +229,10 @@ static void ComputePTXValueVTs(const TargetLowering &TLI,
const DataLayout &DL,
// v*i8 are formally lowered as v4i8
EltVT = MVT::v4i8;
NumElts = (NumElts + 3) / 4;
+ } else if (EltVT.getSimpleVT() == MVT::i8 && NumElts == 2) {
+// v2i8 is promoted to v2i16
+NumElts = 1;
+EltVT = MVT::v2i16;
}
for (unsigned j = 0; j != NumElts; ++j) {
ValueVTs.push_back(EltVT);
___
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] [AMDGPU][Attributor] Make `AAAMDWavesPerEU` honor existing attribute (PR #114438)
https://github.com/choikwa approved this pull request. https://github.com/llvm/llvm-project/pull/114438 ___ 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] [AMDGPU][Attributor] Make `AAAMDWavesPerEU` honor existing attribute (PR #114438)
choikwa wrote: LGTM https://github.com/llvm/llvm-project/pull/114438 ___ 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] release/19.x: [clang-repl] Fix undefined lld::wasm::link symbol while building clangInterpreter for wasm (#113446) (PR #115848)
anutosh491 wrote: Hi @aheejin The checks pass as expected. I guess this should be ready ! https://github.com/llvm/llvm-project/pull/115848 ___ 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] [TySan] Fix struct access with different bases (PR #108385)
https://github.com/gbMattN updated
https://github.com/llvm/llvm-project/pull/108385
>From 82e7bec9acb33f2bd609e457ebe60febbc45e155 Mon Sep 17 00:00:00 2001
From: Matthew Nagy
Date: Thu, 12 Sep 2024 12:36:57 +
Subject: [PATCH 1/2] [TySan] Fix struct access with different bases
---
compiler-rt/lib/tysan/tysan.cpp | 5 +++
.../tysan/struct-offset-different-base.cpp| 33 +++
2 files changed, 38 insertions(+)
create mode 100644 compiler-rt/test/tysan/struct-offset-different-base.cpp
diff --git a/compiler-rt/lib/tysan/tysan.cpp b/compiler-rt/lib/tysan/tysan.cpp
index f627851d049e6a..c58fada778318f 100644
--- a/compiler-rt/lib/tysan/tysan.cpp
+++ b/compiler-rt/lib/tysan/tysan.cpp
@@ -128,6 +128,11 @@ static bool isAliasingLegalUp(tysan_type_descriptor *TDA,
break;
}
+ // This offset can't be negative. Therefore we must be accessing
something
+ // partially inside the last type
+ if (TDA->Struct.Members[Idx].Offset > OffsetA)
+Idx -= 1;
+
OffsetA -= TDA->Struct.Members[Idx].Offset;
TDA = TDA->Struct.Members[Idx].Type;
} else {
diff --git a/compiler-rt/test/tysan/struct-offset-different-base.cpp
b/compiler-rt/test/tysan/struct-offset-different-base.cpp
new file mode 100644
index 00..3e1d6f2a6a42f5
--- /dev/null
+++ b/compiler-rt/test/tysan/struct-offset-different-base.cpp
@@ -0,0 +1,33 @@
+// RUN: %clangxx_tysan -O0 %s -o %t && %run %t >%t.out 2>&1
+// RUN: FileCheck %s < %t.out
+
+// Modified reproducer from https://github.com/llvm/llvm-project/issues/105960
+
+#include
+
+struct inner {
+ char buffer;
+ int i;
+};
+
+void init_inner(inner *iPtr) {
+ iPtr->i = 0;
+}
+
+struct outer {
+ inner foo;
+char buffer;
+};
+
+int main(void) {
+outer *l = new outer();
+
+init_inner(&l->foo);
+
+int access_offsets_with_different_base = l->foo.i;
+printf("%d\n", access_offsets_with_different_base);
+
+return 0;
+}
+
+// CHECK-NOT: ERROR: TypeSanitizer: type-aliasing-violation
>From d82da2a9d32db14ca1809d3fa8e283d94c5cc5c9 Mon Sep 17 00:00:00 2001
From: gbMattN
Date: Tue, 12 Nov 2024 17:05:44 +
Subject: [PATCH 2/2] Changed test to check for output
---
compiler-rt/test/tysan/struct-offset-different-base.cpp | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/compiler-rt/test/tysan/struct-offset-different-base.cpp
b/compiler-rt/test/tysan/struct-offset-different-base.cpp
index 3e1d6f2a6a42f5..4563f7025bea48 100644
--- a/compiler-rt/test/tysan/struct-offset-different-base.cpp
+++ b/compiler-rt/test/tysan/struct-offset-different-base.cpp
@@ -1,5 +1,5 @@
// RUN: %clangxx_tysan -O0 %s -o %t && %run %t >%t.out 2>&1
-// RUN: FileCheck %s < %t.out
+// RUN: FileCheck %s --implicit-check-not ERROR < %t.out
// Modified reproducer from https://github.com/llvm/llvm-project/issues/105960
@@ -11,7 +11,7 @@ struct inner {
};
void init_inner(inner *iPtr) {
- iPtr->i = 0;
+ iPtr->i = 200;
}
struct outer {
@@ -25,9 +25,9 @@ int main(void) {
init_inner(&l->foo);
int access_offsets_with_different_base = l->foo.i;
-printf("%d\n", access_offsets_with_different_base);
+printf("Accessed value is %d\n", access_offsets_with_different_base);
return 0;
}
-// CHECK-NOT: ERROR: TypeSanitizer: type-aliasing-violation
+// CHECK: Accessed value is 200
___
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] [CGData] Refactor Global Merge Functions (PR #115750)
kyulee-com wrote: > Do we know why `OpIdx` is 4 here? This is confusing to me because it looks > like there is only one argument, `%5`. The `ignoreOp` function was initially designed for use with `llvm::StructuralHashWithDifferences`, where it iterates over operands within the same instruction. In this context, `OpIdx` is always within the valid range for the specified instruction. However, we now also utilize this function to determine if a particular operand can be ignored in certain instructions during this merge operation, as matched in the stable function summary— see `hasValidSharedConst()` for its use. So, there may be cases where an out-of-range index is passed from a different instruction context (although the entire function hash is matched). In this case, we should simply return false, as the target operand is not an interesting operand (that can be ignored/parameterized for merging). https://github.com/llvm/llvm-project/pull/115750 ___ 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] [RISCV] Set DisableLatencyHeuristic to true (PR #115858)
michaelmaitland wrote: For the recent scheduler patches, the common theme is we saw another target did something brought that functionality to RISC-V. How do we know that these changes are sensible defaults for RISC-V cores? Are you making measurements on any cores? Are they in order, out of order, both? In my experience tuning for different cores, there is often a difference between OOO and in order cores. https://github.com/llvm/llvm-project/pull/115858 ___ 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] [NVPTX] Promote v2i8 to v2i16 (#111189) (PR #115081)
Artem-B wrote: The CI check was unhappy because PR was based on the tree before 19.1.4. I've rebased it on top of the most recent commit. https://github.com/llvm/llvm-project/pull/115081 ___ 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] [libcxxabi] release/19.x: [libc++] Fix broken configuration system-libcxxabi on Apple (#110920) (PR #115892)
https://github.com/ldionne approved this pull request. I think this is reasonable to cherry-pick. It's fixing a somewhat more niche use case, but if that's useful to @mgorny I think it makes sense to backport. https://github.com/llvm/llvm-project/pull/115892 ___ 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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
matthias-springer wrote: > The only very high level conern I have is the use and need of > `InsertionPoint::after`. As I understand, this is a not-yet-implemented > optimization for the future for the purpose of reusing materializations by > calculating a better insertion point where it may dominate more operations > which might need exactly that materialization after pattern application as > well. Yes, that's correct. But this optimization is already implemented and it is quite deeply ingrained into the dialect conversion driver. SSA values are not replaced directly, but in a delayed fashion. The replacement value is stored in the `ConversionValueMapping` (a kind of `IRMapping`). We store not only user-specified replacement values but also materializations in there. The data structure is kind of a linked list: for an original value, we store a list of replacement values: the specified replacement value and materializations to a different type. In the "finalize" phase, the driver goes through that list to find a replacement/materialization value with the correct type. We cannot store more than one replacement/materialization value with the same type; the driver would just pick the first one that matches. Note: Computing an insertion point for a 1:1 materialization (or a 1:N block signature conversion) is much easier because there is only one SSA value (or one block). That's why computing the insertion point was trivial until now. > Is the current complexity of calculating the insertion point (and potentially > calculatin the post-dom tree, a O(n log n) operation) worth the gain of the > optimization? I am thinking that the better insertion point insertion logic > should probably be post-poned until we can measure its effectivness (and > avoid the risk of a premature optimization) and have something simpler and > working that does not worsen the status-quo for now instead. This PR also makes the `DominanceInfo` argument to `InsertPoint::after` optional in case of a single SSA value. (And no `DominanceInfo` is passed in that case.) For the most frequent case of 1:1 replacements, we do not compute a dominator tree at all. (And we are not doing any extra work.) In case of N:1 materializations, the implementation uses `DominanceInfo` and we create it during `ConversionPatternRewriter::replaceOpWithMultiple`. Unfortunately, it is not safe to reuse the same `DominanceInfo` object because a pattern could have made IR changes that invalidate the dominator tree. However, I believe `DominanceInfo` is quite "cheap" to use. The dominator tree is built lazily and it is built on a per-region basis. E.g., creating a new `DominanceInfo` and querying dominance for two ops in the same region will just build the dominator tree for that region. In case of two ops from different regions, the implementation will find the common ancestors (in the same region) and then compute the dominator tree only for that region. Long term, the `ConversionValueMapping` is going to disappear with the One-Shot Dialect Conversion. As part of that, I'm also thinking of removing the "materialization caching" mechanism and just building duplicate materializations (in the form of `unrealized_conversion_cast`, i.e., not calling the callback). These can then be CSE'd before calling the materialization callback. The CSE-ing will require `DominanceInfo`, but the same `DominanceInfo` can be reused for the entire dialect conversion because at this point of time we are done with pattern applications. https://github.com/llvm/llvm-project/pull/115816 ___ 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] [RISCV] Set DisableLatencyHeuristic to true (PR #115858)
wangpc-pp wrote: I added two experimental options: `-riscv-disable-latency-heuristic` and `-riscv-should-track-lane-masks` and evaluated the statistics (`regalloc.NumSpills`/`regalloc.NumReloads`) on llvm-test-suite (option: `-O3 -march=rva23u64`): 1. `-riscv-disable-latency-heuristic=true` and `-riscv-should-track-lane-masks=false`: ``` Program regalloc.NumSpills regalloc.NumReloads 00 10 diff 00 10 diff SingleSour...ce/UnitTests/matrix-types-spec8823.006166.00 -2657.00 15603.0013403.00 -2200.00 External/S...rate/510.parest_r/510.parest_r 43817.00 43262.00 -555.00 87058.0087033.00 -25.00 External/S...017speed/625.x264_s/625.x264_s2373.001991.00 -382.00 4808.00 4287.00 -521.00 External/S...2017rate/525.x264_r/525.x264_r2373.001991.00 -382.00 4808.00 4287.00 -521.00 MultiSourc...ks/ASCI_Purple/SMG2000/smg20002684.002334.00 -350.00 4820.00 4349.00 -471.00 MultiSourc...nchmarks/FreeBench/pifft/pifft 442.00 126.00 -316.00 595.00 281.00 -314.00 MultiSourc.../Applications/JM/ldecod/ldecod1335.001131.00 -204.00 2311.00 2142.00 -169.00 External/S...00.perlbench_s/600.perlbench_s4354.004154.00 -200.00 9615.00 9435.00 -180.00 External/S...00.perlbench_r/500.perlbench_r4354.004154.00 -200.00 9615.00 9435.00 -180.00 MultiSourc.../Applications/JM/lencod/lencod3368.003172.00 -196.00 7261.00 7069.00 -192.00 External/S...te/538.imagick_r/538.imagick_r4163.004000.00 -163.00 10354.00 9964.00 -390.00 MultiSourc...ch/consumer-lame/consumer-lame 722.00 559.00 -163.00 1098.00 994.00 -104.00 External/S...ed/638.imagick_s/638.imagick_s4163.004000.00 -163.00 10354.00 9964.00 -390.00 MultiSource/Applications/oggenc/oggenc 970.00 817.00 -153.00 2327.00 2120.00 -207.00 MultiSourc...e/Applications/ClamAV/clamscan2072.001937.00 -135.00 4836.00 4648.00 -188.00 regalloc.NumSpillsregalloc.NumReloads run 0010 diff 00 10 diff mean 87.747460 84.068699-3.678761 1371.475285 1357.146154 -3.792937 ``` 2. `-riscv-disable-latency-heuristic=false` and `-riscv-should-track-lane-masks=true`: ``` Program regalloc.NumSpills regalloc.NumReloads 00 01 diff 00 01 diff SingleSour...ce/UnitTests/matrix-types-spec 8823.008233.00 -590.00 15603.0015020.00 -583.00 MultiSourc...ch/consumer-lame/consumer-lame722.00 689.00 -33.00 1098.00 1065.00 -33.00 MultiSourc...s/Prolangs-C/football/football248.00 250.00 2.00 349.00 350.001.00 MultiSourc...ench/telecomm-gsm/telecomm-gsm182.00 181.00 -1.00 196.00 195.00 -1.00 MultiSourc...Benchmarks/7zip/7zip-benchmark 1272.001273.00 1.00 2436.00 2437.001.00 MicroBench...arks/ImageProcessing/Blur/blur114.00 113.00 -1.00 136.00 136.000.00 MultiSourc...rks/mediabench/gsm/toast/toast182.00 181.00 -1.00 196.00 195.00 -1.00 MultiSourc...gs-C/TimberWolfMC/timberwolfmc 1196.001195.00 -1.00 2036.00 2029.00 -7.00 SingleSour.../execute/GCC-C-execute-pr36321 0.00 0.00 0.00 0.00 SingleSour.../execute/GCC-C-execute-pr36077 0.00 0.00 0.00 0.00 SingleSour...xecute/GCC-C-execute-pr33779-1 0.00 0.00 0.00 0.00 SingleSour.../execute/GCC-C-execute-pr33669 0.00 0.00 0.00 0.00 SingleSour.../execute/GCC-C-execute-pr33631 0.00 0.00 0.00 0.00 SingleSour.../execute/GCC-C-execute-pr33382 0.00 0.00 0.00 0.00 SingleSour.../execute/GCC-C-execute-pr37102 0.00 0.00 0.00 0.00 regalloc.NumSpillsregalloc.NumReloads run 0001 diff
[llvm-branch-commits] [RISCV] Enable ShouldTrackLaneMasks when having vector instructions (PR #115843)
wangpc-pp wrote: Paste the data here as well I added two experimental options: `-riscv-disable-latency-heuristic` and `-riscv-should-track-lane-masks` and evaluated the statistics (`regalloc.NumSpills`/`regalloc.NumReloads`) on llvm-test-suite (option: `-O3 -march=rva23u64`): 1. `-riscv-disable-latency-heuristic=true` and `-riscv-should-track-lane-masks=false`: ``` Program regalloc.NumSpills regalloc.NumReloads 00 10 diff 00 10 diff SingleSour...ce/UnitTests/matrix-types-spec8823.006166.00 -2657.00 15603.0013403.00 -2200.00 External/S...rate/510.parest_r/510.parest_r 43817.00 43262.00 -555.00 87058.0087033.00 -25.00 External/S...017speed/625.x264_s/625.x264_s2373.001991.00 -382.00 4808.00 4287.00 -521.00 External/S...2017rate/525.x264_r/525.x264_r2373.001991.00 -382.00 4808.00 4287.00 -521.00 MultiSourc...ks/ASCI_Purple/SMG2000/smg20002684.002334.00 -350.00 4820.00 4349.00 -471.00 MultiSourc...nchmarks/FreeBench/pifft/pifft 442.00 126.00 -316.00 595.00 281.00 -314.00 MultiSourc.../Applications/JM/ldecod/ldecod1335.001131.00 -204.00 2311.00 2142.00 -169.00 External/S...00.perlbench_s/600.perlbench_s4354.004154.00 -200.00 9615.00 9435.00 -180.00 External/S...00.perlbench_r/500.perlbench_r4354.004154.00 -200.00 9615.00 9435.00 -180.00 MultiSourc.../Applications/JM/lencod/lencod3368.003172.00 -196.00 7261.00 7069.00 -192.00 External/S...te/538.imagick_r/538.imagick_r4163.004000.00 -163.00 10354.00 9964.00 -390.00 MultiSourc...ch/consumer-lame/consumer-lame 722.00 559.00 -163.00 1098.00 994.00 -104.00 External/S...ed/638.imagick_s/638.imagick_s4163.004000.00 -163.00 10354.00 9964.00 -390.00 MultiSource/Applications/oggenc/oggenc 970.00 817.00 -153.00 2327.00 2120.00 -207.00 MultiSourc...e/Applications/ClamAV/clamscan2072.001937.00 -135.00 4836.00 4648.00 -188.00 regalloc.NumSpillsregalloc.NumReloads run 0010 diff 00 10 diff mean 87.747460 84.068699-3.678761 1371.475285 1357.146154 -3.792937 ``` 2. `-riscv-disable-latency-heuristic=false` and `-riscv-should-track-lane-masks=true`: ``` Program regalloc.NumSpills regalloc.NumReloads 00 01 diff 00 01 diff SingleSour...ce/UnitTests/matrix-types-spec 8823.008233.00 -590.00 15603.0015020.00 -583.00 MultiSourc...ch/consumer-lame/consumer-lame722.00 689.00 -33.00 1098.00 1065.00 -33.00 MultiSourc...s/Prolangs-C/football/football248.00 250.00 2.00 349.00 350.001.00 MultiSourc...ench/telecomm-gsm/telecomm-gsm182.00 181.00 -1.00 196.00 195.00 -1.00 MultiSourc...Benchmarks/7zip/7zip-benchmark 1272.001273.00 1.00 2436.00 2437.001.00 MicroBench...arks/ImageProcessing/Blur/blur114.00 113.00 -1.00 136.00 136.000.00 MultiSourc...rks/mediabench/gsm/toast/toast182.00 181.00 -1.00 196.00 195.00 -1.00 MultiSourc...gs-C/TimberWolfMC/timberwolfmc 1196.001195.00 -1.00 2036.00 2029.00 -7.00 SingleSour.../execute/GCC-C-execute-pr36321 0.00 0.00 0.00 0.00 SingleSour.../execute/GCC-C-execute-pr36077 0.00 0.00 0.00 0.00 SingleSour...xecute/GCC-C-execute-pr33779-1 0.00 0.00 0.00 0.00 SingleSour.../execute/GCC-C-execute-pr33669 0.00 0.00 0.00 0.00 SingleSour.../execute/GCC-C-execute-pr33631 0.00 0.00 0.00 0.00 SingleSour.../execute/GCC-C-execute-pr33382 0.00 0.00 0.00 0.00 SingleSour.../execute/GCC-C-execute-pr37102 0.00 0.00 0.00 0.00 regalloc.NumSpillsregalloc.NumReloads run 00
[llvm-branch-commits] [llvm] [WebAssembly] Fix rethrow's index calculation (#114693) (PR #115844)
llvmbot wrote: @llvm/pr-subscribers-llvm-selectiondag Author: Heejin Ahn (aheejin) Changes So far we have assumed that we only rethrow the exception caught in the innermost EH pad. This is true in code we directly generate, but after inlining this may not be the case. For example, consider this code: ```ll ehcleanup: %0 = cleanuppad ... call @destructor cleanupret from %0 unwind label %catch.dispatch ``` If `destructor` gets inlined into this function, the code can be like ```ll ehcleanup: %0 = cleanuppad ... invoke @throwing_func to label %unreachale unwind label %catch.dispatch.i catch.dispatch.i: catchswitch ... [ label %catch.start.i ] catch.start.i: %1 = catchpad ... invoke @some_function to label %invoke.cont.i unwind label %terminate.i invoke.cont.i: catchret from %1 to label %destructor.exit destructor.exit: cleanupret from %0 unwind label %catch.dispatch ``` We lower a `cleanupret` into `rethrow`, which assumes it rethrows the exception caught by the nearest dominating EH pad. But after the inlining, the nearest dominating EH pad is not `ehcleanup` but `catch.start.i`. The problem exists in the same manner in the new (exnref) EH, because it assumes the exception comes from the nearest EH pad and saves an exnref from that EH pad and rethrows it (using `throw_ref`). This problem can be fixed easily if `cleanupret` has the basic block where its matching `cleanuppad` is. The bitcode instruction `cleanupret` kind of has that info (it has a token from the `cleanuppad`), but that info is lost when when we enter ISel, because `TargetSelectionDAG.td`'s `cleanupret` node does not have any arguments: https://github.com/llvm/llvm-project/blob/5091a359d9807db8f7d62375696f93fc34226969/llvm/include/llvm/Target/TargetSelectionDAG.td#L700 Note that `catchret` already has two basic block arguments, even though neither of them means `catchpad`'s BB. This PR adds the `cleanuppad`'s BB as an argument to `cleanupret` node in ISel and uses it in the Wasm backend. Because this node is also used in X86 backend we need to note its argument there too but nothing more needs to change there as long as X86 doesn't need it. --- - Details about changes in the Wasm backend: After this PR, our pseudo `RETHROW` instruction takes a BB, which means the EH pad whose exception it needs to rethrow. There are currently two ways to generate a `RETHROW`: one is from `llvm.wasm.rethrow` intrinsic and the other is from `CLEANUPRET` we discussed above. In case of `llvm.wasm.rethrow`, we add a '0' as a placeholder argument when it is lowered to a `RETHROW`, and change it to a BB in LateEHPrepare. As written in the comments, this PR doesn't change how this BB is computed. The BB argument will be converted to an immediate argument as with other control flow instructions in CFGStackify. In case of `CLEANUPRET`, it already has a BB argument pointing to an EH pad, so it is just converted to a `RETHROW` with the same BB argument in LateEHPrepare. This will also be lowered to an immediate in CFGStackify with other control flow instructions. --- Fixes #114600. --- Full diff: https://github.com/llvm/llvm-project/pull/115844.diff 11 Files Affected: - (modified) llvm/include/llvm/Target/TargetSelectionDAG.td (+5-1) - (modified) llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp (+4-2) - (modified) llvm/lib/Target/AArch64/AArch64InstrInfo.td (+1-1) - (modified) llvm/lib/Target/WebAssembly/WebAssemblyCFGStackify.cpp (+8-45) - (modified) llvm/lib/Target/WebAssembly/WebAssemblyISelDAGToDAG.cpp (+13) - (modified) llvm/lib/Target/WebAssembly/WebAssemblyInstrControl.td (+4-5) - (modified) llvm/lib/Target/WebAssembly/WebAssemblyLateEHPrepare.cpp (+31-3) - (modified) llvm/lib/Target/X86/X86InstrCompiler.td (+2-1) - (modified) llvm/test/CodeGen/WebAssembly/cfg-stackify-eh.mir (+7-4) - (modified) llvm/test/CodeGen/WebAssembly/exception-legacy.ll (+105) - (modified) llvm/test/CodeGen/WebAssembly/exception.mir (+1-1) ``diff diff --git a/llvm/include/llvm/Target/TargetSelectionDAG.td b/llvm/include/llvm/Target/TargetSelectionDAG.td index 46044aab79a832..e7895258438d26 100644 --- a/llvm/include/llvm/Target/TargetSelectionDAG.td +++ b/llvm/include/llvm/Target/TargetSelectionDAG.td @@ -231,6 +231,10 @@ def SDTCatchret : SDTypeProfile<0, 2, [ // catchret SDTCisVT<0, OtherVT>, SDTCisVT<1, OtherVT> ]>; +def SDTCleanupret : SDTypeProfile<0, 1, [ // cleanupret + SDTCisVT<0, OtherVT> +]>; + def SDTNone : SDTypeProfile<0, 0, []>; // ret, trap def SDTUBSANTrap : SDTypeProfile<0, 1, []>; // ubsantrap @@ -680,7 +684,7 @@ def brind : SDNode<"ISD::BRIND" , SDTBrind, [SDNPHasChain]>; def br : SDNode<"ISD::BR" , SDTBr, [SDNPHasChain]>; def catchret : SDNode<"ISD::CATCHRET" , SDTCatchret, [SDNPHasChain, SDNPSideEffect]>; -def cleanupret : SDNode<"ISD::CLEANUPRET" , SDTNone, [SDNPHasChain]>;
[llvm-branch-commits] [llvm] [WebAssembly] Fix rethrow's index calculation (#114693) (PR #115844)
llvmbot wrote: @llvm/pr-subscribers-backend-x86 Author: Heejin Ahn (aheejin) Changes So far we have assumed that we only rethrow the exception caught in the innermost EH pad. This is true in code we directly generate, but after inlining this may not be the case. For example, consider this code: ```ll ehcleanup: %0 = cleanuppad ... call @destructor cleanupret from %0 unwind label %catch.dispatch ``` If `destructor` gets inlined into this function, the code can be like ```ll ehcleanup: %0 = cleanuppad ... invoke @throwing_func to label %unreachale unwind label %catch.dispatch.i catch.dispatch.i: catchswitch ... [ label %catch.start.i ] catch.start.i: %1 = catchpad ... invoke @some_function to label %invoke.cont.i unwind label %terminate.i invoke.cont.i: catchret from %1 to label %destructor.exit destructor.exit: cleanupret from %0 unwind label %catch.dispatch ``` We lower a `cleanupret` into `rethrow`, which assumes it rethrows the exception caught by the nearest dominating EH pad. But after the inlining, the nearest dominating EH pad is not `ehcleanup` but `catch.start.i`. The problem exists in the same manner in the new (exnref) EH, because it assumes the exception comes from the nearest EH pad and saves an exnref from that EH pad and rethrows it (using `throw_ref`). This problem can be fixed easily if `cleanupret` has the basic block where its matching `cleanuppad` is. The bitcode instruction `cleanupret` kind of has that info (it has a token from the `cleanuppad`), but that info is lost when when we enter ISel, because `TargetSelectionDAG.td`'s `cleanupret` node does not have any arguments: https://github.com/llvm/llvm-project/blob/5091a359d9807db8f7d62375696f93fc34226969/llvm/include/llvm/Target/TargetSelectionDAG.td#L700 Note that `catchret` already has two basic block arguments, even though neither of them means `catchpad`'s BB. This PR adds the `cleanuppad`'s BB as an argument to `cleanupret` node in ISel and uses it in the Wasm backend. Because this node is also used in X86 backend we need to note its argument there too but nothing more needs to change there as long as X86 doesn't need it. --- - Details about changes in the Wasm backend: After this PR, our pseudo `RETHROW` instruction takes a BB, which means the EH pad whose exception it needs to rethrow. There are currently two ways to generate a `RETHROW`: one is from `llvm.wasm.rethrow` intrinsic and the other is from `CLEANUPRET` we discussed above. In case of `llvm.wasm.rethrow`, we add a '0' as a placeholder argument when it is lowered to a `RETHROW`, and change it to a BB in LateEHPrepare. As written in the comments, this PR doesn't change how this BB is computed. The BB argument will be converted to an immediate argument as with other control flow instructions in CFGStackify. In case of `CLEANUPRET`, it already has a BB argument pointing to an EH pad, so it is just converted to a `RETHROW` with the same BB argument in LateEHPrepare. This will also be lowered to an immediate in CFGStackify with other control flow instructions. --- Fixes #114600. --- Full diff: https://github.com/llvm/llvm-project/pull/115844.diff 11 Files Affected: - (modified) llvm/include/llvm/Target/TargetSelectionDAG.td (+5-1) - (modified) llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp (+4-2) - (modified) llvm/lib/Target/AArch64/AArch64InstrInfo.td (+1-1) - (modified) llvm/lib/Target/WebAssembly/WebAssemblyCFGStackify.cpp (+8-45) - (modified) llvm/lib/Target/WebAssembly/WebAssemblyISelDAGToDAG.cpp (+13) - (modified) llvm/lib/Target/WebAssembly/WebAssemblyInstrControl.td (+4-5) - (modified) llvm/lib/Target/WebAssembly/WebAssemblyLateEHPrepare.cpp (+31-3) - (modified) llvm/lib/Target/X86/X86InstrCompiler.td (+2-1) - (modified) llvm/test/CodeGen/WebAssembly/cfg-stackify-eh.mir (+7-4) - (modified) llvm/test/CodeGen/WebAssembly/exception-legacy.ll (+105) - (modified) llvm/test/CodeGen/WebAssembly/exception.mir (+1-1) ``diff diff --git a/llvm/include/llvm/Target/TargetSelectionDAG.td b/llvm/include/llvm/Target/TargetSelectionDAG.td index 46044aab79a832..e7895258438d26 100644 --- a/llvm/include/llvm/Target/TargetSelectionDAG.td +++ b/llvm/include/llvm/Target/TargetSelectionDAG.td @@ -231,6 +231,10 @@ def SDTCatchret : SDTypeProfile<0, 2, [ // catchret SDTCisVT<0, OtherVT>, SDTCisVT<1, OtherVT> ]>; +def SDTCleanupret : SDTypeProfile<0, 1, [ // cleanupret + SDTCisVT<0, OtherVT> +]>; + def SDTNone : SDTypeProfile<0, 0, []>; // ret, trap def SDTUBSANTrap : SDTypeProfile<0, 1, []>; // ubsantrap @@ -680,7 +684,7 @@ def brind : SDNode<"ISD::BRIND" , SDTBrind, [SDNPHasChain]>; def br : SDNode<"ISD::BR" , SDTBr, [SDNPHasChain]>; def catchret : SDNode<"ISD::CATCHRET" , SDTCatchret, [SDNPHasChain, SDNPSideEffect]>; -def cleanupret : SDNode<"ISD::CLEANUPRET" , SDTNone, [SDNPHasChain]>; +def
[llvm-branch-commits] [llvm] [WebAssembly] Fix rethrow's index calculation (#114693) (PR #115844)
https://github.com/aheejin updated https://github.com/llvm/llvm-project/pull/115844 >From 9d61762134fe2604a1a9c4a2a7d91ad709b88a83 Mon Sep 17 00:00:00 2001 From: Heejin Ahn Date: Tue, 5 Nov 2024 21:45:13 -0800 Subject: [PATCH] [WebAssembly] Fix rethrow's index calculation (#114693) So far we have assumed that we only rethrow the exception caught in the innermost EH pad. This is true in code we directly generate, but after inlining this may not be the case. For example, consider this code: ```ll ehcleanup: %0 = cleanuppad ... call @destructor cleanupret from %0 unwind label %catch.dispatch ``` If `destructor` gets inlined into this function, the code can be like ```ll ehcleanup: %0 = cleanuppad ... invoke @throwing_func to label %unreachale unwind label %catch.dispatch.i catch.dispatch.i: catchswitch ... [ label %catch.start.i ] catch.start.i: %1 = catchpad ... invoke @some_function to label %invoke.cont.i unwind label %terminate.i invoke.cont.i: catchret from %1 to label %destructor.exit destructor.exit: cleanupret from %0 unwind label %catch.dispatch ``` We lower a `cleanupret` into `rethrow`, which assumes it rethrows the exception caught by the nearest dominating EH pad. But after the inlining, the nearest dominating EH pad is not `ehcleanup` but `catch.start.i`. The problem exists in the same manner in the new (exnref) EH, because it assumes the exception comes from the nearest EH pad and saves an exnref from that EH pad and rethrows it (using `throw_ref`). This problem can be fixed easily if `cleanupret` has the basic block where its matching `cleanuppad` is. The bitcode instruction `cleanupret` kind of has that info (it has a token from the `cleanuppad`), but that info is lost when when we enter ISel, because `TargetSelectionDAG.td`'s `cleanupret` node does not have any arguments: https://github.com/llvm/llvm-project/blob/5091a359d9807db8f7d62375696f93fc34226969/llvm/include/llvm/Target/TargetSelectionDAG.td#L700 Note that `catchret` already has two basic block arguments, even though neither of them means `catchpad`'s BB. This PR adds the `cleanuppad`'s BB as an argument to `cleanupret` node in ISel and uses it in the Wasm backend. Because this node is also used in X86 backend we need to note its argument there too but nothing more needs to change there as long as X86 doesn't need it. --- - Details about changes in the Wasm backend: After this PR, our pseudo `RETHROW` instruction takes a BB, which means the EH pad whose exception it needs to rethrow. There are currently two ways to generate a `RETHROW`: one is from `llvm.wasm.rethrow` intrinsic and the other is from `CLEANUPRET` we discussed above. In case of `llvm.wasm.rethrow`, we add a '0' as a placeholder argument when it is lowered to a `RETHROW`, and change it to a BB in LateEHPrepare. As written in the comments, this PR doesn't change how this BB is computed. The BB argument will be converted to an immediate argument as with other control flow instructions in CFGStackify. In case of `CLEANUPRET`, it already has a BB argument pointing to an EH pad, so it is just converted to a `RETHROW` with the same BB argument in LateEHPrepare. This will also be lowered to an immediate in CFGStackify with other control flow instructions. --- Fixes #114600. --- .../include/llvm/Target/TargetSelectionDAG.td | 6 +- .../SelectionDAG/SelectionDAGBuilder.cpp | 6 +- llvm/lib/Target/AArch64/AArch64InstrInfo.td | 2 +- .../WebAssembly/WebAssemblyCFGStackify.cpp| 53 ++--- .../WebAssembly/WebAssemblyISelDAGToDAG.cpp | 13 +++ .../WebAssembly/WebAssemblyInstrControl.td| 9 +- .../WebAssembly/WebAssemblyLateEHPrepare.cpp | 34 +- llvm/lib/Target/X86/X86InstrCompiler.td | 3 +- .../CodeGen/WebAssembly/cfg-stackify-eh.mir | 11 +- .../CodeGen/WebAssembly/exception-legacy.ll | 105 ++ llvm/test/CodeGen/WebAssembly/exception.mir | 2 +- 11 files changed, 181 insertions(+), 63 deletions(-) diff --git a/llvm/include/llvm/Target/TargetSelectionDAG.td b/llvm/include/llvm/Target/TargetSelectionDAG.td index 46044aab79a832..e7895258438d26 100644 --- a/llvm/include/llvm/Target/TargetSelectionDAG.td +++ b/llvm/include/llvm/Target/TargetSelectionDAG.td @@ -231,6 +231,10 @@ def SDTCatchret : SDTypeProfile<0, 2, [ // catchret SDTCisVT<0, OtherVT>, SDTCisVT<1, OtherVT> ]>; +def SDTCleanupret : SDTypeProfile<0, 1, [ // cleanupret + SDTCisVT<0, OtherVT> +]>; + def SDTNone : SDTypeProfile<0, 0, []>; // ret, trap def SDTUBSANTrap : SDTypeProfile<0, 1, []>; // ubsantrap @@ -680,7 +684,7 @@ def brind : SDNode<"ISD::BRIND" , SDTBrind, [SDNPHasChain]>; def br : SDNode<"ISD::BR" , SDTBr, [SDNPHasChain]>; def catchret : SDNode<"ISD::CATCHRET" , SDTCatchret, [SDNPHasChain, SDNPSideEffect]>; -def cleanupret : SDNode<"ISD::CLEANUPRET" , SDTNone, [SDNPHasChain]>; +def cleanupret : SDNode<"
[llvm-branch-commits] [llvm] [WebAssembly] Fix rethrow's index calculation (#114693) (PR #115844)
https://github.com/aheejin created https://github.com/llvm/llvm-project/pull/115844 So far we have assumed that we only rethrow the exception caught in the innermost EH pad. This is true in code we directly generate, but after inlining this may not be the case. For example, consider this code: ```ll ehcleanup: %0 = cleanuppad ... call @destructor cleanupret from %0 unwind label %catch.dispatch ``` If `destructor` gets inlined into this function, the code can be like ```ll ehcleanup: %0 = cleanuppad ... invoke @throwing_func to label %unreachale unwind label %catch.dispatch.i catch.dispatch.i: catchswitch ... [ label %catch.start.i ] catch.start.i: %1 = catchpad ... invoke @some_function to label %invoke.cont.i unwind label %terminate.i invoke.cont.i: catchret from %1 to label %destructor.exit destructor.exit: cleanupret from %0 unwind label %catch.dispatch ``` We lower a `cleanupret` into `rethrow`, which assumes it rethrows the exception caught by the nearest dominating EH pad. But after the inlining, the nearest dominating EH pad is not `ehcleanup` but `catch.start.i`. The problem exists in the same manner in the new (exnref) EH, because it assumes the exception comes from the nearest EH pad and saves an exnref from that EH pad and rethrows it (using `throw_ref`). This problem can be fixed easily if `cleanupret` has the basic block where its matching `cleanuppad` is. The bitcode instruction `cleanupret` kind of has that info (it has a token from the `cleanuppad`), but that info is lost when when we enter ISel, because `TargetSelectionDAG.td`'s `cleanupret` node does not have any arguments: https://github.com/llvm/llvm-project/blob/5091a359d9807db8f7d62375696f93fc34226969/llvm/include/llvm/Target/TargetSelectionDAG.td#L700 Note that `catchret` already has two basic block arguments, even though neither of them means `catchpad`'s BB. This PR adds the `cleanuppad`'s BB as an argument to `cleanupret` node in ISel and uses it in the Wasm backend. Because this node is also used in X86 backend we need to note its argument there too but nothing more needs to change there as long as X86 doesn't need it. --- - Details about changes in the Wasm backend: After this PR, our pseudo `RETHROW` instruction takes a BB, which means the EH pad whose exception it needs to rethrow. There are currently two ways to generate a `RETHROW`: one is from `llvm.wasm.rethrow` intrinsic and the other is from `CLEANUPRET` we discussed above. In case of `llvm.wasm.rethrow`, we add a '0' as a placeholder argument when it is lowered to a `RETHROW`, and change it to a BB in LateEHPrepare. As written in the comments, this PR doesn't change how this BB is computed. The BB argument will be converted to an immediate argument as with other control flow instructions in CFGStackify. In case of `CLEANUPRET`, it already has a BB argument pointing to an EH pad, so it is just converted to a `RETHROW` with the same BB argument in LateEHPrepare. This will also be lowered to an immediate in CFGStackify with other control flow instructions. --- Fixes #114600. >From 9d61762134fe2604a1a9c4a2a7d91ad709b88a83 Mon Sep 17 00:00:00 2001 From: Heejin Ahn Date: Tue, 5 Nov 2024 21:45:13 -0800 Subject: [PATCH] [WebAssembly] Fix rethrow's index calculation (#114693) So far we have assumed that we only rethrow the exception caught in the innermost EH pad. This is true in code we directly generate, but after inlining this may not be the case. For example, consider this code: ```ll ehcleanup: %0 = cleanuppad ... call @destructor cleanupret from %0 unwind label %catch.dispatch ``` If `destructor` gets inlined into this function, the code can be like ```ll ehcleanup: %0 = cleanuppad ... invoke @throwing_func to label %unreachale unwind label %catch.dispatch.i catch.dispatch.i: catchswitch ... [ label %catch.start.i ] catch.start.i: %1 = catchpad ... invoke @some_function to label %invoke.cont.i unwind label %terminate.i invoke.cont.i: catchret from %1 to label %destructor.exit destructor.exit: cleanupret from %0 unwind label %catch.dispatch ``` We lower a `cleanupret` into `rethrow`, which assumes it rethrows the exception caught by the nearest dominating EH pad. But after the inlining, the nearest dominating EH pad is not `ehcleanup` but `catch.start.i`. The problem exists in the same manner in the new (exnref) EH, because it assumes the exception comes from the nearest EH pad and saves an exnref from that EH pad and rethrows it (using `throw_ref`). This problem can be fixed easily if `cleanupret` has the basic block where its matching `cleanuppad` is. The bitcode instruction `cleanupret` kind of has that info (it has a token from the `cleanuppad`), but that info is lost when when we enter ISel, because `TargetSelectionDAG.td`'s `cleanupret` node does not have any arguments: https://github.com/llvm/llvm-project/blob/5091a359d9807db8f7d62375696f93fc34226969/llvm/i
[llvm-branch-commits] [llvm] [WebAssembly] Fix rethrow's index calculation (#114693) (PR #115844)
llvmbot wrote: @llvm/pr-subscribers-backend-aarch64 Author: Heejin Ahn (aheejin) Changes So far we have assumed that we only rethrow the exception caught in the innermost EH pad. This is true in code we directly generate, but after inlining this may not be the case. For example, consider this code: ```ll ehcleanup: %0 = cleanuppad ... call @destructor cleanupret from %0 unwind label %catch.dispatch ``` If `destructor` gets inlined into this function, the code can be like ```ll ehcleanup: %0 = cleanuppad ... invoke @throwing_func to label %unreachale unwind label %catch.dispatch.i catch.dispatch.i: catchswitch ... [ label %catch.start.i ] catch.start.i: %1 = catchpad ... invoke @some_function to label %invoke.cont.i unwind label %terminate.i invoke.cont.i: catchret from %1 to label %destructor.exit destructor.exit: cleanupret from %0 unwind label %catch.dispatch ``` We lower a `cleanupret` into `rethrow`, which assumes it rethrows the exception caught by the nearest dominating EH pad. But after the inlining, the nearest dominating EH pad is not `ehcleanup` but `catch.start.i`. The problem exists in the same manner in the new (exnref) EH, because it assumes the exception comes from the nearest EH pad and saves an exnref from that EH pad and rethrows it (using `throw_ref`). This problem can be fixed easily if `cleanupret` has the basic block where its matching `cleanuppad` is. The bitcode instruction `cleanupret` kind of has that info (it has a token from the `cleanuppad`), but that info is lost when when we enter ISel, because `TargetSelectionDAG.td`'s `cleanupret` node does not have any arguments: https://github.com/llvm/llvm-project/blob/5091a359d9807db8f7d62375696f93fc34226969/llvm/include/llvm/Target/TargetSelectionDAG.td#L700 Note that `catchret` already has two basic block arguments, even though neither of them means `catchpad`'s BB. This PR adds the `cleanuppad`'s BB as an argument to `cleanupret` node in ISel and uses it in the Wasm backend. Because this node is also used in X86 backend we need to note its argument there too but nothing more needs to change there as long as X86 doesn't need it. --- - Details about changes in the Wasm backend: After this PR, our pseudo `RETHROW` instruction takes a BB, which means the EH pad whose exception it needs to rethrow. There are currently two ways to generate a `RETHROW`: one is from `llvm.wasm.rethrow` intrinsic and the other is from `CLEANUPRET` we discussed above. In case of `llvm.wasm.rethrow`, we add a '0' as a placeholder argument when it is lowered to a `RETHROW`, and change it to a BB in LateEHPrepare. As written in the comments, this PR doesn't change how this BB is computed. The BB argument will be converted to an immediate argument as with other control flow instructions in CFGStackify. In case of `CLEANUPRET`, it already has a BB argument pointing to an EH pad, so it is just converted to a `RETHROW` with the same BB argument in LateEHPrepare. This will also be lowered to an immediate in CFGStackify with other control flow instructions. --- Fixes #114600. --- Full diff: https://github.com/llvm/llvm-project/pull/115844.diff 11 Files Affected: - (modified) llvm/include/llvm/Target/TargetSelectionDAG.td (+5-1) - (modified) llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp (+4-2) - (modified) llvm/lib/Target/AArch64/AArch64InstrInfo.td (+1-1) - (modified) llvm/lib/Target/WebAssembly/WebAssemblyCFGStackify.cpp (+8-45) - (modified) llvm/lib/Target/WebAssembly/WebAssemblyISelDAGToDAG.cpp (+13) - (modified) llvm/lib/Target/WebAssembly/WebAssemblyInstrControl.td (+4-5) - (modified) llvm/lib/Target/WebAssembly/WebAssemblyLateEHPrepare.cpp (+31-3) - (modified) llvm/lib/Target/X86/X86InstrCompiler.td (+2-1) - (modified) llvm/test/CodeGen/WebAssembly/cfg-stackify-eh.mir (+7-4) - (modified) llvm/test/CodeGen/WebAssembly/exception-legacy.ll (+105) - (modified) llvm/test/CodeGen/WebAssembly/exception.mir (+1-1) ``diff diff --git a/llvm/include/llvm/Target/TargetSelectionDAG.td b/llvm/include/llvm/Target/TargetSelectionDAG.td index 46044aab79a832..e7895258438d26 100644 --- a/llvm/include/llvm/Target/TargetSelectionDAG.td +++ b/llvm/include/llvm/Target/TargetSelectionDAG.td @@ -231,6 +231,10 @@ def SDTCatchret : SDTypeProfile<0, 2, [ // catchret SDTCisVT<0, OtherVT>, SDTCisVT<1, OtherVT> ]>; +def SDTCleanupret : SDTypeProfile<0, 1, [ // cleanupret + SDTCisVT<0, OtherVT> +]>; + def SDTNone : SDTypeProfile<0, 0, []>; // ret, trap def SDTUBSANTrap : SDTypeProfile<0, 1, []>; // ubsantrap @@ -680,7 +684,7 @@ def brind : SDNode<"ISD::BRIND" , SDTBrind, [SDNPHasChain]>; def br : SDNode<"ISD::BR" , SDTBr, [SDNPHasChain]>; def catchret : SDNode<"ISD::CATCHRET" , SDTCatchret, [SDNPHasChain, SDNPSideEffect]>; -def cleanupret : SDNode<"ISD::CLEANUPRET" , SDTNone, [SDNPHasChain]>; +
[llvm-branch-commits] [clang] d23ed7b - Revert "[Clang-Repl] Add support for out-of-process execution. (#110418)"
Author: SahilPatidar
Date: 2024-11-12T16:46:14+05:30
New Revision: d23ed7b82735b367501949541b7194bbb6b4fb86
URL:
https://github.com/llvm/llvm-project/commit/d23ed7b82735b367501949541b7194bbb6b4fb86
DIFF:
https://github.com/llvm/llvm-project/commit/d23ed7b82735b367501949541b7194bbb6b4fb86.diff
LOG: Revert "[Clang-Repl] Add support for out-of-process execution. (#110418)"
This reverts commit 3183b3aad130ac6754f294046c008a85b9925894.
Added:
Modified:
clang/include/clang/Interpreter/Interpreter.h
clang/lib/Interpreter/CMakeLists.txt
clang/lib/Interpreter/Interpreter.cpp
clang/tools/clang-repl/CMakeLists.txt
clang/tools/clang-repl/ClangRepl.cpp
Removed:
clang/include/clang/Interpreter/RemoteJITUtils.h
clang/lib/Interpreter/RemoteJITUtils.cpp
clang/test/Interpreter/out-of-process.cpp
diff --git a/clang/include/clang/Interpreter/Interpreter.h
b/clang/include/clang/Interpreter/Interpreter.h
index 42486304083f4e..1230a3a7016fae 100644
--- a/clang/include/clang/Interpreter/Interpreter.h
+++ b/clang/include/clang/Interpreter/Interpreter.h
@@ -20,7 +20,6 @@
#include "llvm/ADT/DenseMap.h"
#include "llvm/ExecutionEngine/JITSymbol.h"
-#include "llvm/ExecutionEngine/Orc/ExecutorProcessControl.h"
#include "llvm/ExecutionEngine/Orc/Shared/ExecutorAddress.h"
#include "llvm/Support/Error.h"
#include
@@ -130,14 +129,10 @@ class Interpreter {
public:
virtual ~Interpreter();
static llvm::Expected>
- create(std::unique_ptr CI,
- std::unique_ptr JITBuilder = nullptr);
+ create(std::unique_ptr CI);
static llvm::Expected>
createWithCUDA(std::unique_ptr CI,
std::unique_ptr DCI);
- static llvm::Expected>
- createLLJITBuilder(std::unique_ptr EPC,
- llvm::StringRef OrcRuntimePath);
const ASTContext &getASTContext() const;
ASTContext &getASTContext();
const CompilerInstance *getCompilerInstance() const;
diff --git a/clang/include/clang/Interpreter/RemoteJITUtils.h
b/clang/include/clang/Interpreter/RemoteJITUtils.h
deleted file mode 100644
index 8705a3b1f669de..00
--- a/clang/include/clang/Interpreter/RemoteJITUtils.h
+++ /dev/null
@@ -1,38 +0,0 @@
-//===-- RemoteJITUtils.h - Utilities for remote-JITing --*- C++
-*-===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-//
-// Utilities for ExecutorProcessControl-based remote JITing with Orc and
-// JITLink.
-//
-//===--===//
-
-#ifndef LLVM_CLANG_INTERPRETER_REMOTEJITUTILS_H
-#define LLVM_CLANG_INTERPRETER_REMOTEJITUTILS_H
-
-#include "llvm/ADT/StringRef.h"
-#include "llvm/ExecutionEngine/Orc/Core.h"
-#include "llvm/ExecutionEngine/Orc/Layer.h"
-#include "llvm/ExecutionEngine/Orc/SimpleRemoteEPC.h"
-#include "llvm/Support/Error.h"
-
-#include
-#include
-#include
-
-llvm::Expected>
-launchExecutor(llvm::StringRef ExecutablePath, bool UseSharedMemory,
- llvm::StringRef SlabAllocateSizeString);
-
-/// Create a JITLinkExecutor that connects to the given network address
-/// through a TCP socket. A valid NetworkAddress provides hostname and port,
-/// e.g. localhost:2.
-llvm::Expected>
-connectTCPSocket(llvm::StringRef NetworkAddress, bool UseSharedMemory,
- llvm::StringRef SlabAllocateSizeString);
-
-#endif // LLVM_CLANG_INTERPRETER_REMOTEJITUTILS_H
diff --git a/clang/lib/Interpreter/CMakeLists.txt
b/clang/lib/Interpreter/CMakeLists.txt
index eb99e316ebc0a7..d5ffe78251d253 100644
--- a/clang/lib/Interpreter/CMakeLists.txt
+++ b/clang/lib/Interpreter/CMakeLists.txt
@@ -25,7 +25,6 @@ add_clang_library(clangInterpreter
Interpreter.cpp
InterpreterValuePrinter.cpp
InterpreterUtils.cpp
- RemoteJITUtils.cpp
Value.cpp
${WASM_SRC}
PARTIAL_SOURCES_INTENDED
diff --git a/clang/lib/Interpreter/Interpreter.cpp
b/clang/lib/Interpreter/Interpreter.cpp
index 8eacbc6b713a19..bc96da811d44cb 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -44,7 +44,6 @@
#include "clang/Sema/Lookup.h"
#include "clang/Serialization/ObjectFilePCHContainerReader.h"
#include "llvm/ExecutionEngine/JITSymbol.h"
-#include "llvm/ExecutionEngine/Orc/EPCDynamicLibrarySearchGenerator.h"
#include "llvm/ExecutionEngine/Orc/LLJIT.h"
#include "llvm/IR/Module.h"
#include "llvm/Support/Errc.h"
@@ -457,11 +456,10 @@ const char *const Runtimes = R"(
)";
llvm::Expected>
-Interpreter::create(std::unique_ptr CI,
-std::unique_ptr JB) {
+Interpreter::create(std::unique_ptr CI) {
llvm::Error Err = llvm::Error::success();
- auto Interp = std::unique_ptr(
- new Inte
[llvm-branch-commits] [compiler-rt] [TySan] Improved compatability for tests (PR #96507)
@@ -23,8 +24,8 @@ void f(int m) {
}
// CHECK: TypeSanitizer: type-aliasing-violation on address
- // CHECK-NEXT: READ of size 2 at {{.+}} with type short accesses an existing
object of type long long
- // CHECK-NEXT:in f violation-pr47137.c:30
+ // CHECK-NEXT: READ of size 2 at {{.+}} with type short accesses an existing
object of type {{(long)+}}
gbMattN wrote:
Good catch, will change that 👍
https://github.com/llvm/llvm-project/pull/96507
___
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] [TySan] Improved compatability for tests (PR #96507)
@@ -18,7 +18,7 @@ int main(void) {
// CHECK: TypeSanitizer: type-aliasing-violation on address
// CHECK-NEXT: WRITE of size 8 at {{.+}} with type double accesses an
existing object of type float
- // CHECK-NEXT: in main violation-pr45282.c:25
+ // CHECK-NEXT: in main {{.*violation-pr45282.c:25.*}}
gbMattN wrote:
Checked and the trailing .* can indeed be left out, I'll change that
Compiler-rt tests tend to have the file name in the check lines because you
want to make sure that the sanitizer correctly informs the user where the
problem is.
https://github.com/llvm/llvm-project/pull/96507
___
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] [TySan] Improved compatability for tests (PR #96507)
https://github.com/gbMattN updated
https://github.com/llvm/llvm-project/pull/96507
>From c684ebd51c77f31a03eb874f5d09d4131c648b0b Mon Sep 17 00:00:00 2001
From: Matthew Nagy
Date: Fri, 28 Jun 2024 16:48:53 +
Subject: [PATCH] [TySan] Improves compatability for tests
---
compiler-rt/test/tysan/violation-pr45282.c | 2 +-
compiler-rt/test/tysan/violation-pr47137.c | 5 +++--
compiler-rt/test/tysan/violation-pr62544.c | 2 +-
compiler-rt/test/tysan/violation-pr62828.cpp | 2 +-
compiler-rt/test/tysan/violation-pr68655.cpp | 2 +-
compiler-rt/test/tysan/violation-pr86685.c | 2 +-
6 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/compiler-rt/test/tysan/violation-pr45282.c
b/compiler-rt/test/tysan/violation-pr45282.c
index f3583d6be6f6a3..769aee1979d7eb 100644
--- a/compiler-rt/test/tysan/violation-pr45282.c
+++ b/compiler-rt/test/tysan/violation-pr45282.c
@@ -18,7 +18,7 @@ int main(void) {
// CHECK: TypeSanitizer: type-aliasing-violation on address
// CHECK-NEXT: WRITE of size 8 at {{.+}} with type double accesses an
existing object of type float
- // CHECK-NEXT: in main violation-pr45282.c:25
+ // CHECK-NEXT: in main {{.*violation-pr45282.c:25}}
// loop of problems
for (j = 2; j <= 4; ++j) {
diff --git a/compiler-rt/test/tysan/violation-pr47137.c
b/compiler-rt/test/tysan/violation-pr47137.c
index 3987128ff6fc67..85bad7bf6c85b7 100644
--- a/compiler-rt/test/tysan/violation-pr47137.c
+++ b/compiler-rt/test/tysan/violation-pr47137.c
@@ -4,6 +4,7 @@
// https://github.com/llvm/llvm-project/issues/47137
#include
#include
+#include
void f(int m) {
int n = (4 * m + 2) / 3;
@@ -23,8 +24,8 @@ void f(int m) {
}
// CHECK: TypeSanitizer: type-aliasing-violation on address
- // CHECK-NEXT: READ of size 2 at {{.+}} with type short accesses an existing
object of type long long
- // CHECK-NEXT:in f violation-pr47137.c:30
+ // CHECK-NEXT: READ of size 2 at {{.+}} with type short accesses an existing
object of type long{{( long)?}}
+ // CHECK-NEXT:in f {{.*violation-pr47137.c:31}}
for (int i = 0, j = 0; j < 4 * m; i += 4, j += 3) {
for (int k = 0; k < 3; k++) {
((uint16_t *)a)[j + k] = ((uint16_t *)a)[i + k];
diff --git a/compiler-rt/test/tysan/violation-pr62544.c
b/compiler-rt/test/tysan/violation-pr62544.c
index 30610925ba385f..cd6a10343d3ee5 100644
--- a/compiler-rt/test/tysan/violation-pr62544.c
+++ b/compiler-rt/test/tysan/violation-pr62544.c
@@ -18,7 +18,7 @@ int main() {
// CHECK: TypeSanitizer: type-aliasing-violation on address
// CHECK-NEXT: WRITE of size 2 at {{.+}} with type short accesses an
existing object of type int
- // CHECK-NEXT: in main violation-pr62544.c:22
+ // CHECK-NEXT: in main {{.*violation-pr62544.c:22}}
*e = 3;
printf("%d\n", a);
}
diff --git a/compiler-rt/test/tysan/violation-pr62828.cpp
b/compiler-rt/test/tysan/violation-pr62828.cpp
index 33003df9761f52..611c27bab773bb 100644
--- a/compiler-rt/test/tysan/violation-pr62828.cpp
+++ b/compiler-rt/test/tysan/violation-pr62828.cpp
@@ -24,7 +24,7 @@ short *test1(int_v8 *cast_c_array, short_v8 *shuf_c_array1,
int *ptr) {
// CHECK: ERROR: TypeSanitizer: type-aliasing-violation on address
// CHECK-NEXT: READ of size 2 at {{.+}} with type short accesses an existing
object of type int
- // CHECK-NEXT:in test1(int (*) [8], short (*) [8], int*)
violation-pr62828.cpp:29
+ // CHECK-NEXT:in test1(int (*) [8], short (*) [8], int*)
{{.*violation-pr62828.cpp:29}}
for (int i3 = 0; i3 < 4; ++i3) {
output2[i3] = input2[(i3 * 2)];
}
diff --git a/compiler-rt/test/tysan/violation-pr68655.cpp
b/compiler-rt/test/tysan/violation-pr68655.cpp
index ac20f8c94e1ffd..8d71336eb9c535 100644
--- a/compiler-rt/test/tysan/violation-pr68655.cpp
+++ b/compiler-rt/test/tysan/violation-pr68655.cpp
@@ -9,7 +9,7 @@ struct S1 {
// CHECK: TypeSanitizer: type-aliasing-violation on address
// CHECK-NEXT: READ of size 4 at {{.+}} with type int accesses an existing
object of type long long (in S1 at offset 0)
-// CHECK-NEXT: in copyMem(S1*, S1*) violation-pr68655.cpp:19
+// CHECK-NEXT: in copyMem(S1*, S1*) {{.*violation-pr68655.cpp:19}}
void inline copyMem(S1 *dst, S1 *src) {
unsigned *d = reinterpret_cast(dst);
diff --git a/compiler-rt/test/tysan/violation-pr86685.c
b/compiler-rt/test/tysan/violation-pr86685.c
index fe4fd82af5fdd2..41be462cbacdda 100644
--- a/compiler-rt/test/tysan/violation-pr86685.c
+++ b/compiler-rt/test/tysan/violation-pr86685.c
@@ -13,7 +13,7 @@ void foo(int *s, float *f, long n) {
// CHECK: TypeSanitizer: type-aliasing-violation on address
// CHECK-NEXT: WRITE of size 4 at {{.+}} with type int accesses an
existing object of type float
-// CHECK-NEXT: #0 {{.+}} in foo violation-pr86685.c:17
+// CHECK-NEXT: #0 {{.+}} in foo {{.*violation-pr86685.c:17}}
*s = 4;
}
}
___
llvm-branch-commits mailing list
[llvm-branch-commits] [RISCV] Enable ShouldTrackLaneMasks when having vector instructions (PR #115843)
llvmbot wrote:
@llvm/pr-subscribers-backend-risc-v
Author: Pengcheng Wang (wangpc-pp)
Changes
This can help to improve the register pressure for LMUL>1 cases.
---
Patch is 202.84 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm-project/pull/115843.diff
40 Files Affected:
- (modified) llvm/lib/Target/RISCV/RISCVSubtarget.cpp (+4)
- (modified) llvm/test/CodeGen/RISCV/early-clobber-tied-def-subreg-liveness.ll
(+22-23)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vector-i8-index-cornercase.ll
(+16-16)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-buildvec-of-binop.ll
(+4-4)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-deinterleave-load.ll
(+10-10)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-buildvec.ll
(+121-133)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-interleave.ll (+2-2)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fptrunc-vp.ll (+2-2)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-insert-subvector.ll
(+9-10)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int-buildvec.ll (+26-26)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int-interleave.ll (+2-2)
- (modified)
llvm/test/CodeGen/RISCV/rvv/fixed-vectors-shuffle-changes-length.ll (+12-12)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-shuffle-concat.ll
(+18-16)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-shuffle-exact-vlen.ll
(+1-1)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-shuffle-reverse.ll
(+127-116)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-strided-load-combine.ll
(+18-18)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-trunc-vp.ll (+59-70)
- (modified) llvm/test/CodeGen/RISCV/rvv/fixed-vectors-vpgather.ll (+2-2)
- (modified) llvm/test/CodeGen/RISCV/rvv/mgather-sdnode.ll (+14-14)
- (modified) llvm/test/CodeGen/RISCV/rvv/named-vector-shuffle-reverse.ll
(+212-244)
- (modified) llvm/test/CodeGen/RISCV/rvv/splat-vector-split-i64-vl-sdnode.ll
(+30-30)
- (modified) llvm/test/CodeGen/RISCV/rvv/vector-deinterleave-fixed.ll (+10-10)
- (modified) llvm/test/CodeGen/RISCV/rvv/vector-deinterleave.ll (+22-22)
- (modified) llvm/test/CodeGen/RISCV/rvv/vector-interleave-fixed.ll (+4-4)
- (modified) llvm/test/CodeGen/RISCV/rvv/vector-interleave-store.ll (+2-2)
- (modified) llvm/test/CodeGen/RISCV/rvv/vector-interleave.ll (+108-44)
- (modified) llvm/test/CodeGen/RISCV/rvv/vfadd-constrained-sdnode.ll (+18-26)
- (modified) llvm/test/CodeGen/RISCV/rvv/vfadd-sdnode.ll (+18-26)
- (modified) llvm/test/CodeGen/RISCV/rvv/vfdiv-constrained-sdnode.ll (+18-26)
- (modified) llvm/test/CodeGen/RISCV/rvv/vfdiv-sdnode.ll (+18-26)
- (modified) llvm/test/CodeGen/RISCV/rvv/vfmax-sdnode.ll (+18-26)
- (modified) llvm/test/CodeGen/RISCV/rvv/vfmin-sdnode.ll (+18-26)
- (modified) llvm/test/CodeGen/RISCV/rvv/vfmul-constrained-sdnode.ll (+18-26)
- (modified) llvm/test/CodeGen/RISCV/rvv/vfmul-sdnode.ll (+18-26)
- (modified) llvm/test/CodeGen/RISCV/rvv/vfptoi-sdnode.ll (+16-24)
- (modified) llvm/test/CodeGen/RISCV/rvv/vfsqrt-constrained-sdnode.ll (+4-8)
- (modified) llvm/test/CodeGen/RISCV/rvv/vfsqrt-sdnode.ll (+4-8)
- (modified) llvm/test/CodeGen/RISCV/rvv/vfsub-constrained-sdnode.ll (+18-26)
- (modified) llvm/test/CodeGen/RISCV/rvv/vfsub-sdnode.ll (+18-26)
- (modified) llvm/test/CodeGen/RISCV/rvv/vitofp-sdnode.ll (+16-16)
``diff
diff --git a/llvm/lib/Target/RISCV/RISCVSubtarget.cpp
b/llvm/lib/Target/RISCV/RISCVSubtarget.cpp
index 03397e1e0d89ee..3eae2b9774203f 100644
--- a/llvm/lib/Target/RISCV/RISCVSubtarget.cpp
+++ b/llvm/lib/Target/RISCV/RISCVSubtarget.cpp
@@ -211,4 +211,8 @@ void RISCVSubtarget::overrideSchedPolicy(MachineSchedPolicy
&Policy,
// Spilling is generally expensive on all RISC-V cores, so always enable
// register-pressure tracking. This will increase compile time.
Policy.ShouldTrackPressure = true;
+
+ // Enabling ShouldTrackLaneMasks when vector instructions are supported.
+ // TODO: Add extensions that need register pairs as well?
+ Policy.ShouldTrackLaneMasks = hasVInstructions();
}
diff --git a/llvm/test/CodeGen/RISCV/early-clobber-tied-def-subreg-liveness.ll
b/llvm/test/CodeGen/RISCV/early-clobber-tied-def-subreg-liveness.ll
index 26e86d41176e04..5a38ec36068f93 100644
--- a/llvm/test/CodeGen/RISCV/early-clobber-tied-def-subreg-liveness.ll
+++ b/llvm/test/CodeGen/RISCV/early-clobber-tied-def-subreg-liveness.ll
@@ -24,31 +24,31 @@ define void @_Z3foov() {
; CHECK-NEXT:lui a0, %hi(.L__const._Z3foov.var_49)
; CHECK-NEXT:addi a0, a0, %lo(.L__const._Z3foov.var_49)
; CHECK-NEXT:vsetivli zero, 2, e16, m2, ta, ma
-; CHECK-NEXT:vle16.v v8, (a0)
+; CHECK-NEXT:vle16.v v10, (a0)
; CHECK-NEXT:lui a0, %hi(.L__const._Z3foov.var_48)
; CHECK-NEXT:addi a0, a0, %lo(.L__const._Z3foov.var_48)
-; CHECK-NEXT:vle8.v v10, (a0)
+; CHECK-NEXT:vle8.v v8, (a0)
; CHECK-NEXT:csrr a0, vlenb
; CHECK-NEXT:
[llvm-branch-commits] [compiler-rt] release/19.x: [compiler-rt] [fuzzer] Skip trying to set the thread name on MinGW (#115167) (PR #115287)
https://github.com/tru updated https://github.com/llvm/llvm-project/pull/115287
>From d174e2a5538984bca3d31ac41aff71528bb28747 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Thu, 7 Nov 2024 00:18:57 +0200
Subject: [PATCH] [compiler-rt] [fuzzer] Skip trying to set the thread name on
MinGW (#115167)
Since b4130bee6bfd34d8045f02fc9f951bcb5db9d85c, we check for
_LIBCPP_HAS_THREAD_API_PTHREAD to decide between using
SetThreadDescription or pthread_setname_np for setting the thread name.
c6f3b7bcd0596d30f8dabecdfb9e44f9a07b6e4c changed how libcxx defines
their configuration macros - now they are always defined, but defined to
0 or 1, while they previously were either defined or undefined.
As these libcxx defines used to be defined to an empty string (rather
than expanding to 1) if enabled, we can't easily produce an expression
that works both with older and newer libcxx. Additionally, these defines
are libcxx internal config macros that aren't a detail that isn't
supported and isn't meant to be relied upon.
Simply skip trying to set thread name on MinGW as we can't easily know
which kind of thread native handle we have. Setting the thread name is
only a nice to have, quality of life improvement - things should work
the same even without it.
Additionally, libfuzzer isn't generally usable on MinGW targets yet
(Clang doesn't include it in the getSupportedSanitizers() method for the
MinGW target), so this shouldn't make any difference in practice anyway.
(cherry picked from commit 87f4bc0acad65b1d20160d4160c7778b187125fc)
---
compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
b/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
index 73eea07cf869ff..da3eb3cfb34063 100644
--- a/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
+++ b/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
@@ -239,10 +239,11 @@ size_t PageSize() {
}
void SetThreadName(std::thread &thread, const std::string &name) {
-#if defined(_LIBCPP_HAS_THREAD_API_PTHREAD) ||
\
-defined(_GLIBCXX_GCC_GTHR_POSIX_H)
- (void)pthread_setname_np(thread.native_handle(), name.c_str());
-#else
+#ifndef __MINGW32__
+ // Not setting the thread name in MinGW environments. MinGW C++ standard
+ // libraries can either use native Windows threads or pthreads, so we
+ // don't know with certainty what kind of thread handle we're getting
+ // from thread.native_handle() here.
typedef HRESULT(WINAPI * proc)(HANDLE, PCWSTR);
HMODULE kbase = GetModuleHandleA("KernelBase.dll");
proc ThreadNameProc =
___
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] Fix undefined lld::wasm::link symbol while building clangInterpreter for wasm (PR #115846)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Anutosh Bhat (anutosh491)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/115846.diff
1 Files Affected:
- (modified) clang/lib/Interpreter/CMakeLists.txt (+2)
``diff
diff --git a/clang/lib/Interpreter/CMakeLists.txt
b/clang/lib/Interpreter/CMakeLists.txt
index 6a069659ebb8db..0a2d60757c216d 100644
--- a/clang/lib/Interpreter/CMakeLists.txt
+++ b/clang/lib/Interpreter/CMakeLists.txt
@@ -14,6 +14,7 @@ set(LLVM_LINK_COMPONENTS
if (EMSCRIPTEN AND "lld" IN_LIST LLVM_ENABLE_PROJECTS)
set(WASM_SRC Wasm.cpp)
+ set(WASM_LINK lldWasm)
endif()
add_clang_library(clangInterpreter
@@ -43,6 +44,7 @@ add_clang_library(clangInterpreter
clangParse
clangSema
clangSerialization
+ ${WASM_LINK}
)
if ((MINGW OR CYGWIN) AND BUILD_SHARED_LIBS)
``
https://github.com/llvm/llvm-project/pull/115846
___
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-repl] Fix undefined lld::wasm::link symbol while building clangInterpreter for wasm (PR #115846)
https://github.com/anutosh491 edited https://github.com/llvm/llvm-project/pull/115846 ___ 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] release/19.x: [clang-repl] Fix undefined lld::wasm::link symbol while building clangInterpreter for wasm (#113446) (PR #115848)
github-actions[bot] wrote: ⚠️ We detected that you are using a GitHub private e-mail address to contribute to the repo. Please turn off [Keep my email addresses private](https://github.com/settings/emails) setting in your account. See [LLVM Discourse](https://discourse.llvm.org/t/hidden-emails-on-github-should-we-do-something-about-it) for more information. https://github.com/llvm/llvm-project/pull/115848 ___ 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/19.x: [WebAssembly] Fix rethrow's index calculation (#114693) (PR #115844)
https://github.com/aheejin edited https://github.com/llvm/llvm-project/pull/115844 ___ 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] AMDGPU/GlobalISel: AMDGPURegBankSelect (PR #112863)
@@ -69,3 +72,37 @@ AMDGPU::getBaseWithConstantOffset(MachineRegisterInfo &MRI,
Register Reg,
return std::pair(Reg, 0);
}
+
+IntrinsicLaneMaskAnalyzer::IntrinsicLaneMaskAnalyzer(MachineFunction &MF)
+: MRI(MF.getRegInfo()) {
+ initLaneMaskIntrinsics(MF);
+}
+
+bool IntrinsicLaneMaskAnalyzer::isS32S64LaneMask(Register Reg) const {
+ return S32S64LaneMask.contains(Reg);
+}
+
+void IntrinsicLaneMaskAnalyzer::initLaneMaskIntrinsics(MachineFunction &MF) {
+ for (auto &MBB : MF) {
+for (auto &MI : MBB) {
+ GIntrinsic *GI = dyn_cast(&MI);
+ if (GI && GI->is(Intrinsic::amdgcn_if_break)) {
+S32S64LaneMask.insert(MI.getOperand(3).getReg());
+findLCSSAPhi(MI.getOperand(0).getReg());
+ }
+
+ if (MI.getOpcode() == AMDGPU::SI_IF ||
+ MI.getOpcode() == AMDGPU::SI_ELSE) {
+findLCSSAPhi(MI.getOperand(0).getReg());
+ }
petar-avramovic wrote:
Consequence of what legalizer does, si.if and si.else are inst-selected to
SI_IF and SI_ELSE in AMDGPULegalizerInfo::legalizeIntrinsic, if.break is still
intrinsic for reg bank selection
https://github.com/llvm/llvm-project/pull/112863
___
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-repl] Fix undefined lld::wasm::link symbol while building clangInterpreter for wasm (PR #115846)
anutosh491 wrote: Closing as duplicate of #115848 https://github.com/llvm/llvm-project/pull/115846 ___ 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-repl] Fix undefined lld::wasm::link symbol while building clangInterpreter for wasm (PR #115846)
https://github.com/anutosh491 closed https://github.com/llvm/llvm-project/pull/115846 ___ 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] AMDGPU/GlobalISel: RegBankLegalize rules for load (PR #112882)
https://github.com/petar-avramovic updated
https://github.com/llvm/llvm-project/pull/112882
>From 3854308d10edc1329086faf26542ca469b26c589 Mon Sep 17 00:00:00 2001
From: Petar Avramovic
Date: Wed, 30 Oct 2024 15:37:59 +0100
Subject: [PATCH] AMDGPU/GlobalISel: RegBankLegalize rules for load
Add IDs for bit width that cover multiple LLTs: B32 B64 etc.
"Predicate" wrapper class for bool predicate functions used to
write pretty rules. Predicates can be combined using &&, || and !.
Lowering for splitting and widening loads.
Write rules for loads to not change existing mir tests from old
regbankselect.
---
.../AMDGPU/AMDGPURegBankLegalizeHelper.cpp| 284 +++-
.../AMDGPU/AMDGPURegBankLegalizeHelper.h | 5 +
.../AMDGPU/AMDGPURegBankLegalizeRules.cpp | 309 -
.../AMDGPU/AMDGPURegBankLegalizeRules.h | 65 +++-
.../AMDGPU/GlobalISel/regbankselect-load.mir | 320 +++---
.../GlobalISel/regbankselect-zextload.mir | 9 +-
6 files changed, 927 insertions(+), 65 deletions(-)
diff --git a/llvm/lib/Target/AMDGPU/AMDGPURegBankLegalizeHelper.cpp
b/llvm/lib/Target/AMDGPU/AMDGPURegBankLegalizeHelper.cpp
index 916140e2bbcd68..5c4195cb15fb2c 100644
--- a/llvm/lib/Target/AMDGPU/AMDGPURegBankLegalizeHelper.cpp
+++ b/llvm/lib/Target/AMDGPU/AMDGPURegBankLegalizeHelper.cpp
@@ -38,6 +38,83 @@ void
RegBankLegalizeHelper::findRuleAndApplyMapping(MachineInstr &MI) {
lower(MI, Mapping, WaterfallSgprs);
}
+void RegBankLegalizeHelper::splitLoad(MachineInstr &MI,
+ ArrayRef LLTBreakdown, LLT MergeTy)
{
+ MachineFunction &MF = B.getMF();
+ assert(MI.getNumMemOperands() == 1);
+ MachineMemOperand &BaseMMO = **MI.memoperands_begin();
+ Register Dst = MI.getOperand(0).getReg();
+ const RegisterBank *DstRB = MRI.getRegBankOrNull(Dst);
+ Register Base = MI.getOperand(1).getReg();
+ LLT PtrTy = MRI.getType(Base);
+ const RegisterBank *PtrRB = MRI.getRegBankOrNull(Base);
+ LLT OffsetTy = LLT::scalar(PtrTy.getSizeInBits());
+ SmallVector LoadPartRegs;
+
+ unsigned ByteOffset = 0;
+ for (LLT PartTy : LLTBreakdown) {
+Register BasePlusOffset;
+if (ByteOffset == 0) {
+ BasePlusOffset = Base;
+} else {
+ auto Offset = B.buildConstant({PtrRB, OffsetTy}, ByteOffset);
+ BasePlusOffset = B.buildPtrAdd({PtrRB, PtrTy}, Base, Offset).getReg(0);
+}
+auto *OffsetMMO = MF.getMachineMemOperand(&BaseMMO, ByteOffset, PartTy);
+auto LoadPart = B.buildLoad({DstRB, PartTy}, BasePlusOffset, *OffsetMMO);
+LoadPartRegs.push_back(LoadPart.getReg(0));
+ByteOffset += PartTy.getSizeInBytes();
+ }
+
+ if (!MergeTy.isValid()) {
+// Loads are of same size, concat or merge them together.
+B.buildMergeLikeInstr(Dst, LoadPartRegs);
+ } else {
+// Loads are not all of same size, need to unmerge them to smaller pieces
+// of MergeTy type, then merge pieces to Dst.
+SmallVector MergeTyParts;
+for (Register Reg : LoadPartRegs) {
+ if (MRI.getType(Reg) == MergeTy) {
+MergeTyParts.push_back(Reg);
+ } else {
+auto Unmerge = B.buildUnmerge({DstRB, MergeTy}, Reg);
+for (unsigned i = 0; i < Unmerge->getNumOperands() - 1; ++i)
+ MergeTyParts.push_back(Unmerge.getReg(i));
+ }
+}
+B.buildMergeLikeInstr(Dst, MergeTyParts);
+ }
+ MI.eraseFromParent();
+}
+
+void RegBankLegalizeHelper::widenLoad(MachineInstr &MI, LLT WideTy,
+ LLT MergeTy) {
+ MachineFunction &MF = B.getMF();
+ assert(MI.getNumMemOperands() == 1);
+ MachineMemOperand &BaseMMO = **MI.memoperands_begin();
+ Register Dst = MI.getOperand(0).getReg();
+ const RegisterBank *DstRB = MRI.getRegBankOrNull(Dst);
+ Register Base = MI.getOperand(1).getReg();
+
+ MachineMemOperand *WideMMO = MF.getMachineMemOperand(&BaseMMO, 0, WideTy);
+ auto WideLoad = B.buildLoad({DstRB, WideTy}, Base, *WideMMO);
+
+ if (WideTy.isScalar()) {
+B.buildTrunc(Dst, WideLoad);
+ } else {
+SmallVector MergeTyParts;
+auto Unmerge = B.buildUnmerge({DstRB, MergeTy}, WideLoad);
+
+LLT DstTy = MRI.getType(Dst);
+unsigned NumElts = DstTy.getSizeInBits() / MergeTy.getSizeInBits();
+for (unsigned i = 0; i < NumElts; ++i) {
+ MergeTyParts.push_back(Unmerge.getReg(i));
+}
+B.buildMergeLikeInstr(Dst, MergeTyParts);
+ }
+ MI.eraseFromParent();
+}
+
void RegBankLegalizeHelper::lower(MachineInstr &MI,
const RegBankLLTMapping &Mapping,
SmallSet &WaterfallSgprs) {
@@ -116,6 +193,50 @@ void RegBankLegalizeHelper::lower(MachineInstr &MI,
MI.eraseFromParent();
break;
}
+ case SplitLoad: {
+LLT DstTy = MRI.getType(MI.getOperand(0).getReg());
+unsigned Size = DstTy.getSizeInBits();
+// Even split to 128-bit loads
+if (Size > 128) {
+ LLT B128;
+ if (DstTy.isVector()) {
+LLT EltTy = DstTy.getElementType();
+B128 = LLT:
[llvm-branch-commits] [llvm] MachineUniformityAnalysis: Improve isConstantOrUndefValuePhi (PR #112866)
https://github.com/petar-avramovic updated
https://github.com/llvm/llvm-project/pull/112866
>From c59ad6e821a49e48df70edff1fdb044eb0083b1c Mon Sep 17 00:00:00 2001
From: Petar Avramovic
Date: Thu, 31 Oct 2024 14:10:57 +0100
Subject: [PATCH] MachineUniformityAnalysis: Improve isConstantOrUndefValuePhi
Change existing code for G_PHI to match what LLVM-IR version is doing
via PHINode::hasConstantOrUndefValue. This is not safe for regular PHI
since it may appear with an undef operand and getVRegDef can fail.
Most notably this improves number of values that can be allocated
to sgpr register bank in AMDGPURegBankSelect.
Common case here are phis that appear in structurize-cfg lowering
for cycles with multiple exits:
Undef incoming value is coming from block that reached cycle exit
condition, if other incoming is uniform keep the phi uniform despite
the fact it is joining values from pair of blocks that are entered
via divergent condition branch.
---
llvm/lib/CodeGen/MachineSSAContext.cpp| 27 +-
.../AMDGPU/MIR/hidden-diverge-gmir.mir| 28 +++
.../AMDGPU/MIR/hidden-loop-diverge.mir| 4 +-
.../AMDGPU/MIR/uses-value-from-cycle.mir | 8 +-
.../GlobalISel/divergence-structurizer.mir| 80 --
.../regbankselect-mui-regbanklegalize.mir | 69 ---
.../regbankselect-mui-regbankselect.mir | 18 ++--
.../AMDGPU/GlobalISel/regbankselect-mui.ll| 84 ++-
.../AMDGPU/GlobalISel/regbankselect-mui.mir | 51 ++-
9 files changed, 191 insertions(+), 178 deletions(-)
diff --git a/llvm/lib/CodeGen/MachineSSAContext.cpp
b/llvm/lib/CodeGen/MachineSSAContext.cpp
index e384187b6e8593..8e13c0916dd9e1 100644
--- a/llvm/lib/CodeGen/MachineSSAContext.cpp
+++ b/llvm/lib/CodeGen/MachineSSAContext.cpp
@@ -54,9 +54,34 @@ const MachineBasicBlock
*MachineSSAContext::getDefBlock(Register value) const {
return F->getRegInfo().getVRegDef(value)->getParent();
}
+static bool isUndef(const MachineInstr &MI) {
+ return MI.getOpcode() == TargetOpcode::G_IMPLICIT_DEF ||
+ MI.getOpcode() == TargetOpcode::IMPLICIT_DEF;
+}
+
+/// MachineInstr equivalent of PHINode::hasConstantOrUndefValue() for G_PHI.
template <>
bool MachineSSAContext::isConstantOrUndefValuePhi(const MachineInstr &Phi) {
- return Phi.isConstantValuePHI();
+ if (!Phi.isPHI())
+return false;
+
+ // In later passes PHI may appear with an undef operand, getVRegDef can fail.
+ if (Phi.getOpcode() == TargetOpcode::PHI)
+return Phi.isConstantValuePHI();
+
+ // For G_PHI we do equivalent of PHINode::hasConstantOrUndefValue().
+ const MachineRegisterInfo &MRI = Phi.getMF()->getRegInfo();
+ Register This = Phi.getOperand(0).getReg();
+ Register ConstantValue;
+ for (unsigned i = 1, e = Phi.getNumOperands(); i < e; i += 2) {
+Register Incoming = Phi.getOperand(i).getReg();
+if (Incoming != This && !isUndef(*MRI.getVRegDef(Incoming))) {
+ if (ConstantValue && ConstantValue != Incoming)
+return false;
+ ConstantValue = Incoming;
+}
+ }
+ return true;
}
template <>
diff --git
a/llvm/test/Analysis/UniformityAnalysis/AMDGPU/MIR/hidden-diverge-gmir.mir
b/llvm/test/Analysis/UniformityAnalysis/AMDGPU/MIR/hidden-diverge-gmir.mir
index ce00edf3363f77..9694a340b5e906 100644
--- a/llvm/test/Analysis/UniformityAnalysis/AMDGPU/MIR/hidden-diverge-gmir.mir
+++ b/llvm/test/Analysis/UniformityAnalysis/AMDGPU/MIR/hidden-diverge-gmir.mir
@@ -1,24 +1,24 @@
# RUN: llc -mtriple=amdgcn-- -run-pass=print-machine-uniformity -o - %s 2>&1 |
FileCheck %s
# CHECK-LABEL: MachineUniformityInfo for function: hidden_diverge
# CHECK-LABEL: BLOCK bb.0
-# CHECK: DIVERGENT: %{{[0-9]*}}: %{{[0-9]*}}:_(s32) = G_INTRINSIC
intrinsic(@llvm.amdgcn.workitem.id.x)
-# CHECK: DIVERGENT: %{{[0-9]*}}: %{{[0-9]*}}:_(s1) = G_ICMP intpred(slt)
-# CHECK: DIVERGENT: %{{[0-9]*}}: %{{[0-9]*}}:_(s1) = G_XOR %{{[0-9]*}}:_,
%{{[0-9]*}}:_
-# CHECK: DIVERGENT: %{{[0-9]*}}: %{{[0-9]*}}:_(s1), %{{[0-9]*}}:_(s64) =
G_INTRINSIC_W_SIDE_EFFECTS intrinsic(@llvm.amdgcn.if)
-# CHECK: DIVERGENT: %{{[0-9]*}}: %{{[0-9]*}}:_(s1), %{{[0-9]*}}:_(s64) =
G_INTRINSIC_W_SIDE_EFFECTS intrinsic(@llvm.amdgcn.if)
-# CHECK: DIVERGENT: G_BRCOND %{{[0-9]*}}:_(s1), %bb.1
-# CHECK: DIVERGENT: G_BR %bb.2
+# CHECK: DIVERGENT: %{{[0-9]*}}: %{{[0-9]*}}:_(s32) = G_INTRINSIC
intrinsic(@llvm.amdgcn.workitem.id.x)
+# CHECK: DIVERGENT: %{{[0-9]*}}: %{{[0-9]*}}:_(s1) = G_ICMP intpred(slt)
+# CHECK: DIVERGENT: %{{[0-9]*}}: %{{[0-9]*}}:_(s1) = G_XOR %{{[0-9]*}}:_,
%{{[0-9]*}}:_
+# CHECK: DIVERGENT: %{{[0-9]*}}: %{{[0-9]*}}:_(s1), %{{[0-9]*}}:_(s64) =
G_INTRINSIC_W_SIDE_EFFECTS intrinsic(@llvm.amdgcn.if)
+# CHECK: DIVERGENT: %{{[0-9]*}}: %{{[0-9]*}}:_(s1), %{{[0-9]*}}:_(s64) =
G_INTRINSIC_W_SIDE_EFFECTS intrinsic(@llvm.amdgcn.if)
+# CHECK: DIVERGENT: G_BRCOND %{{[0-9]*}}:_(s1), %bb.1
+# CHECK: DIVERGENT: G_BR %bb.2
# CHECK-LABEL: BLOCK bb.1
# CHECK-LABEL: BLOCK bb.2
-# CHECK: D
[llvm-branch-commits] [mlir] [mlir][Transforms] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
@@ -1390,8 +1412,9 @@ void
ConversionPatternRewriterImpl::notifyOpReplaced(Operation *op,
isUnresolvedMaterialization = true;
// Create mappings for each of the new result values.
- for (auto [newValue, result] : llvm::zip(newValues, op->getResults())) {
-if (!newValue) {
+ for (auto [n, result] : llvm::zip(newValues, op->getResults())) {
zero9178 wrote:
```suggestion
for (auto [n, result] : llvm::zip_equal(newValues, op->getResults())) {
```
https://github.com/llvm/llvm-project/pull/115816
___
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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
https://github.com/zero9178 edited https://github.com/llvm/llvm-project/pull/115816 ___ 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/19.x: [SLP]Check that operand of abs does not overflow before making it part of minbitwidth transformation (PR #113146)
@@ -15440,9 +15440,25 @@ bool BoUpSLP::collectValuesToDemote(
MaskedValueIsZero(I->getOperand(1), Mask, SimplifyQuery(*DL)));
});
};
+auto AbsChecker = [&](unsigned BitWidth, unsigned OrigBitWidth) {
+ assert(BitWidth <= OrigBitWidth && "Unexpected bitwidths!");
+ return all_of(E.Scalars, [&](Value *V) {
+auto *I = cast(V);
+unsigned SignBits = OrigBitWidth - BitWidth;
+APInt Mask = APInt::getBitsSetFrom(OrigBitWidth, BitWidth - 1);
+unsigned Op0SignBits =
+ComputeNumSignBits(I->getOperand(0), *DL, 0, AC, nullptr, DT);
+return SignBits <= Op0SignBits &&
+ ((SignBits != Op0SignBits &&
+ !isKnownNonNegative(I->getOperand(0), SimplifyQuery(*DL))) ||
alexey-bataev wrote:
!isKnownNonNegative is correct here
https://github.com/llvm/llvm-project/pull/113146
___
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] [CGData] Refactor Global Merge Functions (PR #115750)
https://github.com/kyulee-com edited https://github.com/llvm/llvm-project/pull/115750 ___ 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] fe90afe - Revert "[analyzer][NFC] Make RegionStore dumps deterministic (#115615)"
Author: Balazs Benics
Date: 2024-11-12T16:22:07+01:00
New Revision: fe90afe8b22a8c89dc418451c200be4a90229e34
URL:
https://github.com/llvm/llvm-project/commit/fe90afe8b22a8c89dc418451c200be4a90229e34
DIFF:
https://github.com/llvm/llvm-project/commit/fe90afe8b22a8c89dc418451c200be4a90229e34.diff
LOG: Revert "[analyzer][NFC] Make RegionStore dumps deterministic (#115615)"
This reverts commit e05d91b30e1fe2ed9a90911de2b959395d0318c8.
Added:
Modified:
clang/lib/StaticAnalyzer/Core/RegionStore.cpp
Removed:
diff --git a/clang/lib/StaticAnalyzer/Core/RegionStore.cpp
b/clang/lib/StaticAnalyzer/Core/RegionStore.cpp
index 085f0ef9a5fb96..674099dd7e1f0f 100644
--- a/clang/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ b/clang/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -67,8 +67,8 @@ class BindingKey {
isa(r)) &&
"Not a base");
}
-
public:
+
bool isDirect() const { return P.getInt() & Direct; }
bool hasSymbolicOffset() const { return P.getInt() & Symbolic; }
@@ -232,75 +232,27 @@ class RegionBindingsRef : public
llvm::ImmutableMapRef StringifyCache;
-auto ToString = [&StringifyCache](const MemRegion *R) {
- auto [Place, Inserted] = StringifyCache.try_emplace(R);
- if (!Inserted)
-return Place->second;
- std::string Res;
- raw_string_ostream OS(Res);
- OS << R;
- Place->second = Res;
- return Res;
-};
-
-using Cluster =
-std::pair>;
-using Binding = std::pair;
-
-const auto ClusterSortKey = [&ToString](const Cluster *C) {
- const MemRegion *Key = C->first;
- return std::tuple{isa(Key), ToString(Key)};
-};
-
-const auto MemSpaceBeforeRegionName = [&ClusterSortKey](const Cluster *L,
-const Cluster *R) {
- return ClusterSortKey(L) < ClusterSortKey(R);
-};
-
-const auto BindingSortKey = [&ToString](const Binding *BPtr) {
- const BindingKey &Key = BPtr->first;
- return std::tuple{Key.isDirect(), !Key.hasSymbolicOffset(),
-ToString(Key.getRegion()), Key.getOffset()};
-};
-
-const auto DefaultBindingBeforeDirectBindings =
-[&BindingSortKey](const Binding *LPtr, const Binding *RPtr) {
- return BindingSortKey(LPtr) < BindingSortKey(RPtr);
-};
-
-const auto AddrOf = [](const auto &Item) { return &Item; };
-
-std::vector SortedClusters;
-SortedClusters.reserve(std::distance(begin(), end()));
-append_range(SortedClusters, map_range(*this, AddrOf));
-llvm::sort(SortedClusters, MemSpaceBeforeRegionName);
-
-for (auto [Idx, C] : llvm::enumerate(SortedClusters)) {
- const auto &[BaseRegion, Bindings] = *C;
+for (iterator I = begin(), E = end(); I != E; ++I) {
+ // TODO: We might need a .printJson for I.getKey() as well.
Indent(Out, Space, IsDot)
- << "{ \"cluster\": \"" << BaseRegion << "\", \"pointer\": \""
- << (const void *)BaseRegion << "\", \"items\": [" << NL;
-
- std::vector SortedBindings;
- SortedBindings.reserve(std::distance(Bindings.begin(), Bindings.end()));
- append_range(SortedBindings, map_range(Bindings, AddrOf));
- llvm::sort(SortedBindings, DefaultBindingBeforeDirectBindings);
+ << "{ \"cluster\": \"" << I.getKey() << "\", \"pointer\": \""
+ << (const void *)I.getKey() << "\", \"items\": [" << NL;
++Space;
- for (auto [Idx, B] : llvm::enumerate(SortedBindings)) {
-const auto &[Key, Value] = *B;
-Indent(Out, Space, IsDot) << "{ " << Key << ", \"value\": ";
-Value.printJson(Out, /*AddQuotes=*/true);
+ const ClusterBindings &CB = I.getData();
+ for (ClusterBindings::iterator CI = CB.begin(), CE = CB.end(); CI != CE;
+ ++CI) {
+Indent(Out, Space, IsDot) << "{ " << CI.getKey() << ", \"value\": ";
+CI.getData().printJson(Out, /*AddQuotes=*/true);
Out << " }";
-if (Idx != SortedBindings.size() - 1)
+if (std::next(CI) != CE)
Out << ',';
Out << NL;
}
+
--Space;
Indent(Out, Space, IsDot) << "]}";
- if (Idx != SortedClusters.size() - 1)
+ if (std::next(I) != E)
Out << ',';
Out << NL;
}
___
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] release/19.x: [compiler-rt] Stop using x86 builtin on AArch64 with GCC (#93890) (PR #115006)
tru wrote: Looking at the patch it looks sane to me. Is there any risk that this breaks something if we merge it as is now? https://github.com/llvm/llvm-project/pull/115006 ___ 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] release/19.x: [compiler-rt] [fuzzer] Skip trying to set the thread name on MinGW (#115167) (PR #115287)
https://github.com/tru closed https://github.com/llvm/llvm-project/pull/115287 ___ 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] release/19.x: [compiler-rt] [fuzzer] Skip trying to set the thread name on MinGW (#115167) (PR #115287)
github-actions[bot] wrote: @mstorsjo (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/115287 ___ 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] [RISCV] Enable ShouldTrackLaneMasks when having vector instructions (PR #115843)
https://github.com/wangpc-pp edited https://github.com/llvm/llvm-project/pull/115843 ___ 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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
@@ -618,21 +618,27 @@ class SparseCallConverter : public
OpConversionPattern {
assert(!sparseFlat.empty());
if (sparseFlat.size() > 1) {
auto flatSize = sparseFlat.size();
-ValueRange fields(iterator_range(
-newCall.result_begin() + retOffset,
-newCall.result_begin() + retOffset + flatSize));
-castedRet.push_back(genTuple(rewriter, loc, retType, fields));
+packedResultVals.push_back(SmallVector());
+llvm::append_range(packedResultVals.back(),
+ iterator_range(
+ newCall.result_begin() + retOffset,
+ newCall.result_begin() + retOffset + flatSize));
zero9178 wrote:
```suggestion
newCall.getResults().slice(retOffset, flatSize));
```
https://github.com/llvm/llvm-project/pull/115816
___
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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
@@ -618,21 +618,27 @@ class SparseCallConverter : public
OpConversionPattern {
assert(!sparseFlat.empty());
if (sparseFlat.size() > 1) {
auto flatSize = sparseFlat.size();
-ValueRange fields(iterator_range(
-newCall.result_begin() + retOffset,
-newCall.result_begin() + retOffset + flatSize));
-castedRet.push_back(genTuple(rewriter, loc, retType, fields));
+packedResultVals.push_back(SmallVector());
+llvm::append_range(packedResultVals.back(),
+ iterator_range(
+ newCall.result_begin() + retOffset,
+ newCall.result_begin() + retOffset + flatSize));
retOffset += flatSize;
} else {
// If this is an 1:1 conversion, no need for casting.
-castedRet.push_back(newCall.getResult(retOffset));
+packedResultVals.push_back(SmallVector());
+packedResultVals.back().push_back(newCall.getResult(retOffset));
retOffset++;
}
sparseFlat.clear();
}
-assert(castedRet.size() == op.getNumResults());
-rewriter.replaceOp(op, castedRet);
+assert(packedResultVals.size() == op.getNumResults());
+SmallVector ranges;
+ranges.reserve(packedResultVals.size());
+for (const SmallVector &vec : packedResultVals)
+ ranges.push_back(ValueRange(vec));
+rewriter.replaceOpWithMultiple(op, ranges);
zero9178 wrote:
```suggestion
rewriter.replaceOpWithMultiple(op,
llvm::to_vector_of(packedResultVals));
```
IIRC this should work, otherwise I'd use `emplace_back` instead of `push_back`
at the very least
https://github.com/llvm/llvm-project/pull/115816
___
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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
@@ -1497,15 +1530,33 @@ void ConversionPatternRewriter::replaceOp(Operation
*op, ValueRange newValues) {
impl->logger.startLine()
<< "** Replace : '" << op->getName() << "'(" << op << ")\n";
});
- impl->notifyOpReplaced(op, newValues);
+ SmallVector newVals(newValues.size(), {});
+ for (auto it : llvm::enumerate(newValues))
+if (Value val = it.value())
+ newVals[it.index()].push_back(val);
zero9178 wrote:
```suggestion
for (auto [index, val] : llvm::enumerate(newValues))
if (val)
newVals[index].push_back(val);
```
Ditto below
https://github.com/llvm/llvm-project/pull/115816
___
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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
@@ -795,12 +795,32 @@ class ConversionPatternRewriter final : public
PatternRewriter {
/// patterns even if a failure is encountered during the rewrite step.
bool canRecoverFromRewriteFailure() const override { return true; }
- /// PatternRewriter hook for replacing an operation.
+ /// Replace the given operation with the new values. The number of op results
+ /// and replacement values must match. The types may differ: the dialect
+ /// conversion driver will reconcile any surviving type mismatches at the end
+ /// of the conversion process with source materializations. The given
+ /// operation is erased.
void replaceOp(Operation *op, ValueRange newValues) override;
- /// PatternRewriter hook for replacing an operation.
+ /// Replace the given operation with the results of the new op. The number of
+ /// op results must match. The types may differ: the dialect conversion
+ /// driver will reconcile any surviving type mismatches at the end of the
+ /// conversion process with source materializations. The original operation
+ /// is erased.
void replaceOp(Operation *op, Operation *newOp) override;
+ /// Replace the given operation with the new value range. The number of op
+ /// results and value ranges must match. If an original SSA value is replaced
+ /// by multiple SSA values (i.e., value range has more than 1 element), the
zero9178 wrote:
```suggestion
/// by multiple SSA values (i.e., a value range has more than 1 element), the
```
https://github.com/llvm/llvm-project/pull/115816
___
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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
zero9178 wrote: Should the changes here be part of the other PR? https://github.com/llvm/llvm-project/pull/115816 ___ 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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
@@ -1417,12 +1441,21 @@ void
ConversionPatternRewriterImpl::notifyOpReplaced(Operation *op,
}
// Remap result to replacement value.
-if (newValue)
- mapping.map(result, newValue);
+if (!repl.empty()) {
+ if (repl.size() == 1) {
+// Single replacement value: replace directly.
+mapping.map(result, repl.front());
+ } else {
+// Multiple replacement values: insert N:1 materialization.
+insertNTo1Materialization(OpBuilder::InsertPoint::after(repl,
&domInfo),
+ result.getLoc(),
+ /*replacements=*/repl,
/*outputValue=*/result,
+ currentTypeConverter);
+ }
+}
zero9178 wrote:
```suggestion
if (repl.empty())
continue;
if (repl.size() == 1) {
// Single replacement value: replace directly.
mapping.map(result, repl.front());
} else {
// Multiple replacement values: insert N:1 materialization.
insertNTo1Materialization(OpBuilder::InsertPoint::after(repl, &domInfo),
result.getLoc(),
/*replacements=*/repl, /*outputValue=*/result,
currentTypeConverter);
}
```
https://github.com/llvm/llvm-project/pull/115816
___
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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
@@ -618,21 +618,27 @@ class SparseCallConverter : public
OpConversionPattern {
assert(!sparseFlat.empty());
if (sparseFlat.size() > 1) {
auto flatSize = sparseFlat.size();
-ValueRange fields(iterator_range(
-newCall.result_begin() + retOffset,
-newCall.result_begin() + retOffset + flatSize));
-castedRet.push_back(genTuple(rewriter, loc, retType, fields));
+packedResultVals.push_back(SmallVector());
+llvm::append_range(packedResultVals.back(),
+ iterator_range(
+ newCall.result_begin() + retOffset,
+ newCall.result_begin() + retOffset + flatSize));
retOffset += flatSize;
} else {
// If this is an 1:1 conversion, no need for casting.
-castedRet.push_back(newCall.getResult(retOffset));
+packedResultVals.push_back(SmallVector());
zero9178 wrote:
```suggestion
packedResultVals.emplace_back();
```
https://github.com/llvm/llvm-project/pull/115816
___
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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
@@ -1497,15 +1530,33 @@ void ConversionPatternRewriter::replaceOp(Operation
*op, ValueRange newValues) {
impl->logger.startLine()
<< "** Replace : '" << op->getName() << "'(" << op << ")\n";
});
- impl->notifyOpReplaced(op, newValues);
+ SmallVector newVals(newValues.size(), {});
zero9178 wrote:
```suggestion
SmallVector newVals(newValues.size());
```
https://github.com/llvm/llvm-project/pull/115816
___
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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
https://github.com/zero9178 commented: Looks mostly good to me besides some code nits :slightly_smiling_face: The only very high level conern I have is the use and need of `InsertionPoint::after`. As I understand, this is a not-yet-implemented optimization for the future for the purpose of reusing materializations by calculating a better insertion point where it may dominate more operations which might need exactly that materialization after pattern application as well. Is the current complexity of calculating the insertion point (and potentially calculatin the post-dom tree, a `O(n log n)` operation) worth the gain of the optimization? I am thinking that the better insertion point insertion logic should probably be post-poned until we can measure its effectivness (and avoid the risk of a premature optimization) and have something simpler and working that does not worsen the status-quo for now instead. https://github.com/llvm/llvm-project/pull/115816 ___ 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] Dialect Conversion: Add `replaceOpWithMultiple` (PR #115816)
@@ -795,12 +795,32 @@ class ConversionPatternRewriter final : public
PatternRewriter {
/// patterns even if a failure is encountered during the rewrite step.
bool canRecoverFromRewriteFailure() const override { return true; }
- /// PatternRewriter hook for replacing an operation.
+ /// Replace the given operation with the new values. The number of op results
+ /// and replacement values must match. The types may differ: the dialect
+ /// conversion driver will reconcile any surviving type mismatches at the end
+ /// of the conversion process with source materializations. The given
+ /// operation is erased.
void replaceOp(Operation *op, ValueRange newValues) override;
- /// PatternRewriter hook for replacing an operation.
+ /// Replace the given operation with the results of the new op. The number of
+ /// op results must match. The types may differ: the dialect conversion
+ /// driver will reconcile any surviving type mismatches at the end of the
+ /// conversion process with source materializations. The original operation
+ /// is erased.
void replaceOp(Operation *op, Operation *newOp) override;
+ /// Replace the given operation with the new value range. The number of op
zero9178 wrote:
```suggestion
/// Replace the given operation with the new value ranges. The number of op
```
https://github.com/llvm/llvm-project/pull/115816
___
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] [RISCV] Set DisableLatencyHeuristic to true (PR #115858)
https://github.com/wangpc-pp created https://github.com/llvm/llvm-project/pull/115858 This helps reduce register pressure for some cases. ___ 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] [RISCV] Set DisableLatencyHeuristic to true (PR #115858)
llvmbot wrote: @llvm/pr-subscribers-backend-risc-v Author: Pengcheng Wang (wangpc-pp) Changes This helps reduce register pressure for some cases. --- Patch is 7.18 MiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/115858.diff 465 Files Affected: - (modified) llvm/lib/Target/RISCV/RISCVSubtarget.cpp (+7) - (modified) llvm/test/CodeGen/RISCV/GlobalISel/alu-roundtrip.ll (+2-2) - (modified) llvm/test/CodeGen/RISCV/GlobalISel/bitmanip.ll (+68-68) - (modified) llvm/test/CodeGen/RISCV/GlobalISel/constbarrier-rv32.ll (+9-9) - (modified) llvm/test/CodeGen/RISCV/GlobalISel/constbarrier-rv64.ll (+1-1) - (modified) llvm/test/CodeGen/RISCV/GlobalISel/iabs.ll (+2-2) - (modified) llvm/test/CodeGen/RISCV/GlobalISel/rv32zbb-zbkb.ll (+1-1) - (modified) llvm/test/CodeGen/RISCV/GlobalISel/rv32zbb.ll (+181-180) - (modified) llvm/test/CodeGen/RISCV/GlobalISel/rv32zbkb.ll (+2-2) - (modified) llvm/test/CodeGen/RISCV/GlobalISel/rv64zbb.ll (+261-261) - (modified) llvm/test/CodeGen/RISCV/GlobalISel/rv64zbkb.ll (+6-6) - (modified) llvm/test/CodeGen/RISCV/GlobalISel/vararg.ll (+12-12) - (modified) llvm/test/CodeGen/RISCV/abds-neg.ll (+262-262) - (modified) llvm/test/CodeGen/RISCV/abds.ll (+254-254) - (modified) llvm/test/CodeGen/RISCV/abdu-neg.ll (+358-358) - (modified) llvm/test/CodeGen/RISCV/abdu.ll (+244-244) - (modified) llvm/test/CodeGen/RISCV/add-before-shl.ll (+18-18) - (modified) llvm/test/CodeGen/RISCV/add-imm.ll (+12-12) - (modified) llvm/test/CodeGen/RISCV/addcarry.ll (+11-11) - (modified) llvm/test/CodeGen/RISCV/addimm-mulimm.ll (+63-63) - (modified) llvm/test/CodeGen/RISCV/alu16.ll (+2-2) - (modified) llvm/test/CodeGen/RISCV/alu8.ll (+2-2) - (modified) llvm/test/CodeGen/RISCV/and.ll (+1-1) - (modified) llvm/test/CodeGen/RISCV/atomic-cmpxchg-branch-on-result.ll (+16-16) - (modified) llvm/test/CodeGen/RISCV/atomic-cmpxchg.ll (+192-192) - (modified) llvm/test/CodeGen/RISCV/atomic-rmw.ll (+1343-1343) - (modified) llvm/test/CodeGen/RISCV/atomic-signext.ll (+122-122) - (modified) llvm/test/CodeGen/RISCV/atomicrmw-cond-sub-clamp.ll (+36-36) - (modified) llvm/test/CodeGen/RISCV/atomicrmw-uinc-udec-wrap.ll (+12-12) - (modified) llvm/test/CodeGen/RISCV/avgceils.ll (+16-16) - (modified) llvm/test/CodeGen/RISCV/avgceilu.ll (+10-10) - (modified) llvm/test/CodeGen/RISCV/avgfloors.ll (+10-10) - (modified) llvm/test/CodeGen/RISCV/avgflooru.ll (+20-20) - (modified) llvm/test/CodeGen/RISCV/bf16-promote.ll (+2-2) - (modified) llvm/test/CodeGen/RISCV/bfloat-arith.ll (+57-57) - (modified) llvm/test/CodeGen/RISCV/bfloat-br-fcmp.ll (+8-8) - (modified) llvm/test/CodeGen/RISCV/bfloat-convert.ll (+91-91) - (modified) llvm/test/CodeGen/RISCV/bfloat-fcmp.ll (+4-4) - (modified) llvm/test/CodeGen/RISCV/bfloat-mem.ll (+2-2) - (modified) llvm/test/CodeGen/RISCV/bfloat.ll (+12-12) - (modified) llvm/test/CodeGen/RISCV/bitextract-mac.ll (+6-6) - (modified) llvm/test/CodeGen/RISCV/branch-relaxation.ll (+95-95) - (modified) llvm/test/CodeGen/RISCV/bswap-bitreverse.ll (+528-524) - (modified) llvm/test/CodeGen/RISCV/calling-conv-half.ll (+16-16) - (modified) llvm/test/CodeGen/RISCV/calling-conv-ilp32-ilp32f-common.ll (+48-52) - (modified) llvm/test/CodeGen/RISCV/calling-conv-ilp32-ilp32f-ilp32d-common.ll (+126-126) - (modified) llvm/test/CodeGen/RISCV/calling-conv-ilp32d.ll (+34-34) - (modified) llvm/test/CodeGen/RISCV/calling-conv-ilp32e.ll (+308-308) - (modified) llvm/test/CodeGen/RISCV/calling-conv-ilp32f-ilp32d-common.ll (+24-24) - (modified) llvm/test/CodeGen/RISCV/calling-conv-lp64-lp64f-lp64d-common.ll (+58-58) - (modified) llvm/test/CodeGen/RISCV/cmov-branch-opt.ll (+4-4) - (modified) llvm/test/CodeGen/RISCV/compress.ll (+1-1) - (modified) llvm/test/CodeGen/RISCV/condbinops.ll (+40-40) - (modified) llvm/test/CodeGen/RISCV/condops.ll (+450-424) - (modified) llvm/test/CodeGen/RISCV/copysign-casts.ll (+48-48) - (modified) llvm/test/CodeGen/RISCV/ctlz-cttz-ctpop.ll (+583-583) - (modified) llvm/test/CodeGen/RISCV/ctz_zero_return_test.ll (+31-31) - (modified) llvm/test/CodeGen/RISCV/div-by-constant.ll (+31-31) - (modified) llvm/test/CodeGen/RISCV/div-pow2.ll (+32-32) - (modified) llvm/test/CodeGen/RISCV/div.ll (+28-28) - (modified) llvm/test/CodeGen/RISCV/double-arith.ll (+4-4) - (modified) llvm/test/CodeGen/RISCV/double-bitmanip-dagcombines.ll (+1-1) - (modified) llvm/test/CodeGen/RISCV/double-calling-conv.ll (+32-32) - (modified) llvm/test/CodeGen/RISCV/double-convert.ll (+43-43) - (modified) llvm/test/CodeGen/RISCV/double-imm.ll (+1-1) - (modified) llvm/test/CodeGen/RISCV/double-intrinsics.ll (+3-3) - (modified) llvm/test/CodeGen/RISCV/double-previous-failure.ll (+1-1) - (modified) llvm/test/CodeGen/RISCV/double-round-conv-sat.ll (+216-216) - (modified) llvm/test/CodeGen/RISCV/double_reduct.ll (+15-15) - (modified) llvm/test/CodeGen/RISCV/early-clobber-tied-def-subreg-liveness.ll (+2-2) - (modified) llvm/test/CodeGen/RISCV/f
[llvm-branch-commits] [RISCV] Set DisableLatencyHeuristic to true (PR #115858)
https://github.com/wangpc-pp edited https://github.com/llvm/llvm-project/pull/115858 ___ 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] release/19.x: [compiler-rt] Stop using x86 builtin on AArch64 with GCC (#93890) (PR #115006)
statham-arm wrote: Despite the force-push, I think the current patch looks the same as the one I clicked approve on (maybe it was just rebased?). I can't see a problem – it's the same patch that hasn't been causing trouble on `main`. https://github.com/llvm/llvm-project/pull/115006 ___ 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/19.x: [SLP]Check that operand of abs does not overflow before making it part of minbitwidth transformation (PR #113146)
@@ -15440,9 +15440,25 @@ bool BoUpSLP::collectValuesToDemote(
MaskedValueIsZero(I->getOperand(1), Mask, SimplifyQuery(*DL)));
});
};
+auto AbsChecker = [&](unsigned BitWidth, unsigned OrigBitWidth) {
+ assert(BitWidth <= OrigBitWidth && "Unexpected bitwidths!");
+ return all_of(E.Scalars, [&](Value *V) {
+auto *I = cast(V);
+unsigned SignBits = OrigBitWidth - BitWidth;
+APInt Mask = APInt::getBitsSetFrom(OrigBitWidth, BitWidth - 1);
+unsigned Op0SignBits =
+ComputeNumSignBits(I->getOperand(0), *DL, 0, AC, nullptr, DT);
+return SignBits <= Op0SignBits &&
+ ((SignBits != Op0SignBits &&
+ !isKnownNonNegative(I->getOperand(0), SimplifyQuery(*DL))) ||
nikic wrote:
Should this then check isKnownNegative rather than !isKnownNonNegative? They're
not the same. I'm still confused by this code.
https://github.com/llvm/llvm-project/pull/113146
___
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] release/19.x: [compiler-rt] Stop using x86 builtin on AArch64 with GCC (#93890) (PR #115006)
tru wrote: The force push was just a rebase to get it on the latest code. https://github.com/llvm/llvm-project/pull/115006 ___ 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] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
@@ -0,0 +1,198 @@ + + +# Fortran Runtime (flang-rt) + +Flang-rt is the runtime library for code emitted by the Flang compiler +(https://flang.llvm.org). + + +## Getting Started + +There are two build modes for the flang-rt. The bootstrap build, also +called the in-tree build, and the runtime-only build, also called the +out-of-tree build. +Not to be confused with the terms +[in-source and out-of-source](https://cmake.org/cmake/help/latest/manual/cmake.1.html#introduction-to-cmake-buildsystems) +builds as defined by CMake. In an in-source build, the source directory and the +build directory are identical, whereas with an out-of-source build the +build artifacts are stored somewhere else, possibly in a subdirectory of the +source directory. LLVM does not support in-source builds. + + +### Requirements + +Requirements: + * [Same as LLVM](https://llvm.org/docs/GettingStarted.html#requirements). + + +### Bootstrap/In-Tree Build + +The bootstrap build will first build Clang and Flang, then use these compilers +to compile flang-rt. CMake will create a secondary build tree in +configured with these just-built compilers. The secondary build will reuse the +same build options (Flags, Debug/Release, ...) as the primary build. It will +also ensure that once built, flang-rt is found by Flang from either +the build- or install-prefix. To enable, add `flang-rt` to +`LLVM_ENABLE_RUNTIMES`: + +```bash +cmake -S /llvm\ + -DNinja \ + -DLLVM_ENABLE_PROJECTS=flang \ + -DLLVM_ENABLE_RUNTIMES=flang-rt \ + ... +``` + +It is recommended to enable building OpenMP alongside Flang and flang-rt +as well. This will build `omp_lib.mod` required to use OpenMP from Fortran. +Building Compiler-RT may also be required, particularly on platforms that do +not provide all C-ABI functionality (such as Windows). + +```bash +cmake -S /llvm \ + -DNinja \ + -DCMAKE_BUILD_TYPE=Release \ + -DLLVM_ENABLE_PROJECTS="flang;openmp" \ + -DLLVM_ENABLE_RUNTIMES="compiler-rt;flang-rt" \ + ... +``` + +By default, the enabled runtimes will only be built for the host platform +(`-DLLVM_RUNTIME_TARGETS=default`). To add additional targets to support +cross-compilation via `flang-new --target=`, add more triples to +`LLVM_RUNTIME_TARGETS`, such as +`-DLLVM_RUNTIME_TARGETS="default;aarch64-linux-gnu"`. + +After configuration, build, test, and install the runtime(s) via + +```shell +$ ninja flang-rt +$ ninja check-flang-rt +$ ninja install +``` + + +### Runtime-only/Out-of-Tree Build + +Instead of building Clang and Flang from scratch, the Runtime-only build uses +CMake's environment introspection to find a C, C++, and Fortran compiler. The +compiler to be used can be controlled using CMake's standard mechanisms such as +`CMAKE_CXX_COMPILER`, `CMAKE_CXX_COMPILER`, and `CMAKE_Fortran_COMPILER`. +`CMAKE_Fortran_COMPILER` must be `flang-new` built from the same Git commit as +flang-rt to ensure they are using the same ABI. The C and C++ compiler +can be any compiler supporting the same ABI. + +In addition to the compiler, the build be able to find LLVM development tools jeanPerier wrote: ```suggestion In addition to the compiler, the build must be able to find LLVM development tools ``` https://github.com/llvm/llvm-project/pull/110217 ___ 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] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)
@@ -0,0 +1,101 @@
+#===-- unittests/CMakeLists.txt
===#
+#
+# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+# See https://llvm.org/LICENSE.txt for license information.
+# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+#
+#======#
+
+# Add GTest if not already present.
+# Using a function so LLVM_SUBPROJECT_TITLE does not propagate.
+function (build_gtest)
+ set(LLVM_SUBPROJECT_TITLE "Third-Party/Google Test")
+ add_subdirectory("${LLVM_THIRD_PARTY_DIR}/unittest"
"${CMAKE_CURRENT_BINARY_DIR}/third-party/unittest")
+endfunction ()
+if (NOT TARGET llvm_gtest)
+ build_gtest()
+endif ()
+
+# LLVM's modified GTest depends on LLVM, but not all runtime projects using
+# GTest also add the include search path.
+target_include_directories(llvm_gtest PUBLIC "${LLVM_INCLUDE_DIR}"
"${LLVM_MAIN_INCLUDE_DIR}")
jeanPerier wrote:
I am getting a cmake error here:
```
unittests/CMakeLists.txt:21 (target_include_directories):
target_include_directories may only set INTERFACE properties on IMPORTED
target
When building out of tree with test enabled (I previously built flang, clang,
and llvm with `-DLLVM_INSTALL_GTEST=ON`).
https://github.com/llvm/llvm-project/pull/110217
___
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] release/19.x: [clang-repl] Fix undefined lld::wasm::link symbol while building clangInterpreter for wasm (#113446) (PR #115848)
https://github.com/vgvassilev approved this pull request. LGTM, the risk of breaking binary compatibility and user base is very low. https://github.com/llvm/llvm-project/pull/115848 ___ 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/19.x: [WebAssembly] Fix rethrow's index calculation (#114693) (PR #115844)
aheejin wrote: What do you mean by already done? This is a request to backport the fix to 19.4 release. https://github.com/llvm/llvm-project/pull/115844 ___ 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/19.x: [WebAssembly] Fix rethrow's index calculation (#114693) (PR #115844)
https://github.com/dschuff approved this pull request. LGTM, although it looks like this is already done? https://github.com/llvm/llvm-project/pull/115844 ___ 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] release/19.x: [clang-repl] Fix undefined lld::wasm::link symbol while building clangInterpreter for wasm (#113446) (PR #115848)
aheejin wrote: As I said I'm not a release maintainer. I don't have permission to merge commits to release branches. https://github.com/llvm/llvm-project/pull/115848 ___ 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] [libcxxabi] release/19.x: [libc++] Fix broken configuration system-libcxxabi on Apple (#110920) (PR #115892)
https://github.com/llvmbot created
https://github.com/llvm/llvm-project/pull/115892
Backport 21da4e7f51c7adfd0b1c5defc8bd0d16ea1ce759
Requested by: @mgorny
>From 9a0c3e5488912da04e5465d0c3427ed21d23de0e Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Wed, 9 Oct 2024 08:46:59 -0400
Subject: [PATCH] [libc++] Fix broken configuration system-libcxxabi on Apple
(#110920)
On Apple platforms, using system-libcxxabi as an ABI library wouldn't
work because we'd try to re-export symbols from libc++abi that the
system libc++abi.dylib might not have. Instead, only re-export those
symbols when we're using the in-tree libc++abi.
This does mean that libc++.dylib won't re-export any libc++abi symbols
when building against the system libc++abi, which could be fixed in
various ways. However, the best solution really depends on the intended
use case, so this patch doesn't try to solve that problem.
As a drive-by, also improve the diagnostic message when the user forgets
to set the LIBCXX_CXX_ABI_INCLUDE_PATHS variable, which would previously
lead to a confusing error.
Closes #104672
(cherry picked from commit 21da4e7f51c7adfd0b1c5defc8bd0d16ea1ce759)
---
libcxx/cmake/Modules/HandleLibCXXABI.cmake | 25 +-
libcxx/src/CMakeLists.txt | 8 ++-
libcxxabi/src/CMakeLists.txt | 2 ++
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/libcxx/cmake/Modules/HandleLibCXXABI.cmake
b/libcxx/cmake/Modules/HandleLibCXXABI.cmake
index 34e9a672a960f9..52236f473f35de 100644
--- a/libcxx/cmake/Modules/HandleLibCXXABI.cmake
+++ b/libcxx/cmake/Modules/HandleLibCXXABI.cmake
@@ -83,6 +83,10 @@ endfunction()
# Link against a system-provided libstdc++
if ("${LIBCXX_CXX_ABI}" STREQUAL "libstdc++")
+ if(NOT LIBCXX_CXX_ABI_INCLUDE_PATHS)
+message(FATAL_ERROR "LIBCXX_CXX_ABI_INCLUDE_PATHS must be set when
selecting libstdc++ as an ABI library")
+ endif()
+
add_library(libcxx-abi-headers INTERFACE)
import_private_headers(libcxx-abi-headers "${LIBCXX_CXX_ABI_INCLUDE_PATHS}"
"cxxabi.h;bits/c++config.h;bits/os_defines.h;bits/cpu_defines.h;bits/cxxabi_tweaks.h;bits/cxxabi_forced.h")
@@ -96,6 +100,10 @@ if ("${LIBCXX_CXX_ABI}" STREQUAL "libstdc++")
# Link against a system-provided libsupc++
elseif ("${LIBCXX_CXX_ABI}" STREQUAL "libsupc++")
+ if(NOT LIBCXX_CXX_ABI_INCLUDE_PATHS)
+message(FATAL_ERROR "LIBCXX_CXX_ABI_INCLUDE_PATHS must be set when
selecting libsupc++ as an ABI library")
+ endif()
+
add_library(libcxx-abi-headers INTERFACE)
import_private_headers(libcxx-abi-headers "${LIBCXX_CXX_ABI_INCLUDE_PATHS}"
"cxxabi.h;bits/c++config.h;bits/os_defines.h;bits/cpu_defines.h;bits/cxxabi_tweaks.h;bits/cxxabi_forced.h")
@@ -114,7 +122,18 @@ elseif ("${LIBCXX_CXX_ABI}" STREQUAL "libcxxabi")
target_compile_definitions(libcxx-abi-headers INTERFACE
"-DLIBCXX_BUILDING_LIBCXXABI")
if (TARGET cxxabi_shared)
-add_library(libcxx-abi-shared ALIAS cxxabi_shared)
+add_library(libcxx-abi-shared INTERFACE)
+target_link_libraries(libcxx-abi-shared INTERFACE cxxabi_shared)
+
+# When using the in-tree libc++abi as an ABI library, libc++ re-exports the
+# libc++abi symbols (on platforms where it can) because libc++abi is only
an
+# implementation detail of libc++.
+target_link_libraries(libcxx-abi-shared INTERFACE cxxabi-reexports)
+
+# Populate the OUTPUT_NAME property of libcxx-abi-shared because that is
used when
+# generating a linker script.
+get_target_property(_output_name cxxabi_shared OUTPUT_NAME)
+set_target_properties(libcxx-abi-shared PROPERTIES "OUTPUT_NAME"
"${_output_name}")
endif()
if (TARGET cxxabi_static)
@@ -131,6 +150,10 @@ elseif ("${LIBCXX_CXX_ABI}" STREQUAL "libcxxabi")
# Link against a system-provided libc++abi
elseif ("${LIBCXX_CXX_ABI}" STREQUAL "system-libcxxabi")
+ if(NOT LIBCXX_CXX_ABI_INCLUDE_PATHS)
+message(FATAL_ERROR "LIBCXX_CXX_ABI_INCLUDE_PATHS must be set when
selecting system-libcxxabi as an ABI library")
+ endif()
+
add_library(libcxx-abi-headers INTERFACE)
import_private_headers(libcxx-abi-headers "${LIBCXX_CXX_ABI_INCLUDE_PATHS}"
"cxxabi.h;__cxxabi_config.h")
target_compile_definitions(libcxx-abi-headers INTERFACE
"-DLIBCXX_BUILDING_LIBCXXABI")
diff --git a/libcxx/src/CMakeLists.txt b/libcxx/src/CMakeLists.txt
index 0dfc9647558d46..b9ecbb196694a9 100644
--- a/libcxx/src/CMakeLists.txt
+++ b/libcxx/src/CMakeLists.txt
@@ -229,14 +229,10 @@ if (LIBCXX_ENABLE_SHARED)
target_link_libraries(cxx_shared PUBLIC libcxx-abi-shared)
endif()
- # Maybe re-export symbols from libc++abi
- # In particular, we don't re-export the symbols if libc++abi is merged
statically
- # into libc++ because in that case there's no dylib to re-export from.
+ # Maybe force some symbols to be weak, not weak or not exported.
+ # TODO: This shouldn't depend on the platform, and ideally it should be done
in the sources.
if (APPLE AND LIBCXX_CXX
