LLD still does not produce a correct combination of MIPS ELF flags if
input files have different sets of ELF flags (i.e. EF_MIPS_ARCH_32 and
EF_MIPS_ARCH_32R2). But now we do not stick to "R2" ABI version and can
emit EF_MIPS_ARCH_32R6 for example.

llvm-svn: 276172

Summary:
Previously we wouldn't move loads/stores across instructions that had
side-effects, where that was defined as may-write or may-throw.  But
this is not sufficiently restrictive: Stores can't safely be moved
across instructions that may load.

This patch also adds a DEBUG check that all instructions in our chain
are either loads or stores.

Reviewers: asbirlea

Subscribers: llvm-commits, jholewinski, arsenm, mzolotukhin

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

llvm-svn: 276171

Summary:
Previously if we had a chain that contained a side-effecting
instruction, we wouldn't vectorize it at all.  Now we'll vectorize
everything that comes before the side-effecting instruction.

Reviewers: asbirlea

Subscribers: arsenm, jholewinski, llvm-commits, mzolotukhin

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

llvm-svn: 276170

A seemingly common use for the walker's getClobberingMemoryAccess
function is:

```
MemoryAccess *getClobber(MemorySSAWalker *W, MemoryUseOrDef *MUD) {
  const Instruction *I = MUD->getMemoryInst();
  return W->getClobberingMemoryAccess(I);
}
```

Which is kind of redundant, since walkers will ultimately query MSSA to
find out which MemoryAccess `I` maps to (...which is always `MUD`).

So, this patch adds an overload of getClobberingMemoryAccess that
accepts MemoryAccesses directly. As a result, the Instruction overload
of getClobberingMemoryAccess becomes a lightweight wrapper around our
new overload.

Additionally, this patch un`virtual`izes the Instruction overload of
getClobberingMemoryAccess, since there doesn't seem to be a walker that
benefits from that being virtual, and I can't think of how else one
would implement it. Happy to make it virtual again if we would benefit
from doing so.

llvm-svn: 276169

Summary: Lists can be written either with "-" or "[]" in YAML.

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

llvm-svn: 276168

Clang misdiagnoses atomic captures cases that contains parens.
i.e.

  int v, int *p;
#pragma omp atomic capture
{ v = (*p); (*p)++; }

Patch by David S.

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

llvm-svn: 276167

llvm-svn: 276166

llvm-svn: 276165

This way is consistent with createSections.

llvm-svn: 276164

llvm-svn: 276163

llvm-svn: 276162

Allows AMDGCN target to generate images (such as %opencl.image2d_t) in constant address space.
Images will still be generated in global address space by default.

Added tests to existing opencl-types.cl in test\CodeGenOpenCL.

Patch by Aaron En Ye Shi.

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

llvm-svn: 276161

We can't guard the include of LowLevelType.h because getType and setType are
(trivial) functions even when GlobalISel isn't built.

llvm-svn: 276160

we first touch any part of that module. Instead, defer them until the first
time that module is (transitively) imported. The initializer step for a module
then recursively initializes modules that its own headers imported.

For example, this avoids running the <iostream> global initializer in programs
that don't actually use iostreams, but do use other parts of the standard
library.

llvm-svn: 276159

This should be all the low-level instruction selection needs to determine how
to implement an operation, with the remaining context taken from the opcode
(e.g. G_ADD vs G_FADD) or other flags not based on type (e.g. fast-math).

llvm-svn: 276158

llvm-svn: 276157

llvm-svn: 276156

but things happened to work on some platforms prior to r276133. This
should be the complete set (I hope).

llvm-svn: 276155

Fixes a crash in llvm_unreachable when a function has array return type.

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

llvm-svn: 276154

Avoid unnecessary spills of byval arguments of device functions to
local space on SASS level and subsequent pointer conversion to generic
address space that follows. Instead, make a local copy in IR, provide
a way to access arguments directly, and let LLVM optimize the copy away
when possible.

Differential Review: https://reviews.llvm.org/D21421

llvm-svn: 276153

llvm-svn: 276152

Summary:
A sysroot without c++ headers is able to build compiler-rt, don't
require them when configuring available architectures from cmake.

Reviewers: samsonov, beanz, compnerd

Subscribers: llvm-commits

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

llvm-svn: 276151

Function is not passed unlike in the original of this
(llvm::emitOptimizationRemarkMissed).

llvm-svn: 276150

Summary:
Mirroring most cleanup changed from compiler-rt/lib/builtins/cpu_model.
x86 methods are still returning a bool.

Reviewers: llvm-commits, echristo, craig.topper, sanjoy

Subscribers: mehdi_amini

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

llvm-svn: 276149

Summary:
Use stricter comparisons for architecture. This prevents cmake from failing
for sysroots which can only compile armhf and not arm, since
arm MATCHES armhf is true, while arm STREQUAL armhf is false.

Reviewers: beanz, compnerd

Subscribers: aemerson, llvm-commits

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

llvm-svn: 276148

llvm-svn: 276147

We will need to do something like this to support range extension
thunks since that process is iterative.

Doing this also has the advantage that when doing the regular
relocation scan the offset in the output section is known and we can
just store that. This reduces the number of times we have to run
getOffset and I think will allow a more specialized .eh_frame
representation.

By itself this is already a performance win.

firefox
  master 7.295045737
  patch  7.209466989 0.98826892235
chromium
  master 4.531254468
  patch  4.509221804 0.995137623774
chromium fast
  master 1.836928973
  patch  1.823805241 0.992855612714
the gold plugin
  master 0.379768791
  patch  0.380043405 1.00072310839
clang
  master 0.642698284
  patch  0.642215663 0.999249070657
llvm-as
  master 0.036665467
  patch  0.036456225 0.994293213284
the gold plugin fsds
  master 0.40395817
  patch  0.404384555 1.0010555177
clang fsds
  master 0.722045545
  patch  0.720946135 0.998477367518
llvm-as fsds
  master 0.03292646
  patch  0.032759965 0.994943428477
scylla
  master 3.427376378
  patch  3.368316181 0.98276810292

llvm-svn: 276146

Summary:
The format style is set to LLVM. This is consistent with the
parallel-libs project charter which specifies that its libraries will
conform to LLVM coding style.

Reviewers: jlebar

Subscribers: parallel_libs-commits

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

llvm-svn: 276145

Thanks to George Rimar for finding the problem.

llvm-svn: 276144

llvm-svn: 276143

llvm-svn: 276142

This patch simplifies output section management by making
Factory class have ownership of sections that creates.

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

llvm-svn: 276141

As noted in https://reviews.llvm.org/D22537 , we can use this functionality in 
visitSelectInstWithICmp() and InstSimplify, but currently we have duplicated
code.

llvm-svn: 276140

The content in this testcase was accidentally duplicated. Fix the error.

llvm-svn: 276139

This update resolves a bug in computing lexicographic minima/maxima.

llvm-svn: 276138

Previously it was harder to read and also has a error:
command kind was not checked.

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

llvm-svn: 276137

In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion.
However, const folding and sext/zext distribution can make the reuse still difficult.

A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and
  S1 = S2 + C_a
  S3 = S2 + C_b
where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as
V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a
complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused
by the fact that S3 is generated from S1 after const folding.

In order to do that, we represent ExprValueMap as a mapping from SCEV to
ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the
ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first
expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to
V1 - C_a + C_b.

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

llvm-svn: 276136

llvm-svn: 276135

llvm-svn: 276134

llvm-svn: 276133