This allows for nicer backtrace and debugging when -j1 is passed:

  $ opt-viewer.py CMakeFiles/LLVMScalarOpts.dir/LoopVersioningLICM.cpp.opt.yaml html
  Traceback (most recent call last):
    File "/org/llvm/utils/opt-viewer/opt-viewer.py", line 405, in <module>
      generate_report(pmap, all_remarks, file_remarks, args.source_dir, args.output_dir)
    File "/org/llvm/utils/opt-viewer/opt-viewer.py", line 362, in generate_report
      pmap(_render_file_bound, file_remarks.items())
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 251, in map
      return self.map_async(func, iterable, chunksize).get()
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 567, in get
      raise self._value
  Exception: blah

  $ opt-viewer.py -j 1 CMakeFiles/LLVMScalarOpts.dir/LoopVersioningLICM.cpp.opt.yaml html
  Traceback (most recent call last):
    File "/org/llvm/utils/opt-viewer/opt-viewer.py", line 405, in <module>
      generate_report(pmap, all_remarks, file_remarks, args.source_dir, args.output_dir)
    File "/org/llvm/utils/opt-viewer/opt-viewer.py", line 362, in generate_report
      pmap(_render_file_bound, file_remarks.items())
    File "/org/llvm/utils/opt-viewer/opt-viewer.py", line 317, in _render_file
      SourceFileRenderer(source_dir, output_dir, filename).render(remarks)
    File "/org/llvm/utils/opt-viewer/opt-viewer.py", line 168, in __init__
      raise Exception("blah")
  Exception: blah

llvm-svn: 295080

llvm-svn: 295078

Summary:
As written in the comments above, LastCallToStaticBonus is already applied to
the cost if Caller has only one user, so it is redundant to reapply the bonus
here.

If the only user is not a caller, TotalSecondaryCost will not be adjusted
anyway because callerWillBeRemoved is false. If there's no caller at all, we
don't need to care about TotalSecondaryCost because
inliningPreventsSomeOuterInline is false.

Reviewers: chandlerc, eraman

Reviewed By: eraman

Subscribers: haicheng, davidxl, davide, llvm-commits, mehdi_amini

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

llvm-svn: 295075

llvm-svn: 295073

And use it in MachineOptimizationRemarkEmitter.  A test will follow on top of
Justin's changes to enable MachineORE in AsmPrinter.

The approach is similar to the IR-level pass.  It's a bit simpler because BPI
is immutable at the Machine level so we don't need to make that lazy.

Because of this, a new function mapping is introduced (BPIPassTrait::getBPI).
This function extracts BPI from the pass.  In case of the lazy pass, this is
when the calculation of the BFI occurs.  For Machine-level, this is the
identity function.

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

llvm-svn: 295072

This will be used by the LazyMachineBFI pass.

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

llvm-svn: 295071

llvm-svn: 295068

llvm-svn: 295066

llvm-svn: 295065

Summary:
This is achieved by generalizing the expression selecting the StringRef
format_provider. Now, anything that can be converted to a StringRef will
use it's formatter.

Reviewers: zturner

Subscribers: llvm-commits

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

llvm-svn: 295064

This reapplies commit r294967 with a fix for the execution time regressions
caught by the clang-cmake-aarch64-quick bot. We now extend the truncate
optimization to non-primary induction variables only if the truncate isn't
already free.

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

llvm-svn: 295063

Add support for specifying an UNPCK input as UNDEF

llvm-svn: 295061

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

llvm-svn: 295060

Not correctly using UNDEF or ZERO inputs to combine to UNPCK shuffles

llvm-svn: 295059

Remove excess semicolons

llvm-svn: 295058

back into a vector

Previously the cost of the existing ExtractElement/ExtractValue
instructions was considered as a dead cost only if it was detected that
they have only one use. But these instructions may be considered
dead also if users of the instructions are also going to be vectorized,
like:
```
%x0 = extractelement <2 x float> %x, i32 0
%x1 = extractelement <2 x float> %x, i32 1
%x0x0 = fmul float %x0, %x0
%x1x1 = fmul float %x1, %x1
%add = fadd float %x0x0, %x1x1
```
This can be transformed to
```
%1 = fmul <2 x float> %x, %x
%2 = extractelement <2 x float> %1, i32 0
%3 = extractelement <2 x float> %1, i32 1
%add = fadd float %2, %3
```
because though `%x0` and `%x1` have 2 users each other, these users are
part of the vectorized tree and we can consider these `extractelement`
instructions as dead.

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

