llvm-svn: 293210

IRGen: When loading the main module in the distributed ThinLTO backend, look for the module containing the summary.

Differential Revision: https://reviews.llvm.org/D29067

llvm-svn: 293209

llvm-svn: 293208

This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.

We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.

llvm-svn: 293207

Summary: Fix the example of equivalent expansion for when mask is all ones.

Reviewers: delena

Reviewed By: delena

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D29179

llvm-svn: 293206

llvm-svn: 293205

Summary: Refine floating point SQRT and DIV with accurate latency information.

Reviewers: mcrosier

Subscribers: aemerson, rengolin, llvm-commits

Differential Revision: https://reviews.llvm.org/D29191

llvm-svn: 293204

This simplifies skipping debug instructions and shrinking ranges.

llvm-svn: 293202

Currently, os_id of the main thread contains the PID instead of a thread ID. Let's fix this.

Differential Revision: https://reviews.llvm.org/D29106

llvm-svn: 293201

1) Explicitly sets mayLoad/mayStore property in the tablegen files on load/store
   instructions.
2) Updated the flags on a number of intrinsics indicating that they write
    memory.
3) Added SDNPMemOperand flags for some target dependent SDNodes so that they
   propagate their memory operand

Review: https://reviews.llvm.org/D28818
llvm-svn: 293200

Turning on the warning by default helps the users as it's a common
mistake to capture out-parameters in a block without ensuring the object
assigned doesn't get released.

rdar://problem/30200058

llvm-svn: 293199

llvm-svn: 293198

Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:

    In file included from test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
    In file included from include/thread:97:
    In file included from include/__mutex_base:17:
    include/__threading_support:222:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
    }
    ^
    include/__threading_support:221:10: note: mutex acquired here
      return pthread_mutex_lock(__m);
             ^
    include/__threading_support:231:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
      return pthread_mutex_unlock(__m);
             ^
    include/__threading_support:242:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
    }
    ^
    include/__threading_support:241:10: note: mutex acquired here
      return pthread_mutex_lock(__m);
             ^
    include/__threading_support:251:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
      return pthread_mutex_unlock(__m);
             ^
    include/__threading_support:272:10: error: calling function 'pthread_cond_wait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
      return pthread_cond_wait(__cv, __m);
             ^
    include/__threading_support:278:10: error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
      return pthread_cond_timedwait(__cv, __m, __ts);
             ^
    6 errors generated.

This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.

Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520

llvm-svn: 293197

llvm-svn: 293196

Summary:
Hi Michal,

Would you be able to review this simple fix, please?

Since r291504 compiler-rt uses `llvm-config --cmakedir` to get the path to the LLVM CMake modules.
On Windows this option returns Windows style path with backslashes. CMake treats backslashes as beginning of an escaped character and thus fails to append the path to `CMAKE_MODULE_PATH`.

Reviewers: compnerd, mgorny

Reviewed By: mgorny

Subscribers: compnerd, llvm-commits, dberris

Differential Revision: https://reviews.llvm.org/D28908

llvm-svn: 293195

even in the presence of nullability qualifiers.

This commit fixes bugs in r285031 where -Wblock-capture-autoreleasing
wouldn't issue warnings when the function parameters were annotated
with nullability qualifiers. Specifically, look through the sugar and
see if there is an AttributedType of kind attr_objc_ownership to
determine whether __autoreleasing was explicitly specified or implicitly
added by the compiler.

rdar://problem/30193488

llvm-svn: 293194

Differential Revision: https://reviews.llvm.org/D28340

llvm-svn: 293190

This change introduces adjustPassManager target callback giving a
target an opportunity to tweak PassManagerBuilder before pass
managers are populated.

This generalizes and replaces addEarlyAsPossiblePasses target
callback. In particular that can be used to add custom passes to
extension points other than EP_EarlyAsPossible.

Differential Revision: https://reviews.llvm.org/D28336

llvm-svn: 293189

