llvm-svn: 185941

NOTE: This is a candidate for the stable branch.
llvm-svn: 185940

llvm-svn: 185939

This fixes llvm.org/PR15170.

For now, the basic formatting rules are (based on the C++11 standard):
* Surround the "->" with spaces.
* Break before "->".

Also fix typo.

llvm-svn: 185938

llvm-svn: 185937

llvm-svn: 185936

llvm-svn: 185935

llvm-svn: 185934

llvm-svn: 185933

llvm-svn: 185932

Sema::ActOnDocumentableDecls.

Patch by Robert Wilhelm.

llvm-svn: 185931

Basically treat a function with a trailing call similar to a function
with multiple parameters.

Before:
  aaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
      aaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa))
      .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa();

After:
  aaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
                           aaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa))
      .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa();

Also fix typo.

llvm-svn: 185930

llvm-svn: 185929

llvm-svn: 185928

-Wdocumentation won't seek -isystem. LIBXML2's headers in a certain distro might be incompatible to -Wdocumentation.

FIXME: Could autoconf detect clang or availability of -isystem?
llvm-svn: 185927

llvm-svn: 185926

llvm-svn: 185925

[PowerPC] Support ".machine any"

The PowerPC assembler is supposed to provide a directive .machine
that allows switching the supported CPU instruction set on the fly.
Since we do not yet check CPU feature sets at all and always accept
any available instruction, this is not really useful at this point.

However, it makes sense to accept (and ignore) ".machine any" to
avoid spuriously rejecting existing assembler files that use this.

llvm-svn: 185924

This patch broke `make check-asan` on Mac, causing ld warnings like the following one:

ld: warning: direct access in __GLOBAL__I_a to global weak symbol
___asan_mapping_scale means the weak symbol cannot be overridden at
runtime. This was likely caused by different translation units being
compiled with different visibility settings.

The resulting test binaries crashed with incorrect ASan warnings.

llvm-svn: 185923

llvm-svn: 185922

Handle realpath(path, NULL) form.

llvm-svn: 185921

llvm-svn: 185920

Look for patterns of the form (store (load ...), ...) in which the two
locations are known not to partially overlap.  (Identical locations are OK.)
These sequences are better implemented by MVC unless either the load or
the store could use RELATIVE LONG instructions.

The testcase showed that we weren't using LHRL and LGHRL for extload16,
only sextloadi16.  The patch fixes that too.

llvm-svn: 185919

Use "STC;MVC" for memsets that are too big for two STCs or MV...Is yet
small enough for a single MVC.  As with memcpy, I'm leaving longer cases
till later.

The number of tests might seem excessive, but f33 & f34 from memset-04.ll
failed the first cut because I'd not added the "?:" on the calculation
of Size1.

llvm-svn: 185918

llvm-svn: 185917

llvm-svn: 185916

The following transforms are valid if -C is a power of 2:
(icmp ugt (xor X, C), ~C) -> (icmp ult X, C)
(icmp ult (xor X, C), -C) -> (icmp uge X, C)

These are nice, they get rid of the xor.

llvm-svn: 185915

Before:
someFunction(OtherParam, BracedList{
                           // comment 1 (Forcing intersting break)
                           param1, param2,
                           // comment 2
                           param3, param4
             });
After:
someFunction(OtherParam, BracedList{
                           // comment 1 (Forcing intersting break)
                           param1, param2,
                           // comment 2
                           param3, param4
                         });

To do so, the UnwrappedLineParser now stores the information about the
kind of brace in the FormatToken.

llvm-svn: 185914

llvm-svn: 185913

Tests were added in r185910 somehow.

llvm-svn: 185912

[PowerPC] Support .llong and fix .word

This adds support for the .llong PowerPC-specifc assembler directive.
In doing so, I notices that .word is currently incorrect: it is
supposed to define a 2-byte data element, not a 4-byte one.

llvm-svn: 185911

llvm-svn: 185910

C1-X <u C2 -> (X|(C2-1)) == C1
C1-X >u C2 -> (X|C2) == C1
X-C1 <u C2 -> (X & -C2) == C1
X-C1 >u C2 -> (X & ~C2) == C1

llvm-svn: 185909

This fixes llvm.org/PR16328 (at least partially).

Before:
SomeLoooooooooooooooooooooooooooooogType operator<<(
    const SomeLooooooooogType &a, const SomeLooooooooogType &b);

After:
SomeLoooooooooooooooooooooooooooooogType
operator<<(const SomeLooooooooogType &a, const SomeLooooooooogType &b);

llvm-svn: 185908

This fixes another bug found by llvm-stress!

If we happen to be doing an i64 load or store into a stack slot that has less
than a 4-byte alignment, then the frame-index elimination may need to use an
indexed load or store instruction (because the offset may not be a multiple of
4, a requirement of the STD/LD instructions). The extra register needed to hold
the offset comes from the register scavenger, and it is possible that the
scavenger will need to use an emergency spill slot. As a result, we need to
make sure that a spill slot is allocated when doing an i64 load/store into a
less-than-4-byte-aligned stack slot.

Because test cases for things like this tend to be fairly fragile, I've
concatenated a few small bugpoint-reduced test cases together to form the
regression test.

llvm-svn: 185907

llvm-svn: 185906

It is always computed the same way (by parsing the header). Doing it in the
constructor simplifies the callers a bit.

llvm-svn: 185905

llvm-svn: 185904

print five words of memory at the beginning of the stack frame so it's
easier to track where an incorrect saved-fp or saved-pc may have come from.

llvm-svn: 185903

Contents of ".reloc" section depends on the addresses of other sections, so
the section cannot be created until all the other sections are created and get
their memory addresses (RVAs). That means that computation of section size
needs to be at least two pass.

Techynically there's no reason to compute it all at once, but instead we can
compute the address of a section as added to the output file. Doing so helps
us to create ".reloc" section.

llvm-svn: 185902