Merge remote-tracking branch 'origin/main' into ir2vec

Author: mtrofin

.ci/all_requirements.txt

@@ -194,9 +194,9 @@ ml-dtypes==0.5.1 ; python_version < "3.13" \
     --hash=sha256:d13755f8e8445b3870114e5b6240facaa7cb0c3361e54beba3e07fa912a6e12b \
     --hash=sha256:fd918d4e6a4e0c110e2e05be7a7814d10dc1b95872accbf6512b80a109b71ae1
     # via -r mlir/python/requirements.txt
-nanobind==2.7.0 \
-    --hash=sha256:73b12d0e751d140d6c1bf4b215e18818a8debfdb374f08dc3776ad208d808e74 \
-    --hash=sha256:f9f1b160580c50dcf37b6495a0fd5ec61dc0d95dae5f8004f87dd9ad7eb46b34
+nanobind==2.9.2 \
+    --hash=sha256:c37957ffd5eac7eda349cff3622ecd32e5ee1244ecc912c99b5bc8188bafd16e \
+    --hash=sha256:e7608472de99d375759814cab3e2c94aba3f9ec80e62cfef8ced495ca5c27d6e
     # via -r mlir/python/requirements.txt
 numpy==2.0.2 \
     --hash=sha256:0123ffdaa88fa4ab64835dcbde75dcdf89c453c922f18dced6e27c90d1d0ec5a \
@@ -383,6 +383,10 @@ swig==4.3.1 \
     --hash=sha256:efec16327029f682f649a26da726bb0305be8800bd0f1fa3e81bf0769cf5b476 \
     --hash=sha256:fc496c0d600cf1bb2d91e28d3d6eae9c4301e5ea7a0dec5a4281b5efed4245a8
     # via -r lldb/test/requirements.txt
+typing-extensions==4.15.0 \
+    --hash=sha256:0cea48d173cc12fa28ecabc3b837ea3cf6f38c6d1136f85cbaaf598984861466 \
+    --hash=sha256:f0fa19c6845758ab08074a0cfa8b7aecb71c999ca73d62883bc25cc018c4e548
+    # via -r mlir/python/requirements.txt
 urllib3==2.5.0 \
     --hash=sha256:3fc47733c7e419d4bc3f6b3dc2b4f890bb743906a30d56ba4a5bfa4bbff92760 \
     --hash=sha256:e6b01673c0fa6a13e374b50871808eb3bf7046c4b125b216f6bf1cc604cff0dc

.github/CODEOWNERS

@@ -17,6 +17,7 @@
 /runtimes/ @llvm/reviewers-libcxx
 
 /llvm/lib/Analysis/BasicAliasAnalysis.cpp @nikic
+/llvm/lib/Analysis/HashRecognize.cpp @artagnon @pfusik
 /llvm/lib/Analysis/InstructionSimplify.cpp @nikic
 /llvm/lib/Analysis/LazyValueInfo.cpp @nikic
 /llvm/lib/Analysis/ScalarEvolution.cpp @nikic

clang-tools-extra/clangd/ModulesBuilder.cpp

@@ -103,10 +103,13 @@ class FailedPrerequisiteModules : public PrerequisiteModules {
   }
 };
 
