As discussed on D19198 - we need to check what happens when we shuffle with different value type to the load

llvm-svn: 269068

Summary:
Add support for emission of plaintext lists of the imported files for
each distributed backend compilation. Used for distributed build file
staging.

Invoked with new gold-plugin thinlto-emit-imports-files option, which is
only valid with thinlto-index-only (i.e. for distributed builds), or
from llvm-lto with new -thinlto-action=emitimports value.

Depends on D19556.

Reviewers: joker.eph

Subscribers: llvm-commits, joker.eph

Differential Revision: http://reviews.llvm.org/D19636

llvm-svn: 269067

Seems like my sphynx version is different than the one in the bot, as it
accepted everything locally. I think this is the right fix...

llvm-svn: 269062

This restores commit r268627:
    Summary:
    When launching ThinLTO backends in a distributed build (currently
    supported in gold via the thinlto-index-only plugin option), emit
    an individual index file for each backend process as described here:
    http://lists.llvm.org/pipermail/llvm-dev/2016-April/098272.html

    ...

    Differential Revision: http://reviews.llvm.org/D19556

Address msan failures by avoiding std::prev on map.end(), the
theory is that this is causing issues due to some known UB problems
in __tree.

llvm-svn: 269059

HowToCrossCompile was outdated and generating too much traffic on the mailing
list with similar queries. This change helps offset most of the problems that
were reported recently including:

 * Removing the -ccc-gcc-name, adding --sysroot
 * Making references to Debian's multiarch for target libraries
 * Expanding -DCMAKE_CXX_FLAGS for both GCC and Clang
 * Some formatting and clarifications in the text

llvm-svn: 269054

This removes a redundant stride versioning step (we already
do it in getPtrStride, so it has no effect) and uses PSE to
get the SCEV expressions for the source and destination
(this might have changed when getPtrStride was called).

I discovered this through code inspection, and couldn't
produce a regression test for it.

llvm-svn: 269052

This was a fairly simple patch but on closer inspection was seriously flawed and caused PR27690.

This reverts commit r268921.

llvm-svn: 269051

Following post-commit comments on r268900 from Rafael Espindola:
The missing relocations are now explicitly listed in the switch statement with
appropriate FIXME comments and the default path is now unreachable. The
temporary exception to this is that compound relocations for N64 still have a
default path that returns true. This is because fixing that case ought to be a
separate patch.

Also make R_MIPS_NONE return false since it has no effect on the section data.

llvm-svn: 269047

Differential Revision: http://reviews.llvm.org/D19828

llvm-svn: 269040

llvm-svn: 269038

Loop rotation clones instruction from the old header into the preheader. If
there were uses of values produced by these instructions that were outside
the loop, we have to insert PHI nodes to merge the two values. If the values
are used by DbgIntrinsics they will be used as a MetadataAsValue of a
ValueAsMetadata of the original values, and iterating all of the uses of the
original value will not update the DbgIntrinsics. The new code checks if the
values are used by DbgIntrinsics and if so, updates them using essentially
the same logic as the original code.

The attached testcase demonstrates the issue. Without the fix, the
DbgIntrinic outside the loop uses values computed inside the loop, even
though these values do not dominate the DbgIntrinsic.

Author: Thomas Jablin (tjablin)
Reviewers: dblaikie aprantl kbarton hfinkel cycheng

http://reviews.llvm.org/D19564

llvm-svn: 269034

When a va_start or va_copy is immediately followed by a va_end (ignoring
debug information or other start/end in between), then it is safe to
remove the pair. As this code shares some commonalities with the lifetime
markers, this has been factored to helper functions.

This InstCombine pattern kicks-in 3 times when running the LLVM test
suite.

llvm-svn: 269033

Added test to check LeonItineraries are being applied by code checked-in two weeks ago in r267121.

Phabricator Review: http://reviews.llvm.org/D19359

llvm-svn: 269032

Subscribers: llvm-commits, hfinkel

Differential Revision: http://reviews.llvm.org/D16464

llvm-svn: 269031

Revert "[PGO] Fix __llvm_profile_raw_version linkage in MACHO IR instrumentation generates a COMDAT symbol __llvm_profile_raw_version to overwrite the same symbol in profile run-time to distinguish IR profiles from Clang generated profiles. In MACHO, LinkOnceODR linkage is used due to the lack of COMDAT support."

This reverts commits r268969, r268979 and r268984. They had target specific test
in generic directories without the correct specifiers and made it hard for us to
come up with a good solution by rapidly committing untested changes.

This test needs to be in a target specific directory or have the correct REQUIRED
identifier.

llvm-svn: 269027

SystemZ (and probably other targets as well) can fold a memory operand
by changing the opcode into a new instruction that as a side-effect
also clobbers the CC-reg.

In order to do this, liveness of that reg must first be checked. When
LIS is passed, getRegUnit() can be called on it and the right
LiveRange is computed on demand.

Reviewed by Matthias Braun.
http://reviews.llvm.org/D19861

llvm-svn: 269026

