Doing this means that if an LEApcrel is used in two places we will rematerialize
instead of generating two MOVs. This is particularly useful for printfs using
the same format string, where we want to generate an address into a register
that's going to get corrupted by the call.

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

llvm-svn: 303054

Doing this lets us hoist it out of loops, and I've also marked it as
rematerializable the same as the thumb1 and thumb2 counterparts.

It looks like it being marked as such was just a mistake, as the commit that
made that change only mentions LEApcrelJT and in thumb1 and thumb2 only the
LEApcrelJT instructions were marked as having side-effects, so it looks like
the intent was to only mark LEApcrelJT as having side-effects but LEApcrel was
accidentally marked as such also.

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

llvm-svn: 303053

llvm-svn: 303052

I am working on a speedup of building .gdb_index in LLD and 
noticed that relocations that are proccessed in DWARFContextInMemory often uses
the same symbol in a row. This patch introduces caching to reduce the relocations
proccessing time.

For benchmark,
I took debug LLC binary objects configured with -ggnu-pubnames and linked it using LLD.

Link time without --gdb-index is about 4,45s.
Link time with --gdb-index: a) Without patch: 19,16s b) With patch: 15,52s
That means time spent on --gdb-index in this configuration is 
19,16s - 4,45s = 14,71s (without patch) vs 15,52s - 4,45s = 11,07s (with patch).

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

llvm-svn: 303051

[X86] Relocate code of replacement of subtarget unsupported masked memory intrinsics to run also on -O0 option.

Currently, when masked load, store, gather or scatter intrinsics are used, we check in CodeGenPrepare pass if the subtarget support these intrinsics, if not we replace them with scalar code - this is a functional transformation not an optimization (not optional).

CodeGenPrepare pass does not run when the optimization level is set to CodeGenOpt::None (-O0).

Functional transformation should run with all optimization levels, so here I created a new pass which runs on all optimization levels and does no more than this transformation.

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

llvm-svn: 303050

    myFunction(param1, param2,);

For symmetry with other parenthesized lists ([...], {...}), clang-format should
wrap parenthesized lists one-per-line if they contain a trailing comma:

    myFunction(
        param1,
        param2,
    );

This is particularly useful in function declarations or calls with many
arguments, e.g. commonly in constructors.

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

llvm-svn: 303049

rdar://32195226

llvm-svn: 303048

NFC followup to D33147, this explicitly sets all the arguments (instead of relying on the defaults) to SelectionDAG::getMemIntrinsicNode to help identify -verify-machineinstrs issues.

llvm-svn: 303047

rdar://32195200

llvm-svn: 303046

in a record that has no definition

rdar://32194921

llvm-svn: 303045

Reviewers: stoklund, grosbach, vpykhtin

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

llvm-svn: 303044

Summary:
We were asserting in RegisterBankInfo if RBI.copyCost() returns
UINT_MAX.  This is OK for RegBankSelect::Mode::Fast since we only
try one instruction mapping and can't recover from this, but for
RegBankSelect::Mode::Greedy we will be considering multiple
instruction mappings, so we can recover if we see a UNIT_MAX copy
cost.

The copy cost for one pair of register banks in the AMDGPU backend
will be UNIT_MAX, so this patch will prevent AMDGPU tests from
breaking.

Reviewers: ab, qcolombet, t.p.northover, dsanders

Reviewed By: qcolombet

Subscribers: tpr, llvm-commits

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

llvm-svn: 303043

Summary:
This was broken by r302499.  Configuring with -DLLVM_BUILD_DOCS=ON would
cause the docs-llvm-man target not to be created.

Reviewers: anemet, beanz

Reviewed By: anemet

Subscribers: llvm-commits, mgorny

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

llvm-svn: 303042

We were previously silently emitting bogus data in release mode,
making it very hard to diagnose the error, or crashing with an
assert in debug mode. A proper diagnostic is now always emitted
when the value to be emitted is out of range.

llvm-svn: 303041

- This breaks the previous assumption that Fortran Arrays are `GlobalValue`.

- The names of functions were getting unwieldy. So, I renamed the
Fortran related functions.

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

llvm-svn: 303040

- auto + decltype + template use was not inferrable in
  `Transform/Simplify.cpp accessesInOrder`.

- changed code to explicitly construct required vector instead of using
  higher order iterator helpers.

- Failing compiler spec:
    Apple LLVM version 7.3.0 (clang-703.0.31)
    Target: x86_64-apple-darwin15.6.0

llvm-svn: 303039