llvm-svn: 295056

llvm-svn: 295055

This reverts commit ce06d9cb99298eb844b66e117f5108a06747c907.

llvm-svn: 295054

llvm-svn: 295053

Don't bother setting the V1/V2 operands again for unary shuffles.

Don't bother legalizing the value type unless the match succeeds.

llvm-svn: 295051

llvm-svn: 295050

It also shows an unnecessary pshufb/broadcast being used - the original pshufb mask only requested the lowest byte.

llvm-svn: 295046

This reverts r295038. The buildbot clang-with-thin-lto-ubuntu failed.
I'm reverting to investigate.

llvm-svn: 295042

Prevent memory objects of different address spaces to be part of
the same load/store groups when analysing interleaved accesses.

This is fixing pr31900.

Reviewers: HaoLiu, mssimpso, mkuper

Reviewed By: mssimpso, mkuper

Subscribers: llvm-commits, efriedma, mzolotukhin

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

llvm-svn: 295038

Removing whitespace.

llvm-svn: 295037

llvm-svn: 295036

llvm-svn: 295035

Summary:
Function isCompatibleIVType is already used as a guard before the call to

 SE.getMinusSCEV(OperExpr, PrevExpr);

in LSRInstance::ChainInstruction. getMinusSCEV requires the expressions
to be of the same type, so we now consider two pointers with different
address spaces to be incompatible, since it is possible that the pointers
in fact have different sizes.

Reviewers: qcolombet, eli.friedman

Reviewed By: qcolombet

Subscribers: nhaehnle, Ka-Ka, llvm-commits, mzolotukhin

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

llvm-svn: 295033

Launch policies provided a mechanism for running RPC handlers on a background
thread (unblocking the main RPC receiver thread). Async handlers generalize
this by passing the responder function (the function that sends the RPC return
value) as an argument to the handler. The handler can optionally do its work on
a background thread (the same way launch policies do), but can also (a) can
inspect the call arguments before deciding to run the work on a different
thread, or (b) can use the responder in a subsequent RPC call (e.g. in the
handler of a callAsync), allowing the handler to call back to the originator (or
to a 3rd party) without blocking the listener thread, and without launching a
new thread.

llvm-svn: 295030

llvm-svn: 295028

llvm-svn: 295027

Also, for better uniformity use TargetRegistry::RegisterMCAsmInfo rather than 
RegisterMCAsmInfoFn. Again, no functional change.

llvm-svn: 295026

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

llvm-svn: 295021

We can't assume that the `const char *` provided through libLTO has a
lifetime that expands beyond the codegenerator itself.

llvm-svn: 295018

Extend our store promotion code to deal with unordered atomic accesses. Ordered atomics continue to be unhandled.

Most of the change is straight-forward, the only complicated bit is in the reasoning around mixing of atomic and non-atomic memory access. Rather than trying to reason about the complex semantics in these cases, I simply disallowed promotion when both atomic and non-atomic accesses are present. This is conservatively correct.

It seems really tempting to just promote all access to atomics, but the original accesses might have been conditional. Since we can't lower an arbitrary atomic type, it might not be safe to promote all access to atomic. Consider a loop like the following:
while(b) {
  load i128 ...
  if (can lower i128 atomic)
    store atomic i128 ...
  else
    store i128
}

It could be there's no race on the location and thus the code is perfectly well defined even if we can't lower a i128 atomically. 

It's not clear we need to be this conservative - arguably the program above is brocken since it can't be lowered unless the branch is folded - but I didn't want to have to fix any fallout which might result.

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

llvm-svn: 295015

llvm-svn: 295014

Previously we could not use it because std::once_flag's default
constructor was not constexpr. Today, all supported versions of VS
correctly mark it constexpr. I confirmed that MSVC 2015 does not emit
any problematic racy dynamic initialization code, so we should be safe
to use this now.

llvm-svn: 295013

Same changes in files affected by reduced MC headers dependencies.

llvm-svn: 295009

FunctionAttrs: Factor out a function for querying memory access of a specific copy of a function. NFC.

This will later be used by ThinLTOBitcodeWriter to add copies of readnone
functions to the regular LTO module.

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

llvm-svn: 295008

llvm-svn: 295005