Allow vectorization when the step is a loop-invariant variable.
This is the loop example that is getting vectorized after the patch:

 int int_inc;
 int bar(int init, int *restrict A, int N) {

  int x = init;
  for (int i=0;i<N;i++){
    A[i] = x;
    x += int_inc;
  }
  return x;
 }

"x" is an induction variable with *loop-invariant* step.
But it is not a primary induction. Primary induction variable with non-constant step is not handled yet.

Differential Revision: http://reviews.llvm.org/D19258

llvm-svn: 269023

Changing misleading function name was approved in http://reviews.llvm.org/D17268.
Patch by Roman Shirokiy.

llvm-svn: 269021

llvm-svn: 269020

[X86][AVX512] Strengthen the assertions from r269001. We need VLX to use the 128/256-bit move opcodes for extended registers.

llvm-svn: 269019

llvm-svn: 269018

[X86] Update X86_INTR calling convention to save ZMM registers instead of YMM registers when AVX512 is enabled.

llvm-svn: 269017

We now use LiveRangeCalc::extendToUses() instead of a specially designed
algorithm in constructMainRangeFromSubranges():
- The original motivation for constructMainRangeFromSubranges() were
  differences between the main liverange and subranges because of hidden
  dead definitions. This case however cannot happen anymore with the
  DetectDeadLaneMasks pass in place.
- It simplifies the code.
- This fixes a longstanding bug where we did not properly create new SSA
  values on merging control flow (the MachineVerifier missed most of
  these cases).
- Move constructMainRangeFromSubranges() to LiveIntervalAnalysis and
  LiveRangeCalc to better match the implementation/available helper
  functions.

llvm-svn: 269016

llvm-svn: 269015

In -run-pass mode verify/print machine function immediately after
loading the .mir file if -verify-machineinstr/-print-machineinstrs
option is specified.

llvm-svn: 269014

llvm-svn: 269013

Move the register stackification and coloring passes to run very late, after
PEI, tail duplication, and most other passes. This means that all code emitted
and expanded by those passes is now exposed to these passes. This also
eliminates the need for prologue/epilogue code to be manually stackified,
which significantly simplifies the code.

This does require running LiveIntervals a second time. It's useful to think
of these late passes not as late optimization passes, but as a domain-specific
compression algorithm based on knowledge of liveness information. It's used to
compress the code after all conventional optimizations are complete, which is
why it uses LiveIntervals at a phase when actual optimization passes don't
typically need it.

Differential Revision: http://reviews.llvm.org/D20075

llvm-svn: 269012

Many files include Passes.h but only a fraction needs to know about the
TargetPassConfig class. Move it into an own header. Also rename
Passes.cpp to TargetPassConfig.cpp while we are at it.

llvm-svn: 269011

llvm-svn: 269010

Apply a similar fix to the one in r269006 to LiveIntervalTest.cpp.

llvm-svn: 269009

Reviewers: apilipenko, majnemer, reames

Subscribers: mcrosier, llvm-commits

Differential Revision: http://reviews.llvm.org/D20044

llvm-svn: 269008

Summary:
The idea is very close to what we do for assume intrinsics: we mark the
guard intrinsics as writing to arbitrary memory to maintain control
dependence, but under the covers we teach AA that they do not mod any
particular memory location.

Reviewers: chandlerc, hfinkel, gbiv, reames

Subscribers: george.burgess.iv, mcrosier, llvm-commits

Differential Revision: http://reviews.llvm.org/D19575

llvm-svn: 269007

Looks like you need the complete definition of "X" when calling a "X
&func()" declared function even when not using the result further.

llvm-svn: 269006

We now construct a custom pass pipeline instead of injecting
start-before/stop-after into the default pipeline construction. This
allows to specify any pass known to the pass registry. Previously
specifying indirectly added analysis passes or passes not added to the
pipeline add all would not be added and we would silently do nothing.

This also restricts the -run-pass option to cases with .mir input.

llvm-svn: 269003

Add convenience function to create MachineModuleInfo and
MachineFunctionAnalysis passes and add them to a pass manager.

Despite factoring out some shared code in
LiveIntervalTest/LLVMTargetMachine this will be used by my upcoming llc
change.

llvm-svn: 269002

When loading or storing AVX512 registers we were not using the AVX512
variant of the load and store for VR128 and VR256 like registers.
Thus, we ended up with the wrong encoding and actually were dropping the
high bits of the instruction. The result was that we load or store the
wrong register. The effect is visible only when we emit the object file
directly and disassemble it. Then, the output of the disassembler does
not match the assembly input.

This is related to llvm.org/PR27481.

llvm-svn: 269001

llvm-svn: 268999

The boolean expressions are somewhat hard to read otherwise.

llvm-svn: 268998

We can use calls to @llvm.experimental.guard to prove predicates,
relying on the fact that in all locations domianted by a call to
@llvm.experimental.guard the predicate it is guarding is known to be
true.

llvm-svn: 268997

Summary:
Previously these intrinsics were marked as can-read any memory address.
Now they're marked as reading only the pointer they're passed.

Reviewers: rnk

Subscribers: jholewinski, llvm-commits, tra

Differential Revision: http://reviews.llvm.org/D20080

llvm-svn: 268996