Skip to content
  1. Dec 17, 2020
    • dfukalov's avatar
      [NFC] Reduce include files dependency and AA header cleanup (part 2). · 9ed8e0ca
      dfukalov authored
      Continuing work started in https://reviews.llvm.org/D92489:
      
      Removed a bunch of includes from "AliasAnalysis.h" and "LoopPassManager.h".
      
      Reviewed By: RKSimon
      
      Differential Revision: https://reviews.llvm.org/D92852
      9ed8e0ca
    • Barry Revzin's avatar
      Make LLVM build in C++20 mode · 92310454
      Barry Revzin authored
      Part of the <=> changes in C++20 make certain patterns of writing equality
      operators ambiguous with themselves (sorry!).
      This patch goes through and adjusts all the comparison operators such that
      they should work in both C++17 and C++20 modes. It also makes two other small
      C++20-specific changes (adding a constructor to a type that cases to be an
      aggregate, and adding casts from u8 literals which no longer have type
      const char*).
      
      There were four categories of errors that this review fixes.
      Here are canonical examples of them, ordered from most to least common:
      
      // 1) Missing const
      namespace missing_const {
          struct A {
          #ifndef FIXED
              bool operator==(A const&);
          #else
              bool operator==(A const&) const;
          #endif
          };
      
          bool a = A{} == A{}; // error
      }
      
      // 2) Type mismatch on CRTP
      namespace crtp_mismatch {
          template <typename Derived>
          struct Base {
          #ifndef FIXED
              bool operator==(Derived const&) const;
          #else
              // in one case changed to taking Base const&
              friend bool operator==(Derived const&, Derived const&);
          #endif
          };
      
          struct D : Base<D> { };
      
          bool b = D{} == D{}; // error
      }
      
      // 3) iterator/const_iterator with only mixed comparison
      namespace iter_const_iter {
          template <bool Const>
          struct iterator {
              using const_iterator = iterator<true>;
      
              iterator();
      
              template <bool B, std::enable_if_t<(Const && !B), int> = 0>
              iterator(iterator<B> const&);
      
          #ifndef FIXED
              bool operator==(const_iterator const&) const;
          #else
              friend bool operator==(iterator const&, iterator const&);
          #endif
          };
      
          bool c = iterator<false>{} == iterator<false>{} // error
                || iterator<false>{} == iterator<true>{}
                || iterator<true>{} == iterator<false>{}
                || iterator<true>{} == iterator<true>{};
      }
      
      // 4) Same-type comparison but only have mixed-type operator
      namespace ambiguous_choice {
          enum Color { Red };
      
          struct C {
              C();
              C(Color);
              operator Color() const;
              bool operator==(Color) const;
              friend bool operator==(C, C);
          };
      
          bool c = C{} == C{}; // error
          bool d = C{} == Red;
      }
      
      Differential revision: https://reviews.llvm.org/D78938
      92310454
    • Florian Hahn's avatar
      [InstCombine] Preserve !annotation for newly created instructions. · eba09a2d
      Florian Hahn authored
      When replacing an instruction with !annotation with a newly created
      replacement, add the !annotation metadata to the replacement.
      
      This mostly covers cases where the new instructions are created using
      the ::Create helpers. Instructions created by IRBuilder will be handled
      by D91444.
      
      Reviewed By: thegameg
      
      Differential Revision: https://reviews.llvm.org/D93399
      eba09a2d
    • Kazu Hirata's avatar
      [GCN] Remove unused function handleNewInstruction (NFC) · 4ad5b634
      Kazu Hirata authored
      The function was added without a user on Dec 22, 2016 in commit
      7e274e02.  It seems to be unused since
      then.
      4ad5b634
    • Hongtao Yu's avatar
      [CSSPGO] Consume pseudo-probe-based AutoFDO profile · ac068e01
      Hongtao Yu authored
      This change enables pseudo-probe-based sample counts to be consumed by the sample profile loader under the regular `-fprofile-sample-use` switch with minimal adjustments to the existing sample file formats. After the counts are imported, a probe helper, aka, a `PseudoProbeManager` object, is automatically launched to verify the CFG checksum of every function in the current compilation against the corresponding checksum from the profile. Mismatched checksums will cause a function profile to be slipped. A `SampleProfileProber` pass is scheduled before any of the `SampleProfileLoader` instances so that the CFG checksums as well as probe mappings are available during the profile loading time. The `PseudoProbeManager` object is set up right after the profile reading is done. In the future a CFG-based fuzzy matching could be done in `PseudoProbeManager`.
      
      Samples will be applied only to pseudo probe instructions as well as probed callsites once the checksum verification goes through. Those instructions are processed in the same way that regular instructions would be processed in the line-number-based scenario. In other words, a function is processed in a regular way as if it was reduced to just containing pseudo probes (block probes and callsites).
      
      **Adjustment to profile format **
      
      A CFG checksum field is being added to the existing AutoFDO profile formats. So far only the text format and the extended binary format are supported. For the text format, a new line like
      ```
      !CFGChecksum: 12345
      ```
      is added to the end of the body sample lines. For the extended binary profile format, we introduce a metadata section to store the checksum map from function names to their CFG checksums.
      
      Differential Revision: https://reviews.llvm.org/D92347
      ac068e01
    • alex-t's avatar
      Disable Jump Threading for the targets with divergent control flow · 35ec3ff7
      alex-t authored
      Details: Jump Threading does not make sense for the targets with divergent CF
               since they do not use branch prediction for speculative execution.
               Also in the high level IR there is no enough information to conclude that the branch is divergent or uniform.
               This may cause errors in further CF lowering.
      
      Reviewed By: rampitec
      
      Differential Revision: https://reviews.llvm.org/D93302
      35ec3ff7
  2. Dec 16, 2020
  3. Dec 15, 2020
  4. Dec 14, 2020
Loading