LLVM and SPIRV-LLVM-Translator pulldown (WW30 2024)

.git-blame-ignore-revs

@@ -84,3 +84,6 @@ b9079baaddfed5e604fbfaa1d81a7a1c38e78c26
 
 # [libc++][NFC] Run clang-format on libcxx/include again (#95874)
 e2c2ffbe7a1b5d9e32a2ce64279475b50c4cba5b
+
+# [lldb][nfc] Deindent ProcessGDBRemote::SetThreadStopInfo by two levels
+b32931c5b32eb0d2cf37d688b34f8548c9674c19

.github/new-prs-labeler.yml

@@ -775,6 +775,29 @@ backend:AArch64:
   - clang/include/clang/Sema/SemaARM.h
   - clang/lib/Sema/SemaARM.cpp
 
+backend:Hexagon:
+  - clang/include/clang/Basic/BuiltinsHexagon*.def
+  - clang/include/clang/Sema/SemaHexagon.h
+  - clang/lib/Basic/Targets/Hexagon.*
+  - clang/lib/CodeGen/Targets/Hexagon.cpp
+  - clang/lib/Driver/ToolChains/Hexagon.*
+  - clang/lib/Sema/SemaHexagon.cpp
+  - lld/ELF/Arch/Hexagon.cpp
+  - lldb/source/Plugins/ABI/Hexagon/**
+  - lldb/source/Plugins/DynamicLoader/Hexagon-DYLD/**
+  - llvm/include/llvm/BinaryFormat/ELFRelocs/Hexagon.def
+  - llvm/include/llvm/IR/IntrinsicsHexagon*
+  - llvm/include/llvm/Support/Hexagon*
+  - llvm/lib/Support/Hexagon*
+  - llvm/lib/Target/Hexagon/**
+  - llvm/test/CodeGen/Hexagon/**
+  - llvm/test/CodeGen/*/Hexagon/**
+  - llvm/test/DebugInfo/*/Hexagon/**
+  - llvm/test/Transforms/*/Hexagon
+  - llvm/test/MC/Disassembler/Hexagon/**
+  - llvm/test/MC/Hexagon/**
+  - llvm/test/tools/llvm-objdump/ELF/Hexagon/**
+
 backend:loongarch:
   - llvm/include/llvm/IR/IntrinsicsLoongArch.td
   - llvm/test/MC/LoongArch/**

.github/workflows/issue-write.yml

@@ -5,6 +5,7 @@ on:
     workflows:
       - "Check code formatting"
       - "Check for private emails used in PRs"
+      - "PR Request Release Note"
     types:
       - completed
 
@@ -17,7 +18,11 @@ jobs:
     permissions:
       pull-requests: write
     if: >
-      github.event.workflow_run.event == 'pull_request'
+      github.event.workflow_run.event == 'pull_request' &&
+      (
+        github.event.workflow_run.conclusion == 'success' ||
+        github.event.workflow_run.conclusion == 'failure'
+      )
     steps:
       - name: 'Download artifact'
         uses: actions/download-artifact@6b208ae046db98c579e8a3aa621ab581ff575935 # v4.1.1
@@ -92,7 +97,11 @@ jobs:
 
             var pr_number = 0;
             gql_result.repository.ref.associatedPullRequests.nodes.forEach((pr) => {
-              if (pr.baseRepository.owner.login = context.repo.owner && pr.state == 'OPEN') {
+
+              // The largest PR number is the one we care about.  The only way
+              // to have more than one associated pull requests is if all the
+              // old pull requests are in the closed state.
+              if (pr.baseRepository.owner.login = context.repo.owner && pr.number > pr_number) {
                 pr_number = pr.number;
               }
             });

.github/workflows/libcxx-build-and-test.yaml

@@ -63,8 +63,8 @@ jobs:
         cxx: [ 'clang++-19' ]
         include:
           - config: 'generic-gcc'
-            cc: 'gcc-13'
-            cxx: 'g++-13'
+            cc: 'gcc-14'
+            cxx: 'g++-14'
     steps:
       - uses: actions/checkout@v4
       - name: ${{ matrix.config }}.${{ matrix.cxx }}
@@ -101,8 +101,8 @@ jobs:
         cxx: [ 'clang++-19' ]
         include:
           - config: 'generic-gcc-cxx11'
-            cc: 'gcc-13'
-            cxx: 'g++-13'
+            cc: 'gcc-14'
+            cxx: 'g++-14'
           - config: 'generic-cxx23'
             cc: 'clang-17'
             cxx: 'clang++-17'

.github/workflows/pr-request-release-note.yml

@@ -2,7 +2,6 @@ name: PR Request Release Note
 
 permissions:
   contents: read
-  pull-requests: write
 
 on:
   pull_request:
@@ -41,3 +40,10 @@ jobs:
             --token "$GITHUB_TOKEN" \
             request-release-note \
             --pr-number ${{ github.event.pull_request.number}}
+
+      - uses: actions/upload-artifact@26f96dfa697d77e81fd5907df203aa23a56210a8 #v4.3.0
+        if: always()
+        with:
+          name: workflow-args
+          path: |
+            comments

bolt/docs/CommandLineArgumentReference.md

@@ -259,6 +259,10 @@
 
   Always use long jumps/nops for Linux kernel static keys
 
+- `--match-profile-with-function-hash`
+
+  Match profile with function hash
+
 - `--max-data-relocations=<uint>`
 
   Maximum number of data relocations to process
@@ -279,6 +283,12 @@
 
   List of functions to pad with amount of bytes
 
+- `--print-mappings`
+
+  Print mappings in the legend, between characters/blocks and text sections
+  (default false).
+
+
 - `--profile-format=<value>`
 
   Format to dump profile output in aggregation mode, default is fdata
@@ -684,6 +694,10 @@
 
   Use a modified clustering algorithm geared towards minimizing branches
 
+- `--name-similarity-function-matching-threshold=<uint>`
+
+  Match functions using namespace and edit distance.
+
 - `--no-inline`
 
   Disable all inlining (overrides other inlining options)
@@ -1232,4 +1246,4 @@
 
 - `--print-options`
 
-  Print non-default options after command line parsing
+  Print non-default options after command line parsing

bolt/docs/Heatmaps.md

@@ -1,9 +1,9 @@
 # Code Heatmaps
 
 BOLT has gained the ability to print code heatmaps based on
-sampling-based LBR profiles generated by `perf`. The output is produced
-in colored ASCII to be displayed in a color-capable terminal. It looks
-something like this:
+sampling-based profiles generated by `perf`, either with `LBR` data or not.
+The output is produced in colored ASCII to be displayed in a color-capable
+terminal. It looks something like this:
 
 ![](./Heatmap.png)
 
@@ -32,20 +32,64 @@ $ llvm-bolt-heatmap -p perf.data <executable>
 ```
 
 By default the heatmap will be dumped to *stdout*. You can change it
-with `-o <heatmapfile>` option. Each character/block in the heatmap
-shows the execution data accumulated for corresponding 64 bytes of
-code. You can change this granularity with a `-block-size` option.
-E.g. set it to 4096 to see code usage grouped by 4K pages.
-Other useful options are:
+with `-o <heatmapfile>` option.
 
-```bash
--line-size=<uint>   - number of entries per line (default 256)
--max-address=<uint> - maximum address considered valid for heatmap (default 4GB)
-```
 
 If you prefer to look at the data in a browser (or would like to share
 it that way), then you can use an HTML conversion tool. E.g.:
 
 ```bash
 $ aha -b -f <heatmapfile> > <heatmapfile>.html
 ```
+
+---
+
+## Background on heatmaps:
+A heatmap is effectively a histogram that is rendered into a grid for better
+visualization.
+In theory we can generate a heatmap using any binary and a perf profile.
+
+Each block/character in the heatmap shows the execution data accumulated for
+corresponding 64 bytes of code. You can change this granularity with a
+`-block-size` option.
+E.g. set it to 4096 to see code usage grouped by 4K pages.
+
+
+When a block is shown as a dot, it means that no samples were found for that
+address.
+When it is shown as a letter, it indicates a captured sample on a particular
+text section of the binary.
+To show a mapping between letters and text sections in the legend, use
+`-print-mappings`.
+When a sampled address does not belong to any of the text sections, the
+characters 'o' or 'O' will be shown.
+
+The legend shows by default the ranges in the heatmap according to the number
+of samples per block.
+A color is assigned per range, except the first two ranges that distinguished by
+lower and upper case letters.
+
+On the Y axis, each row/line starts with an actual address of the binary.
+Consecutive lines in the heatmap advance by the same amount, with the binary
+size covered by a line dependent on the block size and the line size.
+An empty new line is inserted for larger gaps between samples.
+
+On the X axis, the horizontally emitted hex numbers can help *estimate* where
+in the line the samples lie, but they cannot be combined to provide a full
+address, as they are relative to both the bucket and line sizes.
+
+In the example below, the highlighted `0x100` column is not an offset to each
+row's address, but instead, it points to the middle of the line.
+For the generation, the default bucket size was used with a line size of 128.
+
+
+![](./HeatmapHeader.png)
+
+
+Some useful options are:
+
+```
+-line-size=<uint>   - number of entries per line (default 256)
+-max-address=<uint> - maximum address considered valid for heatmap (default 4GB)
+-print-mappings     - print mappings in the legend, between characters/blocks and text sections (default false)
+```

bolt/docs/OptimizingLinux.md

@@ -44,6 +44,11 @@ $ perf2bolt -p perf.data -o perf.fdata vmlinux
 
 Under a high load, `perf.data` should be several gigabytes in size and you should expect the converted `perf.fdata` not to exceed 100 MB.
 
+Profiles collected from multiple workloads could be joined into a single profile using `merge-fdata` utility:
+```bash
+$ merge-fdata perf.1.fdata perf.2.fdata ... perf.<N>.fdata > perf.merged.fdata
+```
+
 Two changes are required for the kernel build. The first one is optional but highly recommended. It introduces a BOLT-reserved space into `vmlinux` code section:
 
 

bolt/include/bolt/Core/BinaryBasicBlock.h

@@ -842,15 +842,6 @@ class BinaryBasicBlock {
   bool analyzeBranch(const MCSymbol *&TBB, const MCSymbol *&FBB,
                      MCInst *&CondBranch, MCInst *&UncondBranch);
 
-  /// Return true if iterator \p I is pointing to the first instruction in
-  /// a pair that could be macro-fused.
-  bool isMacroOpFusionPair(const_iterator I) const;
-
-  /// If the basic block has a pair of instructions suitable for macro-fusion,
-  /// return iterator to the first instruction of the pair.
-  /// Otherwise return end().
-  const_iterator getMacroOpFusionPair() const;
-
   /// Printer required for printing dominator trees.
   void printAsOperand(raw_ostream &OS, bool PrintType = true) {
     if (PrintType)

bolt/include/bolt/Core/BinaryContext.h

@@ -698,10 +698,6 @@ class BinaryContext {
 
   /// Binary-wide aggregated stats.
   struct BinaryStats {
-    /// Stats for macro-fusion.
-    uint64_t MissedMacroFusionPairs{0};
-    uint64_t MissedMacroFusionExecCount{0};
-
     /// Stats for stale profile matching:
     ///   the total number of basic blocks in the profile
     uint32_t NumStaleBlocks{0};

bolt/include/bolt/Core/BinaryFunction.h

@@ -835,10 +835,6 @@ class BinaryFunction {
   /// them.
   void calculateLoopInfo();
 
-  /// Calculate missed macro-fusion opportunities and update BinaryContext
-  /// stats.
-  void calculateMacroOpFusionStats();
-
   /// Returns if BinaryDominatorTree has been constructed for this function.
   bool hasDomTree() const { return BDT != nullptr; }
 
@@ -930,6 +926,10 @@ class BinaryFunction {
     return const_cast<BinaryFunction *>(this)->getInstructionAtOffset(Offset);
   }
 
+  /// When the function is in disassembled state, return an instruction that
+  /// contains the \p Offset.
+  MCInst *getInstructionContainingOffset(uint64_t Offset);
+
   std::optional<MCInst> disassembleInstructionAtOffset(uint64_t Offset) const;
 
   /// Return offset for the first instruction. If there is data at the

bolt/include/bolt/Passes/BinaryFunctionCallGraph.h → bolt/include/bolt/Core/BinaryFunctionCallGraph.h

@@ -1,4 +1,4 @@
-//===- bolt/Passes/CallGraph.h ----------------------------------*- C++ -*-===//
+//===- bolt/Core/CallGraph.h ----------------------------------*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -9,7 +9,7 @@
 #ifndef BOLT_PASSES_BINARY_FUNCTION_CALLGRAPH_H
 #define BOLT_PASSES_BINARY_FUNCTION_CALLGRAPH_H
 
-#include "bolt/Passes/CallGraph.h"
+#include "bolt/Core/CallGraph.h"
 #include <deque>
 #include <functional>
 #include <unordered_map>

bolt/include/bolt/Passes/CallGraph.h → bolt/include/bolt/Core/CallGraph.h

@@ -1,4 +1,4 @@
-//===- bolt/Passes/CallGraph.h ----------------------------------*- C++ -*-===//
+//===- bolt/Core/CallGraph.h ----------------------------------*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.

bolt/include/bolt/Passes/CallGraphWalker.h → bolt/include/bolt/Core/CallGraphWalker.h

@@ -1,4 +1,4 @@
-//===- bolt/Passes/CallGraphWalker.h ----------------------------*- C++ -*-===//
+//===- bolt/Core/CallGraphWalker.h ----------------------------*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.

bolt/include/bolt/Core/DIEBuilder.h

@@ -135,13 +135,6 @@ class DIEBuilder {
 
   /// Returns current state of the DIEBuilder
   State &getState() { return *BuilderState.get(); }
-  /// Resolve the reference in DIE, if target is not loaded into IR,
-  /// pre-allocate it. \p RefCU will be updated to the Unit specific by \p
-  /// RefValue.
-  DWARFDie resolveDIEReference(
-      const DWARFFormValue &RefValue,
-      const DWARFAbbreviationDeclaration::AttributeSpec AttrSpec,
-      DWARFUnit *&RefCU, DWARFDebugInfoEntry &DwarfDebugInfoEntry);
 
   /// Resolve the reference in DIE, if target is not loaded into IR,
   /// pre-allocate it. \p RefCU will be updated to the Unit specific by \p
@@ -165,10 +158,9 @@ class DIEBuilder {
       const DWARFFormValue &Val);
 
   /// Clone an attribute in reference format.
-  void cloneDieReferenceAttribute(
+  void cloneDieOffsetReferenceAttribute(
       DIE &Die, const DWARFUnit &U, const DWARFDie &InputDIE,
-      const DWARFAbbreviationDeclaration::AttributeSpec AttrSpec,
-      const DWARFFormValue &Val);
+      const DWARFAbbreviationDeclaration::AttributeSpec AttrSpec, uint64_t Ref);
 
   /// Clone an attribute in block format.
   void cloneBlockAttribute(