merge main into amd-staging (#398)

passed https://compiler-ci.amd.com/blue/organizations/jenkins/compiler-psdb-amd-staging/detail/compiler-psdb-amd-staging/2459/pipeline/

Author: ronlieb

clang/docs/ClangOffloadBundler.rst

@@ -28,7 +28,7 @@ A bundled code object may also be used to bundle just the offloaded code
 objects, and embedded as data into the host code object. The host compilation
 includes an ``init`` function that will use the runtime corresponding to the
 offload kind (see :ref:`clang-offload-kind-table`) to load the offload code
-objects appropriate to the devices present when the host program is executed.
+objects appropriate for the devices present when the host program is executed.
 
 :program:`clang-offload-bundler` is located in
 `clang/tools/clang-offload-bundler`.
@@ -147,21 +147,21 @@ bundle file is:
   <end>     ::== OFFLOAD_BUNDLER_MAGIC_STR__END__
 
 **comment**
-  The symbol used for starting single-line comment in the file type of
+  The symbol used for starting a single-line comment in the file type of
   constituting bundles. E.g. it is ";" for ll ``File Type`` and "#" for "s"
   ``File Type``.
 
 **bundle_id**
   The :ref:`clang-bundle-entry-id` for the enclosing bundle.
 
 **eol**
-  The end of line character.
+  The end-of-line character.
 
 **bundle**
   The code object stored in one of the supported text file formats.
 
 **OFFLOAD_BUNDLER_MAGIC_STR__**
-  Magic string that marks the existence of offloading data i.e.
+  The magic string that marks the existence of offloading data i.e.
   "__CLANG_OFFLOAD_BUNDLE__".
 
 .. _clang-bundled-code-object-layout:
@@ -231,7 +231,7 @@ Where:
       ============= ==============================================================
       host          Host code object. ``clang-offload-bundler`` always includes
                     this entry as the first bundled code object entry. For an
-                    embedded bundled code object this entry is not used by the
+                    embedded bundled code object, this entry is not used by the
                     runtime and so is generally an empty code object.
 
       hip           Offload code object for the HIP language. Used for all
@@ -272,7 +272,7 @@ without differentiation based on offload kind.
     ``<arch><sub>-<vendor>-<sys>-<env>``
 
     However, in order to standardize outputs for tools that consume bitcode bundles
-    and to parse target ID containing dashes, the bundler only accepts target
+    and to parse a target ID containing dashes, the bundler only accepts target
     triples in the 4-field format:
 
     ``<arch><sub>-<vendor>-<sys>-<env>``
@@ -292,17 +292,17 @@ Bundled Code Object Composition
   * If there is an entry with a target feature specified as *Any*, then all
     entries must specify that target feature as *Any* for the same processor.
 
-There may be additional target specific restrictions.
+There may be additional target-specific restrictions.
 
 .. _compatibility-bundle-entry-id:
 
 Compatibility Rules for Bundle Entry ID
 ---------------------------------------
 
   A code object, specified using its Bundle Entry ID, can be loaded and
-  executed on a target processor, if:
+  executed on a target processor if:
 
-  * Their offload kinds are the same or comptible.
+  * Their offload kinds are the same or compatible.
   * Their target triples are compatible.
   * Their Target IDs are compatible as defined in :ref:`compatibility-target-id`.
 
@@ -331,7 +331,7 @@ Target ID syntax is defined by the following BNF syntax:
 Where:
 
 **processor**
-  Is a the target specific processor or any alternative processor name.
+  Is the target-specific processor or any alternative processor name.
 
 **target-feature**
   Is a target feature name that is supported by the processor. Each target
@@ -350,7 +350,7 @@ Where:
     can only be loaded on a processor configured with the target feature on.
 
   *Off*
-    specified by ``-``, indicating the target feature is disabled. A code
+    Specified by ``-``, indicating the target feature is disabled. A code
     object compiled with a target ID specifying a target feature off
     can only be loaded on a processor configured with the target feature off.
 
@@ -360,9 +360,9 @@ Compatibility Rules for Target ID
 ---------------------------------
 
   A code object compiled for a Target ID is considered compatible for a
-  target, if:
+  target if:
 
-  * Their processor is same.
+  * Their processor is the same.
   * Their feature set is compatible as defined above.
 
 There are two forms of target ID:
@@ -380,10 +380,10 @@ There are two forms of target ID:
   alphabetic order. Command line tools convert non-canonical form to canonical
   form.
 
-Target Specific information
+Target-Specific information
 ===========================
 
-Target specific information is available for the following:
+Target-specific information is available for the following:
 
 *AMD GPU*
   AMD GPU supports target ID and target features. See `User Guide for AMDGPU Backend
@@ -397,7 +397,7 @@ Most other targets do not support target IDs.
 Archive Unbundling
 ==================
 
-Unbundling of a heterogeneous device archive (HDA) is done to create device specific
+Unbundling of a heterogeneous device archive (HDA) is done to create device-specific
 archives. HDA is in a format compatible with GNU ``ar`` utility and contains a
 collection of bundled device binaries where each bundle file will contain
 device binaries for a host and one or more targets. The output device-specific
@@ -469,7 +469,7 @@ compatible with that particular offload target. Compatibility between a
 device binary in HDA and a target is based on the compatibility between their
 bundle entry IDs as defined in :ref:`compatibility-bundle-entry-id`.
 
-Following cases may arise during compatibility testing:
+The following cases may arise during compatibility testing:
 
 * A binary is compatible with one or more targets: Insert the binary into the
   device-specific archive of each compatible target.
@@ -517,7 +517,7 @@ Compression and Decompression
 
 ``clang-offload-bundler`` provides features to compress and decompress the full
 bundle, leveraging inherent redundancies within the bundle entries. Use the
-`-compress` command-line option to enable this compression capability.
+``-compress`` command-line option to enable this compression capability.
 
 The compressed offload bundle begins with a header followed by the compressed binary data:
 
@@ -542,4 +542,4 @@ The compressed offload bundle begins with a header followed by the compressed bi
 - **Compressed Data**:
     The actual compressed binary data follows the header. Its size can be inferred from the total size of the file minus the header size.
 
-    > **Note**: Version 3 is now the default format. For backward compatibility with older HIP runtimes that support version 2 only, set the environment variable `COMPRESSED_BUNDLE_FORMAT_VERSION=2`.
+    > **Note**: Version 3 is now the default format. For backward compatibility with older HIP runtimes that support version 2 only, set the environment variable ``COMPRESSED_BUNDLE_FORMAT_VERSION=2``.

libc/src/setjmp/x86_64/sigsetjmp.cpp

@@ -41,7 +41,7 @@ LLVM_LIBC_FUNCTION(int, sigsetjmp, (sigjmp_buf buf)) {
       [epilogue] "X"(sigsetjmp_epilogue)
       : "eax", "ebx", "ecx");
 }
-#endif
+#else
 [[gnu::naked]]
 LLVM_LIBC_FUNCTION(int, sigsetjmp, (sigjmp_buf, int)) {
   asm(R"(
@@ -64,5 +64,6 @@ LLVM_LIBC_FUNCTION(int, sigsetjmp, (sigjmp_buf, int)) {
       [epilogue] "X"(sigsetjmp_epilogue)
       : "rax", "rbx");
 }
+#endif
 
 } // namespace LIBC_NAMESPACE_DECL

llvm/docs/YamlIO.rst

@@ -807,7 +807,7 @@ Flow Mapping
 A YAML "flow mapping" is a mapping that uses the inline notation
 (e.g { x: 1, y: 0 } ) when written to YAML. To specify that a type should be
 written in YAML using flow mapping, your MappingTraits specialization should
-add "static const bool flow = true;". For instance:
+add ``static constexpr bool flow = true;``. For instance:
 
 .. code-block:: c++
 
@@ -824,7 +824,7 @@ add "static const bool flow = true;". For instance:
         ...
       }
 
-      static const bool flow = true;
+      static constexpr bool flow = true;
     }
 
 Flow mappings are subject to line wrapping according to the ``Output`` object
@@ -859,7 +859,7 @@ Flow Sequence
 A YAML "flow sequence" is a sequence that when written to YAML it uses the
 inline notation (e.g [ foo, bar ] ).  To specify that a sequence type should
 be written in YAML as a flow sequence, your SequenceTraits specialization should
-add "static const bool flow = true;".  For instance:
+add ``static constexpr bool flow = true;``.  For instance:
 
 .. code-block:: c++
 
@@ -869,7 +869,7 @@ add "static const bool flow = true;".  For instance:
     static MyListEl &element(IO &io, MyList &list, size_t index) { ... }
 
     // The existence of this member causes YAML I/O to use a flow sequence
-    static const bool flow = true;
+    static constexpr bool flow = true;
   };
 
 With the above, if you used MyList as the data type in your native data

llvm/include/llvm/Analysis/DDG.h

@@ -96,7 +96,7 @@ class RootDDGNode : public DDGNode {
   RootDDGNode() : DDGNode(NodeKind::Root) {}
   RootDDGNode(const RootDDGNode &N) = delete;
   RootDDGNode(RootDDGNode &&N) : DDGNode(std::move(N)) {}
-  ~RootDDGNode() = default;
+  ~RootDDGNode() override = default;
 
   /// Define classof to be able to use isa<>, cast<>, dyn_cast<>, etc.
   static bool classof(const DDGNode *N) {
@@ -114,7 +114,7 @@ class LLVM_ABI SimpleDDGNode : public DDGNode {
   SimpleDDGNode(Instruction &I);
   SimpleDDGNode(const SimpleDDGNode &N);
   SimpleDDGNode(SimpleDDGNode &&N);
-  ~SimpleDDGNode();
+  ~SimpleDDGNode() override;
 
   SimpleDDGNode &operator=(const SimpleDDGNode &N) = default;
 
@@ -176,7 +176,7 @@ class LLVM_ABI PiBlockDDGNode : public DDGNode {
   PiBlockDDGNode(const PiNodeList &List);
   PiBlockDDGNode(const PiBlockDDGNode &N);
   PiBlockDDGNode(PiBlockDDGNode &&N);
-  ~PiBlockDDGNode();
+  ~PiBlockDDGNode() override;
 
   PiBlockDDGNode &operator=(const PiBlockDDGNode &N) = default;
 
@@ -318,7 +318,7 @@ class LLVM_ABI DataDependenceGraph : public DDGBase, public DDGInfo {
       : DDGBase(std::move(G)), DDGInfo(std::move(G)) {}
   DataDependenceGraph(Function &F, DependenceInfo &DI);
   DataDependenceGraph(Loop &L, LoopInfo &LI, DependenceInfo &DI);
-  ~DataDependenceGraph();
+  ~DataDependenceGraph() override;
 
   /// If node \p N belongs to a pi-block return a pointer to the pi-block,
   /// otherwise return null.

llvm/include/llvm/Analysis/InteractiveModelRunner.h

@@ -51,7 +51,7 @@ class LLVM_ABI InteractiveModelRunner : public MLModelRunner {
     Log->flush();
   }
 
-  virtual ~InteractiveModelRunner();
+  ~InteractiveModelRunner() override;
 
 private:
   void *evaluateUntyped() override;

llvm/include/llvm/Analysis/MLInlineAdvisor.h

@@ -33,7 +33,7 @@ class MLInlineAdvisor : public InlineAdvisor {
                       GetModelRunner,
                   std::function<bool(CallBase &)> GetDefaultAdvice);
 
-  virtual ~MLInlineAdvisor() = default;
+  ~MLInlineAdvisor() override = default;
 
   void onPassEntry(LazyCallGraph::SCC *SCC) override;
   void onPassExit(LazyCallGraph::SCC *SCC) override;
@@ -105,7 +105,7 @@ class MLInlineAdvice : public InlineAdvice {
 public:
   MLInlineAdvice(MLInlineAdvisor *Advisor, CallBase &CB,
                  OptimizationRemarkEmitter &ORE, bool Recommendation);
-  virtual ~MLInlineAdvice() = default;
+  ~MLInlineAdvice() override = default;
 
   void recordInliningImpl() override;
   void recordInliningWithCalleeDeletedImpl() override;

llvm/include/llvm/Analysis/ReleaseModeModelRunner.h

@@ -106,7 +106,7 @@ class ReleaseModeModelRunner final : public MLModelRunner {
     assert(ResultIndex >= 0 && "Cannot find DecisionName in inlining model");
   }
 
-  virtual ~ReleaseModeModelRunner() = default;
+  ~ReleaseModeModelRunner() override = default;
 
   static bool classof(const MLModelRunner *R) {
     return R->getKind() == MLModelRunner::Kind::Release;

llvm/include/llvm/Analysis/StackSafetyAnalysis.h

@@ -156,7 +156,7 @@ class StackSafetyGlobalInfoWrapperPass : public ModulePass {
   static char ID;
 
   StackSafetyGlobalInfoWrapperPass();
-  ~StackSafetyGlobalInfoWrapperPass();
+  ~StackSafetyGlobalInfoWrapperPass() override;
 
   const StackSafetyGlobalInfo &getResult() const { return SSGI; }
 

llvm/include/llvm/DWARFCFIChecker/DWARFCFIFunctionFrameAnalyzer.h

@@ -32,7 +32,7 @@ class LLVM_ABI CFIFunctionFrameAnalyzer : public CFIFunctionFrameReceiver {
 public:
   CFIFunctionFrameAnalyzer(MCContext &Context, const MCInstrInfo &MCII)
       : CFIFunctionFrameReceiver(Context), MCII(MCII) {}
-  ~CFIFunctionFrameAnalyzer();
+  ~CFIFunctionFrameAnalyzer() override;
 
   void startFunctionFrame(bool IsEH,
                           ArrayRef<MCCFIInstruction> Prologue) override;

llvm/include/llvm/DWARFLinker/Classic/DWARFStreamer.h

@@ -48,7 +48,7 @@ class LLVM_ABI DwarfStreamer : public DwarfEmitter {
                 raw_pwrite_stream &OutFile,
                 DWARFLinkerBase::MessageHandlerTy Warning)
       : OutFile(OutFile), OutFileType(OutFileType), WarningHandler(Warning) {}
-  virtual ~DwarfStreamer() = default;
+  ~DwarfStreamer() override = default;
 
   static Expected<std::unique_ptr<DwarfStreamer>> createStreamer(
       const Triple &TheTriple, DWARFLinkerBase::OutputFileType FileType,