1. Sep 14, 2020
    • David Blaikie's avatar
    • David Blaikie's avatar
      GCOVProfiling: Avoid use-after-move · 6e06f1cd
      David Blaikie authored
      Turns out this was use-after-move of function_ref, which is trivially
      copyable and movable, so the move did nothing and use after move was
      safe.
      
      But since this function_ref is being copied into a std::function, change
      the function_ref to be std::function to avoid extra layers of type
      erasure indirection - and then it's a real use after move, and fix that
      by referring to the moved-to member variable rather than the moved-from
      parameter.
      6e06f1cd
    • Craig Topper's avatar
      [SelectionDAG] Remove default for 'unsigned' Alignment for... · 8889faae
      Craig Topper authored
      [SelectionDAG] Remove default for 'unsigned' Alignment for getLoad/getStore/getExtLoad/getTruncStore. Add default for MaybeAlign version. NFCI
      
      We want to remove the unsigned signatures eventually. This change
      migrates any that don't explicitly pass an alignment.
      8889faae
    • Raphael Isemann's avatar
      [ASTImporter] Add basic support for comparing Stmts and compare function bodies · c0bcd110
      Raphael Isemann authored
      Right now the ASTImporter assumes for most Expr nodes that they are always equal
      which leads to non-compatible declarations ending up being merged. This patch
      adds the basic framework for comparing Stmts (and with that also Exprs) and
      implements the custom checks for a few Stmt subclasses. I'll implement the
      remaining subclasses in follow up patches (mostly because there are a lot of
      subclasses and some of them require further changes like having GNU language in
      the testing framework)
      
      The motivation for this is that in LLDB we try to import libc++ source code and
      some of the types we are importing there contain expressions (e.g. because they
      use `enable_if<expr>`), so those declarations are currently merged even if they
      are completely different (e.g. `enable_if<value> ...` and `enable_if<!value>
      ...` are currently considered equal which is clearly not true).
      
      Reviewed By: martong, balazske
      
      Differential Revision: https://reviews.llvm.org/D87444
      c0bcd110
    • Qiu Chaofan's avatar
      [DAGCombiner] Propagate FMF flags in FMA folding · a4c53519
      Qiu Chaofan authored
      DAG combiner folds (fma a 1.0 b) into (fadd a b) but the flag isn't
      propagated into new fadd. This patch fixes that.
      
      Some code in visitFMA is redundant and such support for vector constants
      is missing. Need follow-up patch to clean.
      
      Reviewed By: spatel
      
      Differential Revision: https://reviews.llvm.org/D87037
      a4c53519
  2. Sep 13, 2020
  3. Sep 12, 2020
    • Simon Pilgrim's avatar
      [InstCombine][X86] Covert masked load/stores with (sign extended) bool vector... · 3170d548
      Simon Pilgrim authored
      [InstCombine][X86] Covert masked load/stores with (sign extended) bool vector masks to generic intrinsics.
      
      As detailed on PR11210, if the mask is known to come from a (sign extended) bool vector (e.g. comparisons) then we can represent with a generic masked load/store without losing anything.
      
      We already do something similar for BLENDV -> SELECT conversion.
      3170d548
    • Florian Hahn's avatar
      [Clang] Add option to allow marking pass-by-value args as noalias. · a874d633
      Florian Hahn authored
      After the recent discussion on cfe-dev 'Can indirect class parameters be
      noalias?' [1], it seems like using using noalias is problematic for
      current C++, but should be allowed for C-only code.
      
      This patch introduces a new option to let the user indicate that it is
      safe to mark indirect class parameters as noalias. Note that this also
      applies to external callers, e.g. it might not be safe to use this flag
      for C functions that are called by C++ functions.
      
      In targets that allocate indirect arguments in the called function, this
      enables more agressive optimizations with respect to memory operations
      and brings a ~1% - 2% codesize reduction for some programs.
      
      [1] : http://lists.llvm.org/pipermail/cfe-dev/2020-July/066353.html
      
      Reviewed By: rjmccall
      
      Differential Revision: https://reviews.llvm.org/D85473
      a874d633