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

Otherwise, you have to say "x/gx" to what you obviously intended to
happen to happen.

<rdar://problem/27415507>

llvm-svn: 276132

llvm-svn: 276130

None of the current lit tests hit si_break handling.

llvm-svn: 276129

Obtained from FreeBSD SVN r302475

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

llvm-svn: 276128

llvm-svn: 276126

Should fix the Windows buildbots, and maybe some other non-Linux Unix
bots too.

XRay currently depends on sanitizer_common, so associate it with the
"build sanitizers" option and remove the option for separately
controlling the XRay build.

llvm-svn: 276124

- R_ARM_TLS_LDM32
- R_ARM_TLS_LDO32

The local dynamic implementation and tests follows the same model as 
the other ARM TLS models. The R_ARM_TLS_LDO32 is implemented as R_ABS 
expr type as the getVA() for a TLS symbol will return the offset from the 
start of the TLS block.

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

llvm-svn: 276123

Summary:
This test is allocating a 1gig chunk to make shadow allocation failed,
but on 64-bits architecture the test is working.

Reviewers: rnk

Subscribers: kubabrecka, llvm-commits, wang0109, chrisha

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

llvm-svn: 276122

llvm-svn: 276121

'ReusingBase' was a terrible name. It might actually refer to the most
derived class, which is not a base. 'BaseWithVPtr' was also bad, since
again, it could refer to the most derived class. It was actually the
first base to introduce the vptr, so now it is 'IntroducingObject'.

llvm-svn: 276120

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

llvm-svn: 276119

Under MSVS 2015 I observed integral constant overflow warning when aggregate initialization was used
to init the bit field. Patch fixes that.

llvm-svn: 276118

Summary:
This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting).

Depends on D19904

Reviewers: echristo, kcc, rnk

Subscribers: rnk, mehdi_amini, llvm-commits

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

llvm-svn: 276117

It's only asan that installs vectored SEH handler to map memory lazily.

llvm-svn: 276112

Summary:
Previoly, the added test failed with the fillowing fixit:

     char v[5];

-    for(size_t i = 0; i < 5; ++i)
+    for(char value : v)
     {
-        unsigned char value = v[i];
         if (value > 127)

i.e. the variable 'value' changes from unsigned char to signed char. And
thus the following 'if' does not work anymore.

With this commit, the fixit is changed to:
     char v[5];

-    for(size_t i = 0; i < 5; ++i)
+    for(unsigned char value : v)
     {
-        unsigned char value = v[i];
         if (value > 127)

Reviewers: alexfh, klimek

Subscribers: cfe-commits

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

llvm-svn: 276111

Added Camel_Snake_Case and camel_Snake_Back

class Camel_Snake_Case_Class_Name
{
  void private_Camel_Snake_Back_Method_Name();
}

Patch by James Reynolds!

Reviewers: alexfh

Subscribers: cfe-commits

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

llvm-svn: 276110

Lots of blocks had "llvm" or "nasm" syntax types but either weren't following
the syntax, or the syntax has changed (and sphinx hasn't keep up) or the type
doesn't even exist (nasm?).

Other documents had :options: what were invalid. I only removed those that had
warnings, and left the ones that didn't, in order to follow the principle of
least surprise.

This is like this for ages, but the buildbot is now failing on errors. It may
take a while to upgrade the buildbot's sphinx, if that's even possible, but
that shouldn't stop us from getting docs updates (which seem down for quite
a while).

Also, we're not losing any syntax highlight, since when it doesn't parse, it
doesn't colour. Ie. those blocks are not being highlighted anyway.

I'm trying to get all docs in one go, so that it's easy to revert later if we
do fix, or at least easy to know what's to fix.

llvm-svn: 276109

In here we are iterating relocations in order, so we can do the same
with the pieces of .eh_frame and avoid a binary search.

The link times I got with this patch were:

firefox
  master 7.22977811
  patch  7.141041442 0.987726225252
chromium
  master 4.478966851
  patch  4.506602207 1.00617002914
chromium fast
  master 1.894713371
  patch  1.866446889 0.98508139414
the gold plugin
  master 0.386193907
  patch  0.382374918 0.990111213743
clang
  master 0.654849589
  patch  0.647899815 0.989387220949
llvm-as
  master 0.037212718
  patch  0.036858172 0.990472450843
the gold plugin fsds
  master 0.410876711
  patch  0.407418613 0.991583611562
clang fsds
  master 0.734623069
  patch  0.728237526 0.991307728726
llvm-as fsds
  master 0.033446197
  patch  0.03302833 0.987506292569
scylla
  master 3.38134402
  patch  3.414188846 1.00971354166

llvm-svn: 276108

Currently fails as:

gotsan.cc: In function 'void* __sanitizer::__libc_memalign(__sanitizer::uptr, __sanitizer::uptr)':
gotsan.cc:6194:50: error: 'posix_memalign' was not declared in this scope
   uptr error = posix_memalign(&p, alignment, size);

Windows does not provide posix_memalign.

llvm-svn: 276107

Makes InstCombine infloop when compiling v8.

This reverts commit r275989 and r276105.

llvm-svn: 276106

Summary: In r275989 we enabled the folding of `logic(cast(icmp), cast(icmp))` to `cast(logic(icmp, icmp))`. Here we add more test cases to assure this folding works for all logical operations `and`/`or`/`xor`.

Reviewers: grosser

Subscribers: llvm-commits

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

Contributed-by: Matthias Reisinger
llvm-svn: 276105

This patch adds costs for the vectorized implementations of CTPOP, the default values were seriously underestimating the cost of these and was encouraging vectorization on targets where serialized use of POPCNT would be much better.

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

llvm-svn: 276104

llvm-svn: 276103

D20859 and D20860 attempted to replace the SSE (V)CVTTPS2DQ and VCVTTPD2DQ truncating conversions with generic IR instead.

It turns out that the behaviour of these intrinsics is different enough from generic IR that this will cause problems, INF/NAN/out of range values are guaranteed to result in a 0x80000000 value - which plays havoc with constant folding which converts them to either zero or UNDEF. This is also an issue with the scalar implementations (which were already generic IR and what I was trying to match).

This patch changes both scalar and packed versions back to using x86-specific builtins.

It also deals with the other scalar conversion cases that are runtime rounding mode dependent and can have similar issues with constant folding.

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

llvm-svn: 276102

Retry r275776 (no changes, we suspect the issue was with another commit).

The current logic for handling inline asm operands in DAGToDAGISel interprets
the operands by looking for constants, which should represent the flags
describing the kind of operand we're dealing with (immediate, memory, register
def etc). The operands representing actual data are skipped only if they are
non-const, with the exception of immediate operands which are skipped explicitly
when a flag describing an immediate is found.

The oversight is that memory operands may be const too (e.g. for device drivers
reading a fixed address), so we should explicitly skip the operand following a
flag describing a memory operand. If we don't, we risk interpreting that
constant as a flag, which is definitely not intended.

Fixes PR26038

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

llvm-svn: 276101

This will unblock the llvm-sphinx-buildbot, which is currently failing due
to a warning being treated as error.

llvm-svn: 276100

llvm-svn: 276099

include a newline at the end.

llvm-svn: 276098