This reverts commit r293184 which is failing in LTO builds

llvm-svn: 293188

Reviewers: bkramer

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D29182

llvm-svn: 293187

[XRay][Arm32] Reduce the portion of the stub and implement more staging for tail calls - in compiler-rt

Summary:
This patch provides more staging for tail calls in XRay Arm32 . When the logging part of XRay is ready for tail calls, its support in the core part of XRay Arm32 may be as easy as changing the number passed to the handler from 1 to 2.
Coupled patch:
- https://reviews.llvm.org/D28673

Reviewers: dberris, rengolin

Reviewed By: dberris, rengolin

Subscribers: llvm-commits, iid_iunknown, aemerson

Differential Revision: https://reviews.llvm.org/D28674

llvm-svn: 293186

Summary:
This patch provides more staging for tail calls in XRay Arm32 . When the logging part of XRay is ready for tail calls, its support in the core part of XRay Arm32 may be as easy as changing the number passed to the handler from 1 to 2.
Coupled patch:
- https://reviews.llvm.org/D28674

Reviewers: dberris, rengolin

Reviewed By: dberris

Subscribers: llvm-commits, iid_iunknown, aemerson, rengolin, dberris

Differential Revision: https://reviews.llvm.org/D28673

llvm-svn: 293185

    * Simplify Consecutive Merge Store Candidate Search

    Now that address aliasing is much less conservative, push through
    simplified store merging search and chain alias analysis which only
    checks for parallel stores through the chain subgraph. This is cleaner
    as the separation of non-interfering loads/stores from the
    store-merging logic.

    When merging stores search up the chain through a single load, and
    finds all possible stores by looking down from through a load and a
    TokenFactor to all stores visited.

    This improves the quality of the output SelectionDAG and the output
    Codegen (save perhaps for some ARM cases where we correctly constructs
    wider loads, but then promotes them to float operations which appear
    but requires more expensive constant generation).

    Some minor peephole optimizations to deal with improved SubDAG shapes (listed below)

    Additional Minor Changes:

      1. Finishes removing unused AliasLoad code

      2. Unifies the chain aggregation in the merged stores across code
         paths

      3. Re-add the Store node to the worklist after calling
         SimplifyDemandedBits.

      4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is
         arbitrary, but seems sufficient to not cause regressions in
         tests.

      5. Remove Chain dependencies of Memory operations on CopyfromReg
         nodes as these are captured by data dependence

      6. Forward loads-store values through tokenfactors containing
          {CopyToReg,CopyFromReg} Values.

      7. Peephole to convert buildvector of extract_vector_elt to
         extract_subvector if possible (see
         CodeGen/AArch64/store-merge.ll)

      8. Store merging for the ARM target is restricted to 32-bit as
         some in some contexts invalid 64-bit operations are being
         generated. This can be removed once appropriate checks are
         added.

    This finishes the change Matt Arsenault started in r246307 and
    jyknight's original patch.

    Many tests required some changes as memory operations are now
    reorderable, improving load-store forwarding. One test in
    particular is worth noting:

      CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store
      forwarding converts a load-store pair into a parallel store and
      a memory-realized bitcast of the same value. However, because we
      lose the sharing of the explicit and implicit store values we
      must create another local store. A similar transformation
      happens before SelectionDAG as well.

    Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle

llvm-svn: 293184

This is a simple patch to teach OpenMP codegen to emit the construct
in Generic mode.

Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29143

llvm-svn: 293183

Summary:
For example, when we change 'na' to "nb::nc", we need to add leading '::' to
references "::nc::X" in the changed namespace.

Reviewers: bkramer

Reviewed By: bkramer

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D29176

llvm-svn: 293182

And teach shouldAssumeDSOLocal that ppc has no copy relocations.

The resulting code handle a few more case than before. For example, it
knows that a weak symbol can be resolved to another .o file, but it
will still be in the main executable.

llvm-svn: 293180

llvm-svn: 293179

llvm-svn: 293178

