1. Jan 16, 2020
    • Benjamin Kramer's avatar
      Revert "[mlir] Create a gpu.module operation for the GPU Dialect." · 0133cc60
      Benjamin Kramer authored
      This reverts commit 4624a1e8. Causing
      problems downstream.
      0133cc60
    • Teresa Johnson's avatar
      Fix bot by adjusting wildcard matching · 76b92cc7
      Teresa Johnson authored
      I noticed one bot failure due to
      24a00ef2 because the wildcard matching
      was not working as intended, fixed it to act similar to other checks of
      CGSCCToFunctionPassAdaptor.
      76b92cc7
    • evgeny's avatar
      [ThinLTO] Always import constants · 10cadee5
      evgeny authored
      This patch imports constant variables even when they can't be internalized
      (which results in promotion). This offers some extra constant folding
      opportunities.
      
      Differential revision: https://reviews.llvm.org/D70404
      10cadee5
    • Arkady Shlykov's avatar
      [Loop Peeling] Add possibility to enable peeling on loop nests. · 3f3017e1
      Arkady Shlykov authored
      Summary:
      Current peeling implementation bails out in case of loop nests.
      The patch introduces a field in TargetTransformInfo structure that
      certain targets can use to relax the constraints if it's
      profitable (disabled by default).
      Also additional option is added to enable peeling manually for
      experimenting and testing purposes.
      
      Reviewers: fhahn, lebedev.ri, xbolva00
      
      Reviewed By: xbolva00
      
      Subscribers: xbolva00, hiraditya, zzheng, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D70304
      3f3017e1
    • Sanjay Patel's avatar
      [InstCombine] reassociate fsub+fsub into fsub+fadd · 3180af43
      Sanjay Patel authored
      As discussed in the motivating PR44509:
      https://bugs.llvm.org/show_bug.cgi?id=44509
      
      ...we can end up with worse code using fast-math than without.
      This is because the reassociate pass greedily transforms fsub
      into fneg/fadd and apparently (based on the regression tests
      seen here) expects instcombine to clean that up if it wasn't
      profitable. But we were missing this fold:
      
      (X - Y) - Z --> X - (Y + Z)
      
      There's another, more specific case that I think we should
      handle as shown in the "fake" fneg test (but missed with a real
      fneg), but that's another patch. That may be tricky to get
      right without conflicting with existing transforms for fneg.
      
      Differential Revision: https://reviews.llvm.org/D72521
      3180af43
    • Nicolas Vasilache's avatar
      88380b91
    • Nicolas Vasilache's avatar
      [mlir][Linalg] NFC - Cleanup Linalg Pass locations and namespacing · 7741de94
      Nicolas Vasilache authored
      Summary:
      This diff moves the conversion pass declaration closer to its definition
      and makes the namespacing of passes consistent with the rest of the
      infrastructure (i.e. `mlir::linalg::createXXXPass` -> `mlir::createXXXPass`).
      
      Reviewers: ftynse, jpienaar, mehdi_amini
      
      Subscribers: rriddle, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, llvm-commits
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D72766
      7741de94
    • Lang Hames's avatar
      [ORC] Simplify use of lazyReexports with LLJIT. · e9e26c01
      Lang Hames authored
      This patch makes the target triple available via the LLJIT interface, and moves
      the IRTransformLayer from LLLazyJIT down into LLJIT. Together these changes make
      it easier to use the lazyReexports utility with LLJIT, and to apply IR
      transforms to code as it is compiled in LLJIT (rather than requiring transforms
      to be applied manually before code is added). An code example is added in
      llvm/examples/LLJITExamples/LLJITWithLazyReexports
      e9e26c01
    • Lang Hames's avatar
      [ORC] Update lazyReexports to support aliases with different symbol names. · d2fabd70
      Lang Hames authored
      A bug in the existing implementation meant that lazyReexports would not work if
      the aliased name differed from the alias's name, i.e. all lazy reexports had to
      be of the form (lib1, name) -> (lib2, name). This patch fixes the issue by
      capturing the alias's name in the NotifyResolved callback. To simplify this
      capture, and the LazyCallThroughManager code in general, the NotifyResolved
      callback is updated to use llvm::unique_function rather than a custom class.
      
      No test case yet: This can only be tested at runtime, and the only in-tree
      client (lli) always uses aliases with matching names. I will add a new LLJIT
      example shortly that will directly test the lazyReexports API and the
      non-trivial alias use case.
      d2fabd70
  2. Jan 15, 2020