Introduced in -r283004, the PassNameParser sorts Optimization options in 
reverse. This is because the commit replaced a compare function with "<" 
(which would seemingly be proper based on the name of the comparison function). 
The result is the 'true' result is converted to '1', which is inverted.

This patch fixes this by replacing the '<' operator call on StringRef with a 
call to the StringRef compare function. It also renames the function to better 
reflect its meaning.

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

llvm-svn: 306857

llvm-svn: 306856

I'm tired of seeing this:
        .globl  "?Test@@YAXXZ"          # -- Begin function ^A?Test@@YAXXZ

llvm-svn: 306855

Symbols in the resource COFF file should be for .rsrc$02, where the
actual resource data is, not .rsrc$01, which contains the directory
tree.

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

Patch by Joe Ranieri.

llvm-svn: 306853

Previously we had the -type-index option which would dump the record of
a single, but we had no way to follow the dependency graph backwards and
also dump all dependent types.

Having this option makes test-writing better, because we can limit the
test to only those records that are of importance for the thing we're
trying to test, which allows us to use things like CHECK-NEXT to reduce
fragility.

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

llvm-svn: 306852

Summary:
To enable profile hotness information in diagnostics output, Clang takes
the option `-fdiagnostics-show-hotness` -- that's "diagnostics", with an
"s" at the end. Clang also defines `CodeGenOptions::DiagnosticsWithHotness`.

LLVM, on the other hand, defines
`LLVMContext::getDiagnosticHotnessRequested` -- that's "diagnostic", not
"diagnostics". It's a small difference, but it's confusing, typo-inducing, and
frustrating.

Add a new method with the spelling "diagnostics", and "deprecate" the
old spelling.

Reviewers: anemet, davidxl

Reviewed By: anemet

Subscribers: llvm-commits, mehdi_amini

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

llvm-svn: 306848

llvm-svn: 306847

Summary:
Runtime unrolling is done for loops with a single exit block and a
single exiting block (and this exiting block should be the latch block).
This patch adds logic to support unrolling in the presence of multiple exit
blocks (which also means multiple exiting blocks).
Currently this is under an off-by-default option and is supported when
epilog code is generated. Support in presence of prolog code will be in
a future patch (we just need to add more tests, and update comments).

This patch is essentially an implementation patch. I have not added any
heuristic (in terms of branches added or code size) to decide when
this should be enabled.

Reviewers: mkuper, sanjoy, reames, evstupac

Reviewed by: reames

Subscribers: llvm-commits

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

llvm-svn: 306846

This fixes a cmake configuration issue when LLVM is configured with no targets.
Instead we need to add TestingSupport directly with target_link_libraries.

llvm-svn: 306842