Should fix a few freebsd packages with dtrace.

llvm-svn: 293177

Inlining in getAddExpr() can cause abnormal computational time in some cases.
New parameter -scev-addops-inline-threshold is intruduced with default value 500.

Reviewers: sanjoy

Subscribers: mzolotukhin, llvm-commits

Differential Revision: https://reviews.llvm.org/D28812

llvm-svn: 293176

Pulled out code that removed unused inputs from a target shuffle mask into a helper function to allow it to be reused in a future commit.

llvm-svn: 293175

The '#if 0' contained the code I had intended to use but clang
rejects it (possibly incorrectly).

llvm-svn: 293174

llvm-svn: 293173

Summary:
This should make it possible to easily add everything needed to import all
the existing SelectionDAG rules. It should also serve the likely
kinds of GlobalISel rules (some of which are not currently representable
in SelectionDAG) once we've nailed down the tablegen definition for that.

The hierarchy is as follows:
  MatcherRule - A matching rule. Currently used to emit C++ ISel code but will
  |             also be used to emit test cases and tablegen definitions in the
  |             near future.
  |- Instruction(s) - Represents the instruction to be matched.
     |- Instruction Predicate(s) - Test the opcode, arithmetic flags, etc. of an
     |                             instruction.
     \- Operand(s) - Represents a particular operand of the instruction. In the
        |            future, there may be subclasses to test the same predicates
        |            on multiple operands (including for variadic instructions).
        \ Operand Predicate(s) - Test the type, register bank, etc. of an operand.
                                 This is where the ComplexPattern equivalent
                                 will be represented. It's also
                                 nested-instruction matching will live as a
                                 predicate that follows the DefUse chain to the
                                 Def and tests a MatcherRule from that position.

Support for multiple instruction matchers in a rule has been retained from
the existing code but has been adjusted to assert when it is used.
Previously it would silently drop all but the first instruction matcher.

The tablegen-erated file is not functionally changed but has more
parentheses and no longer attempts to format the if-statements since
keeping track of the indentation is tricky in the presence of the matcher
hierarchy. It would be nice to have CMakes tablegen() run the output
through clang-format (when available) so we don't have to complicate
TableGen with pretty-printing.

It's also worth mentioning that this hierarchy will also be able to emit
TableGen definitions and test cases in the near future. This is the reason
for favouring explicit emit*() calls rather than the << operator.

Reviewers: aditya_nandakumar, rovka, t.p.northover, qcolombet, ab

Reviewed By: ab

Subscribers: igorb, dberris, kristof.beyls, llvm-commits

Differential Revision: https://reviews.llvm.org/D28942

llvm-svn: 293172

Differential revision: https://reviews.llvm.org/D28980

llvm-svn: 293171

This reverts commit r293164. There are multiple tests failing.

llvm-svn: 293170

Before this change the user only saw "Unspecified Error", when a region
contained the entry block. Now we report:

"Scop contains function entry (not yet supported)."

llvm-svn: 293169

change the set of uniform instructions in the loop causing an assert
failure.

The problem is that the legalization checking also builds data
structures mapping various facts about the loop body. The immediate
cause was the set of uniform instructions. If these then change when
LCSSA is formed, the data structures would already have been built and
become stale. The included test case triggered an assert in loop
vectorize that was reduced out of the new PM's pipeline.

The solution is to form LCSSA early enough that no information is cached
across the changes made. The only really obvious position is outside of
the main logic to vectorize the loop. This also has the advantage of
removing one case where forming LCSSA could mutate the loop but we
wouldn't track that as a "Changed" state.

If it is significantly advantageous to do some legalization checking
prior to this, we can do a more careful positioning but it seemed best
to just back off to a safe position first.

llvm-svn: 293168

Remove the reference to pthread_mach_thread_np() in libcxx headers.

llvm-svn: 293167

Pull the dependency on pthread_mach_thread_np() back into libcxxabi.

llvm-svn: 293166