-struct ModuleFile {
+/// Represents a reference to a module file (*.pcm).
+class ModuleFile {
+protected:
   ModuleFile(StringRef ModuleName, PathRef ModuleFilePath)
       : ModuleName(ModuleName.str()), ModuleFilePath(ModuleFilePath.str()) {}
 
+public:
   ModuleFile() = delete;
 
   ModuleFile(const ModuleFile &) = delete;
@@ -128,21 +131,58 @@ struct ModuleFile {
     new (this) ModuleFile(std::move(Other));
     return *this;
   }
-
-  ~ModuleFile() {
-    if (!ModuleFilePath.empty() && !DebugModulesBuilder)
-      llvm::sys::fs::remove(ModuleFilePath);
-  }
+  virtual ~ModuleFile() = default;
 
   StringRef getModuleName() const { return ModuleName; }
 
   StringRef getModuleFilePath() const { return ModuleFilePath; }
 
-private:
+protected:
   std::string ModuleName;
   std::string ModuleFilePath;
 };
 
+/// Represents a prebuilt module file which is not owned by us.
+class PrebuiltModuleFile : public ModuleFile {
+private:
+  // private class to make sure the class can only be constructed by member
+  // functions.
+  struct CtorTag {};
+
+public:
+  PrebuiltModuleFile(StringRef ModuleName, PathRef ModuleFilePath, CtorTag)
+      : ModuleFile(ModuleName, ModuleFilePath) {}
+
+  static std::shared_ptr<PrebuiltModuleFile> make(StringRef ModuleName,
+                                                  PathRef ModuleFilePath) {
+    return std::make_shared<PrebuiltModuleFile>(ModuleName, ModuleFilePath,
+                                                CtorTag{});
+  }
+};
+
+/// Represents a module file built by us. We're responsible to remove it.
+class BuiltModuleFile : public ModuleFile {
+private:
+  // private class to make sure the class can only be constructed by member
+  // functions.
+  struct CtorTag {};
+
+public:
+  BuiltModuleFile(StringRef ModuleName, PathRef ModuleFilePath, CtorTag)
+      : ModuleFile(ModuleName, ModuleFilePath) {}
+
+  static std::shared_ptr<BuiltModuleFile> make(StringRef ModuleName,
+                                               PathRef ModuleFilePath) {
+    return std::make_shared<BuiltModuleFile>(ModuleName, ModuleFilePath,
+                                             CtorTag{});
+  }
+
+  virtual ~BuiltModuleFile() {
+    if (!ModuleFilePath.empty() && !DebugModulesBuilder)
+      llvm::sys::fs::remove(ModuleFilePath);
+  }
+};
+
 // ReusablePrerequisiteModules - stands for PrerequisiteModules for which all
 // the required modules are built successfully. All the module files
 // are owned by the modules builder.
@@ -171,9 +211,9 @@ class ReusablePrerequisiteModules : public PrerequisiteModules {
   std::string getAsString() const {
     std::string Result;
     llvm::raw_string_ostream OS(Result);
-    for (const auto &ModuleFile : RequiredModules) {
-      OS << "-fmodule-file=" << ModuleFile->getModuleName() << "="
-         << ModuleFile->getModuleFilePath() << " ";
+    for (const auto &MF : RequiredModules) {
+      OS << "-fmodule-file=" << MF->getModuleName() << "="
+         << MF->getModuleFilePath() << " ";
     }
     return Result;
   }
@@ -185,9 +225,9 @@ class ReusablePrerequisiteModules : public PrerequisiteModules {
     return BuiltModuleNames.contains(ModuleName);
   }
 
-  void addModuleFile(std::shared_ptr<const ModuleFile> ModuleFile) {
-    BuiltModuleNames.insert(ModuleFile->getModuleName());
-    RequiredModules.emplace_back(std::move(ModuleFile));
+  void addModuleFile(std::shared_ptr<const ModuleFile> MF) {
+    BuiltModuleNames.insert(MF->getModuleName());
+    RequiredModules.emplace_back(std::move(MF));
   }
 
 private:
@@ -265,7 +305,7 @@ bool IsModuleFilesUpToDate(
 
 /// Build a module file for module with `ModuleName`. The information of built
 /// module file are stored in \param BuiltModuleFiles.
-llvm::Expected<ModuleFile>
+llvm::Expected<std::shared_ptr<BuiltModuleFile>>
 buildModuleFile(llvm::StringRef ModuleName, PathRef ModuleUnitFileName,
                 const GlobalCompilationDatabase &CDB, const ThreadsafeFS &TFS,
                 const ReusablePrerequisiteModules &BuiltModuleFiles) {
@@ -340,7 +380,7 @@ buildModuleFile(llvm::StringRef ModuleName, PathRef ModuleUnitFileName,
                       ModuleUnitFileName));
   }
 
-  return ModuleFile{ModuleName, Inputs.CompileCommand.Output};
+  return BuiltModuleFile::make(ModuleName, Inputs.CompileCommand.Output);
 }
 
 bool ReusablePrerequisiteModules::canReuse(
@@ -509,10 +549,51 @@ class ModulesBuilder::ModulesBuilderImpl {
                        ReusablePrerequisiteModules &BuiltModuleFiles);
 
 private:
+  /// Try to get prebuilt module files from the compilation database.
+  void getPrebuiltModuleFile(StringRef ModuleName, PathRef ModuleUnitFileName,
+                             const ThreadsafeFS &TFS,
+                             ReusablePrerequisiteModules &BuiltModuleFiles);
+
   ModuleFileCache Cache;
   ModuleNameToSourceCache ProjectModulesCache;
 };
 
+void ModulesBuilder::ModulesBuilderImpl::getPrebuiltModuleFile(
+    StringRef ModuleName, PathRef ModuleUnitFileName, const ThreadsafeFS &TFS,
+    ReusablePrerequisiteModules &BuiltModuleFiles) {
+  auto Cmd = getCDB().getCompileCommand(ModuleUnitFileName);
+  if (!Cmd)
+    return;
+
+  ParseInputs Inputs;
+  Inputs.TFS = &TFS;
+  Inputs.CompileCommand = std::move(*Cmd);
+
+  IgnoreDiagnostics IgnoreDiags;
+  auto CI = buildCompilerInvocation(Inputs, IgnoreDiags);
+  if (!CI)
+    return;
+
+  // We don't need to check if the module files are in ModuleCache or adding
+  // them to the module cache. As even if the module files are in the module
+  // cache, we still need to validate them. And it looks not helpful to add them
+  // to the module cache, since we may always try to get the prebuilt module
+  // files before building the module files by ourselves.
+  for (auto &[ModuleName, ModuleFilePath] :
+       CI->getHeaderSearchOpts().PrebuiltModuleFiles) {
+    if (BuiltModuleFiles.isModuleUnitBuilt(ModuleName))
+      continue;
+
+    if (IsModuleFileUpToDate(ModuleFilePath, BuiltModuleFiles,
+                             TFS.view(std::nullopt))) {
+      log("Reusing prebuilt module file {0} of module {1} for {2}",
+          ModuleFilePath, ModuleName, ModuleUnitFileName);
+      BuiltModuleFiles.addModuleFile(
+          PrebuiltModuleFile::make(ModuleName, ModuleFilePath));
+    }
+  }
+}
+
 llvm::Error ModulesBuilder::ModulesBuilderImpl::getOrBuildModuleFile(
     PathRef RequiredSource, StringRef ModuleName, const ThreadsafeFS &TFS,
     CachingProjectModules &MDB, ReusablePrerequisiteModules &BuiltModuleFiles) {
@@ -532,6 +613,11 @@ llvm::Error ModulesBuilder::ModulesBuilderImpl::getOrBuildModuleFile(
     return llvm::createStringError(
         llvm::formatv("Don't get the module unit for module {0}", ModuleName));
 
+  /// Try to get prebuilt module files from the compilation database first. This
+  /// helps to avoid building the module files that are already built by the
+  /// compiler.
+  getPrebuiltModuleFile(ModuleName, ModuleUnitFileName, TFS, BuiltModuleFiles);
+
   // Get Required modules in topological order.
   auto ReqModuleNames = getAllRequiredModules(RequiredSource, MDB, ModuleName);
   for (llvm::StringRef ReqModuleName : ReqModuleNames) {
@@ -551,15 +637,14 @@ llvm::Error ModulesBuilder::ModulesBuilderImpl::getOrBuildModuleFile(
 
     std::string ReqFileName =
         MDB.getSourceForModuleName(ReqModuleName, RequiredSource);
-    llvm::Expected<ModuleFile> MF = buildModuleFile(
+    llvm::Expected<std::shared_ptr<BuiltModuleFile>> MF = buildModuleFile(
         ReqModuleName, ReqFileName, getCDB(), TFS, BuiltModuleFiles);
     if (llvm::Error Err = MF.takeError())
       return Err;
 
-    log("Built module {0} to {1}", ReqModuleName, MF->getModuleFilePath());
-    auto BuiltModuleFile = std::make_shared<const ModuleFile>(std::move(*MF));
-    Cache.add(ReqModuleName, BuiltModuleFile);
-    BuiltModuleFiles.addModuleFile(std::move(BuiltModuleFile));
+    log("Built module {0} to {1}", ReqModuleName, (*MF)->getModuleFilePath());
+    Cache.add(ReqModuleName, *MF);
+    BuiltModuleFiles.addModuleFile(std::move(*MF));
   }
 
   return llvm::Error::success();

clang-tools-extra/clangd/unittests/PrerequisiteModulesTest.cpp

@@ -644,6 +644,35 @@ import M;
   EXPECT_EQ(CDB.getGlobalScanningCount(), 1u);
 }
 
+TEST_F(PrerequisiteModulesTests, PrebuiltModuleFileTest) {
+  MockDirectoryCompilationDatabase CDB(TestDir, FS);
+
+  CDB.addFile("M.cppm", R"cpp(
+export module M;
+  )cpp");
+
+  CDB.addFile("U.cpp", R"cpp(
+import M;
+  )cpp");
+
+  // Use ModulesBuilder to produce the prebuilt module file.
+  ModulesBuilder Builder(CDB);
+  auto ModuleInfo =
+      Builder.buildPrerequisiteModulesFor(getFullPath("U.cpp"), FS);
+  HeaderSearchOptions HS(TestDir);
+  ModuleInfo->adjustHeaderSearchOptions(HS);
+
+  CDB.ExtraClangFlags.push_back("-fmodule-file=M=" +
+                                HS.PrebuiltModuleFiles["M"]);
+  ModulesBuilder Builder2(CDB);
+  auto ModuleInfo2 =
+      Builder2.buildPrerequisiteModulesFor(getFullPath("U.cpp"), FS);
+  HeaderSearchOptions HS2(TestDir);
+  ModuleInfo2->adjustHeaderSearchOptions(HS2);
+
+  EXPECT_EQ(HS.PrebuiltModuleFiles, HS2.PrebuiltModuleFiles);
+}
+
 } // namespace
 } // namespace clang::clangd
 

clang-tools-extra/docs/ReleaseNotes.rst

@@ -126,6 +126,10 @@ Improvements to clang-tidy
 - Improved :program:`clang-tidy` option `-quiet` by suppressing diagnostic
   count messages.
 
+- Improved :program:`clang-tidy` by not crashing when an empty `directory`
+  field is used in a compilation database; the current working directory
+  will be used instead, and an error message will be printed.
+
 New checks
 ^^^^^^^^^^
 

clang-tools-extra/test/clang-tidy/infrastructure/Inputs/invalid-database/compile_commands.json

@@ -0,0 +1,5 @@
+[{
+    "directory":"/invalid/",
+    "file":"/tmp/",
+    "arguments": []
+}]

clang-tools-extra/test/clang-tidy/infrastructure/empty-database.cpp

@@ -1,5 +1,5 @@
 // UNSUPPORTED: system-windows
 
-// RUN: not --crash clang-tidy -p %S/Inputs/empty-database %s 2>&1 | FileCheck %s
+// RUN: clang-tidy -p %S/Inputs/empty-database %s 2>&1 | FileCheck %s
 
-// CHECK: LLVM ERROR: Cannot chdir into ""!
+// CHECK: 'directory' field of compilation database is empty; using the current working directory instead.

clang-tools-extra/test/clang-tidy/infrastructure/invalid-database.cpp

@@ -0,0 +1,5 @@
+// UNSUPPORTED: system-windows
+
+// RUN: not --crash clang-tidy -p %S/Inputs/invalid-database %s 2>&1 | FileCheck %s
+
+// CHECK: LLVM ERROR: Cannot chdir into "/invalid/"!

clang/docs/ReleaseNotes.rst

@@ -206,6 +206,7 @@ Non-comprehensive list of changes in this release
   Currently, the use of ``__builtin_dedup_pack`` is limited to template arguments and base
   specifiers, it also must be used within a template context.
 
+- ``__builtin_assume_dereferenceable`` now accepts non-constant size operands.
 
 New Compiler Flags
 ------------------
@@ -379,6 +380,10 @@ X86 Support
 - NOTE: Please avoid use of the __builtin_ia32_* intrinsics - these are not
   guaranteed to exist in future releases, or match behaviour with previous
   releases of clang or other compilers.
+- Remove `m[no-]avx10.x-[256,512]` and `m[no-]evex512` options from Clang
+  driver.
+- Remove `[no-]evex512` feature request from intrinsics and builtins.
+- Change features `avx10.x-[256,512]` to `avx10.x`.
 
 Arm and AArch64 Support
 ^^^^^^^^^^^^^^^^^^^^^^^
@@ -391,6 +396,7 @@ Windows Support
 
 LoongArch Support
 ^^^^^^^^^^^^^^^^^
+- Enable linker relaxation by default for loongarch64.
 
 RISC-V Support
 ^^^^^^^^^^^^^^

clang/docs/UsersManual.rst

@@ -4581,59 +4581,14 @@ implicitly included in later levels.
 - ``-march=x86-64-v3``: (close to Haswell) AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE
 - ``-march=x86-64-v4``: AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL
 
-`Intel AVX10 ISA <https://cdrdv2.intel.com/v1/dl/getContent/784267>`_ is
+`Intel AVX10 ISA <https://cdrdv2.intel.com/v1/dl/getContent/784343>`_ is
 a major new vector ISA incorporating the modern vectorization aspects of
 Intel AVX-512. This ISA will be supported on all future Intel processors.
-Users are supposed to use the new options ``-mavx10.N`` and ``-mavx10.N-512``
-on these processors and should not use traditional AVX512 options anymore.
-
-The ``N`` in ``-mavx10.N`` represents a continuous integer number starting
-from ``1``. ``-mavx10.N`` is an alias of ``-mavx10.N-256``, which means to
-enable all instructions within AVX10 version N at a maximum vector length of
-256 bits. ``-mavx10.N-512`` enables all instructions at a maximum vector
-length of 512 bits, which is a superset of instructions ``-mavx10.N`` enabled.
-
-Current binaries built with AVX512 features can run on Intel AVX10/512 capable
-processors without re-compile, but cannot run on AVX10/256 capable processors.
-Users need to re-compile their code with ``-mavx10.N``, and maybe update some
-code that calling to 512-bit X86 specific intrinsics and passing or returning
-512-bit vector types in function call, if they want to run on AVX10/256 capable
-processors. Binaries built with ``-mavx10.N`` can run on both AVX10/256 and
-AVX10/512 capable processors.
-
-Users can add a ``-mno-evex512`` in the command line with AVX512 options if
-they want to run the binary on both legacy AVX512 and new AVX10/256 capable
-processors. The option has the same constraints as ``-mavx10.N``, i.e.,
-cannot call to 512-bit X86 specific intrinsics and pass or return 512-bit vector
-types in function call.
-
-Users should avoid using AVX512 features in function target attributes when
-developing code for AVX10. If they have to do so, they need to add an explicit
-``evex512`` or ``no-evex512`` together with AVX512 features for 512-bit or
-non-512-bit functions respectively to avoid unexpected code generation. Both
-command line option and target attribute of EVEX512 feature can only be used
-with AVX512. They don't affect vector size of AVX10.
-
-User should not mix the use AVX10 and AVX512 options together at any time,
-because the option combinations are conflicting sometimes. For example, a
-combination of ``-mavx512f -mavx10.1-256`` doesn't show a clear intention to
-compiler, since instructions in AVX512F and AVX10.1/256 intersect but do not
-overlap. In this case, compiler will emit warning for it, but the behavior
-is determined. It will generate the same code as option ``-mavx10.1-512``.
-A similar case is ``-mavx512f -mavx10.2-256``, which equals to
-``-mavx10.1-512 -mavx10.2-256``, because ``avx10.2-256`` implies ``avx10.1-256``
-and ``-mavx512f -mavx10.1-256`` equals to ``-mavx10.1-512``.
-
-There are some new macros introduced with AVX10 support. ``-mavx10.1-256`` will
-enable ``__AVX10_1__`` and ``__EVEX256__``, while ``-mavx10.1-512`` enables
-``__AVX10_1__``, ``__EVEX256__``, ``__EVEX512__``  and ``__AVX10_1_512__``.
-Besides, both ``-mavx10.1-256`` and ``-mavx10.1-512`` will enable all AVX512
-feature specific macros. A AVX512 feature will enable both ``__EVEX256__``,
-``__EVEX512__`` and its own macro. So ``__EVEX512__`` can be used to guard code
-that can run on both legacy AVX512 and AVX10/512 capable processors but cannot
-run on AVX10/256, while a AVX512 macro like ``__AVX512F__`` cannot tell the
-difference among the three options. Users need to check additional macros
-``__AVX10_1__`` and ``__EVEX512__`` if they want to make distinction.
+Users are supposed to use the new options ``-mavx10.N`` on these processors
+and should not use traditional AVX512 options anymore. The ``N`` in
+``-mavx10.N`` represents a continuous integer number starting
+from ``1``. Current binaries built with AVX512 features can run on Intel AVX10
+capable processors without re-compile.
 
 ARM
 ^^^