Summary:
Some transforms assume that DT.verifyDomInfo() is not expensive and call it even when ENABLE_EXPENSIVE_CHECKS is not set.
This patch disables expensive Dominator Tree verification (reachability, parent property, sibling property) to fix
[[ https://bugs.llvm.org/show_bug.cgi?id=33656 | PR33656 ]].

Note that this is only a temporary fix.

Reviewers: dberlin, chapuni, kparzysz, grosser

Reviewed By: dberlin

Subscribers: llvm-commits

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

llvm-svn: 306839

This reverts commit da6318a92fba793e4f2447ec478b001392d57d43.

This is causing failures on some build bots due to what appears
to be some kind of lit ordering dependency.

llvm-svn: 306833

Presently lit leaks files in the tests' output directories.
Specifically, if a test creates output files, lit makes no
effort to remove them prior to the next test run.  This is
problematic because it leads to false positives whenever a
test passes because stale  files were present.  In general
it is a source of flakiness that should be removed.

This patch addresses this by building the list of all test
directories that are part of the current run set, and then
deleting those directories and recreating them anew.  This
gives each test a clean baseline to start from.

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

llvm-svn: 306832

In particular, use CALL16 (similar to O32) for address loads into T9 for certain
cases.  Otherwise use a %got_disp relocation to load the address of a symbol.
Small offsets (small enough to fit in a 16-bit signed immediate) can be used and
are added to the symbol address after it is loaded from the GOT.  Larger offsets
are currently unsupported and result in an error from the assembler.

Reviewers: sdardis

Reviewed By: sdardis

Patch by: John Baldwin

Subscribers: llvm-commits, seanbruno, arichardson, emaste, dim

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

llvm-svn: 306831

llvm-svn: 306828

Summary:
When linking a regular LTO module, if it has any non-prevailing values
(dropped to available_externally) in comdats, we need to do more than
just remove those values from their comdat. We also remove all values
from that comdat, so as to avoid leaving an incomplete comdat.

This is necessary in case we are compiling in mixed regular and ThinLTO
mode, since the resulting regularLTO native object is always linked into
the final binary first. We need to prevent the linker from selecting an
incomplete comdat that was not the prevailing copy.

Fixes PR32980.

Reviewers: pcc, rafael

Subscribers: mehdi_amini, david2050, llvm-commits, inglorion

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

llvm-svn: 306826

llvm-svn: 306824

There are a few instructions provided by the high-word facility (z196)
that we cannot easily exploit for code generation.  This patch at least
adds those missing instructions for the assembler and disassembler.

This means that now all nonprivileged instructions up to z13 are
supported by the LLVM assembler / disassembler.

llvm-svn: 306821

This reverts commit r306819 which appears be exposing underlying
issues in a stage1 ppc64be build

llvm-svn: 306820

As discussed in D34087, rewrite areNonVolatileConsecutiveLoads using
generic checks. Also, propagate missing local handling from there to
BaseIndexOffset checks.

Tests of note:

  * test/CodeGen/X86/build-vector* - Improved.
  * test/CodeGen/BPF/undef.ll - Improved store alignment allows an
    additional store merge

  * test/CodeGen/X86/clear_upper_vector_element_bits.ll - This is a
    case we already do not handle well. Here, the DAG is improved, but
    scheduling causes a code size degradation.

Reviewers: RKSimon, craig.topper, spatel, andreadb, filcab

Subscribers: nemanjai, llvm-commits

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

llvm-svn: 306819

llvm-svn: 306818

llvm-svn: 306816

llvm-svn: 306815

That may be useful if we want to produce or parse object containing
broken relocation values using yaml2obj/obj2yaml.

Previously that was impossible because only enum values were parsed
correctly, this patch allows to put any numeric value as a
relocation type.

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

llvm-svn: 306814

Current implementation looks a bit confusing. It looks like it should
report/print something on error, but it does not do that.
It silently drops a error message when creating triple, though
this behavior is fine generally.

For example if LLVM configured with -DLLVM_TARGETS_TO_BUILD=ARM and
our host is windows, it is expected that we will be unable to
create "i386-pc-windows-msvc" target.

Patch introduces isConfigurationSupported() function that checks
if current configuration is supported for each test and returns early if not.

llvm-svn: 306812

llvm-svn: 306811

Reviewers: klimek, chandlerc, mehdi_amini

Reviewed By: klimek, mehdi_amini

Subscribers: mehdi_amini, jlebar, llvm-commits

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

llvm-svn: 306810

llvm-svn: 306808

In r301116, a custom lowering needed to be introduced to be able to
legalize 8 and 16-bit divisions on ARM targets without a division
instruction, since 2-step legalization (WidenScalar from 8 bit to 32
bit, then Libcall the 32-bit division) doesn't work.

This fixes this and makes this kind of multi-step legalization, where
first the size of the type needs to be changed and then some action is
needed that doesn't require changing the size of the type,
straighforward to specify.

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

llvm-svn: 306806

It may be detrimental to vectorize loops with very small trip count, as various
costs of the vectorized loop body as well as enclosing overheads including
runtime tests and scalar iterations may outweigh the gains of vectorizing. The
current cost model measures the cost of the vectorized loop body only, expecting
it will amortize other costs, and loops with known or expected very small trip
counts are not vectorized at all. This patch allows loops with very small trip
counts to be vectorized, but under OptForSize constraints, which ensure the cost
of the loop body is dominant, having no runtime guards nor scalar iterations.

Patch inspired by D32451.

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

llvm-svn: 306803

[InstCombine] Add test cases to demonstrate failure to fold (a | b) ^ (~a | ~b) --> ~(a ^ b) and its commuted variants.

llvm-svn: 306801

[InstCombine] In foldXorToXor, move the commutable matcher from the LHS match to the RHS match. No meaningful change intended.

There are two conditions ORed here with similar checks and each contain two matches that must be true for the if to succeed. With the commutable match on the first half of the OR then both ifs basically have the same first part and only the second part distinguishs. With this change we move the commutable match to second half and make the first half unique.

This caused some tests to change because we now produce a commuted result, but this shouldn't matter in practice.

llvm-svn: 306800

llvm-svn: 306798

It served us well, helped kick-start much of the vectorization efforts
in LLVM, etc. Its time has come and past. Back in 2014:
http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html

Time to actually let go and move forward. =]

I've updated the release notes both about the removal and the
deprecation of the corresponding C API.

llvm-svn: 306797

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

llvm-svn: 306795

This is useful for a testcase in lld.

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

llvm-svn: 306794

Segfaults in non-optimized builds. I'll get a stack trace and a
reproducer to Teresa.

llvm-svn: 306793

This still breaks PPC tests we have. I'll forward reproduction
instructions to dehao.

llvm-svn: 306792

The return of itaniumDemangle is allocated with malloc rather than new[]
and so using unique_ptr isn't called for here. As a note for the future
we should rewrite it to do this.

llvm-svn: 306788

In rL300494 there was an attempt to deal with excessive compile time on
invocations of getSign/ZeroExtExpr using local caching. This approach only
helps if we request the same SCEV multiple times throughout recursion. But
in the bug PR33431 we see a case where we request different values all the time,
so caching does not help and the size of the cache grows enormously.

In this patch we remove the local cache for this methods and add the recursion
depth limit instead, as we do for arithmetics. This gives us a guarantee that the
invocation sequence is limited and reasonably short.

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

llvm-svn: 306785

The failure is:
C:\ps4-buildslave2\llvm-clang-x86_64-expensive-checks-win\llvm\unittests\ProfileData\CoverageMappingTest.cpp(244):
error C2668: 'llvm::make_unique': ambiguous call to overloaded function

http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/3489/

llvm-svn: 306784