Summary:
`getIdentifierInfo()` includes all keywords, whereas non-null assertion
operators should only be recognized after non-keywords or pseudo keywords.
Ideally this should list all tokens that clang-format recognizes as a keyword,
but that are pseudo or no keywords in JS. For the time being, just recognize
the specific bits users ran into (`namespace` in this case).

Reviewers: djasper

Subscribers: klimek

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

llvm-svn: 303038

module immediately

Also revert dependent r302969. This is leading to crashes.
Will provide more details reproduction instructions to Richard.

llvm-svn: 303037

llvm-svn: 303036

This patch finishes off the conversion of ComputeSignBit to computeKnownBits.

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

llvm-svn: 303035

llvm-svn: 303034

llvm-svn: 303033

I need to add some asserts to these constructors that are easier to
add once they're in the .cpp file.

llvm-svn: 303032

Separated very long brief sections into two sections. 

I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.

llvm-svn: 303031

llvm-svn: 303030

Summary:
Merge overflow computation for signed add,
appearing both in InstCombine and ValueTracking.

As part of the merge,
cleanup the interface for overflow checks in InstCombine.

Patch by Yoav Ben-Shalom.

Reviewers: craig.topper, majnemer

Reviewed By: craig.topper

Subscribers: takuto.ikuta, llvm-commits

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

llvm-svn: 303029

llvm-svn: 303028

llvm-svn: 303027

https://bugs.llvm.org/show_bug.cgi?id=32933

Turns out clang wasn't really handling vla's (*) in C++11's for-range entirely correctly. 

For e.g. This would lead to generation of buggy IR:

  void foo(int b) {
    int vla[b];
    b = -1;  // This store would affect the '__end = vla + b'
    for (int &c : vla) 
      c = 0;
  }

Additionally, code-gen would get confused when VLA's were reference-captured by lambdas, and then used in a for-range, which would result in an attempt to generate IR for '__end = vla + b' within the lambda's body - without any capture of 'b' - hence the assertion.

This patch modifies clang, so that for VLA's it translates the end pointer approximately into:
  __end = __begin + sizeof(vla)/sizeof(vla->getElementType())

As opposed to the __end = __begin + b;

I considered passing a magic value into codegen - or having codegen special case the '__end' variable when it referred to a variably-modified type, but I decided against that approach, because it smelled like I would be increasing a complicated form of coupling, that I think would be even harder to maintain than the above approach (which can easily be optimized (-O1) to refer to the run-time bound that was calculated upon array's creation or copied into the lambda's closure object).


(*) why oh why gcc would you enable this by default?! ;)

llvm-svn: 303026

One didn't correctly fine the regex variable, the other still had a RUN
line for FNOBUILTIN-checks, which weren't copied to the file.

llvm-svn: 303025

Replace SelectionDAG::getNode(ISD::SELECT, ...)
and SelectionDAG::getNode(ISD::VSELECT, ...)
with SelectionDAG::getSelect(...)
Saves a few lines of code and in some cases saves the need to explicitly
check the type of the desired node.

llvm-svn: 303024

llvm-svn: 303023

llvm-svn: 303022

llvm-svn: 303021

[X86] Add avx512vl command lines to the 128/256-bit vector-lzcnt tests so we can see what compare instructions are being used in the lookup table code.

I noticed the 512-bit lzcnts don't use the X86 specific lookup table code and instead use the EXPAND case in LegalizeDAG. I was toying around with fixing this and noticed it would require compare instructions that generate i1 masks and then converting from mask to vector. Then I noticed that we don't test which compares are used with avx512vl and no avx512cd.

llvm-svn: 303020

Remove an unneeded prefix from the 32-bit command line. Make all the 64-bit triples match. Replace ALL with X64 and remove it from the 32-bit test.

llvm-svn: 303019

llvm-svn: 303018

llvm-svn: 303017

Revert the two commits to understand why the following aarch64 bot is
failing.

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux

llvm-svn: 303016

Summary:

After rL301562, on FreeBSD the DynamicLibrary unittests fail, because
the test uses getMainExecutable("DynamicLibraryTests", Ptr), and since
the path does not contain any slashes, retrieving the main executable
will not work.

Reimplement getMainExecutable() for FreeBSD and NetBSD using sysctl(3),
which is more reliable than fiddling with relative or absolute paths.

Also add retrieval of the original argv[] from the GoogleTest framework,
to use as a fallback for other OSes.

Reviewers: emaste, marsupial, hans, krytarowski

Reviewed By: krytarowski

Subscribers: krytarowski, llvm-commits

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

llvm-svn: 303015