Turns out we can have comparisons which are indirect users of the induction variable that we can make invariant.  In this case, there is no loop invariant value contributing and we'd fail an assert.

The test case was found by a java fuzzer and reduced.  It's a real cornercase.  You have to have a static loop which we've already proven only executes once, but haven't broken the backedge on, and an inner phi whose result can be constant folded by SCEV using exit count reasoning but not proven by isKnownPredicate.  To my knowledge, only the fuzzer has hit this case.

llvm-svn: 319583

Still fails for some bots.

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

llvm-svn: 319582

These are blocks that haven't not been executed during training.  For large
projects this could make a significant difference.  For the project, I was
looking at, I got an order of magnitude decrease in the size of the total YAML
files with this and r319235.

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

Re-commit after fixing the failing testcase in rL319576, rL319577 and
rL319578.

llvm-svn: 319581

I have found LLDB commonly looks up lldb::user_id_t 0xffffffff failing to find
its DIE. One would rather expect LLDB_INVALID_UID == 0xffffffffffffffff in such
case.

DWARFASTParserClang.cpp:495
492             type_sp.reset(
493                 new Type(die.GetID(), dwarf, type_name_const_str, byte_size, NULL,
494                          DIERef(encoding_uid).GetUID(dwarf), encoding_data_type,
495                          &decl, clang_type, resolve_state));
encoding_uid = (DWARFFormValue) {m_cu = 0x0, m_form = 0, m_value = {value = {uval = 0, sval = 0, cstr = 0x0}, data = 0x0}}
-> DIERef::DIERef(const DWARFFormValue &form_value = {m_cu = 0x0, m_form = 0, m_value = {value = {uval = 0, sval = 0, cstr = 0x0}, data = 0x0}})
-> (DIERef) {cu_offset = 0xffffffff, die_offset = 0xffffffff}
-> lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf = 0x61d00000b480) const
-> Type::Type(lldb::user_id_t encoding_uid = 0xffffffff)
But 0xffffffff !=
#define LLDB_INVALID_UID UINT64_MAX

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

llvm-svn: 319580

llvm-svn: 319579

The driver-based test is still not identical to the front-end line, remove the
hotness threshold from there and add a new front-end based test with
threshold.

llvm-svn: 319578

1. Require hotness on all remark lines with -verify.

3. Fix the samplePGO file to actually produce hotness on each line.

The second remark has hotness 60 rather 30 which I don't quite understand but
testing this is strictly better than before.  It also unblocks the commit of
D40678.

llvm-svn: 319577

A RUN line was referring to the previous RUN line but a new test was added in
between them.  Just reorder the lines.

Note this still does not completely fix this the brokenness of the comment as
the driver-based test gained a new hotness-threshold argument in r306948 but
I'll fix that is a separate commit.

llvm-svn: 319576

Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.

This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.

I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.

Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.

Please review carefully, i have not worked with lit/sanitizer tests before.

The original attempt, r319525 was reverted in r319526 due
to the failures in compiler-rt standalone builds.

Reviewers: eugenis, vitalybuka

Reviewed By: eugenis

Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc

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

llvm-svn: 319575

Only pass Native to LLVM_TARGETS_TO_BUILD.

Summary:
Remove the redundant, config-time call to cmake when
building host tools for cross compiles or optimized tablegen..

The config-time call to cmake is redundant because it will always get
called again when the CONFIGURE_LLVM_${target_name} target fires at
build-time.  This speeds up initial configuration, but has no affect
on build behavior.

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

llvm-svn: 319574

Followup to D39595. Removes a bunch of redundant checks.

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

llvm-svn: 319573

llvm-svn: 319572

llvm-svn: 319571

Per beanz, building compiler-rt standalone is a pretty important use
case, so the comment is very out of date.

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

llvm-svn: 319570

These targets strip during installation, and are required to support
install-distribution-stripped in LLVM (to support a stripped
distribution). LLVM has an add_llvm_install_targets function for this
purpose, but we can't rely on LLVM being present.

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

llvm-svn: 319569

llvm-svn: 319568

llvm-svn: 319567

Summary:
Adding support for -print-module-scope similar to how it is
being done for function passes. This option causes loop-pass printer
to emit a whole-module IR instead of just a loop itself.

Reviewers: sanjoy, silvas, weimingz

Reviewed By: sanjoy

Subscribers: apilipenko, skatkov, llvm-commits

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

llvm-svn: 319566

This would have found the regression in r318924.

Thanks to James Henderson for finding the issue!

llvm-svn: 319565

llvm-svn: 319564

PR35478 https://bugs.llvm.org/show_bug.cgi?id=35478 points out a flaw
in the implementation of r318924 from D40364. The implementation
depends on the Size field being set or the SyntheticSection::empty()
being accurate. These functions are not reliable as some linker script
commands that have yet to be processed may affect the results, causing
some non-zero size sections to be reported as zero size.

I think the first step is to revert r318924 and come up with a better
solution for the underlying problem rather than trying to layer more
heuristics onto the zero sized output section.

Chances are I'll be out of office by the time anyone sees this so feel
free to commit the revert if you agree with me.

Fixes PR35478

Current thoughts on the underlying problem:

Revisiting the motivation for adding the zero size check in the first
place; it was to prevent 0 sized SyntheticSections that a user does
not have full control over from needlessly breaking the PT_GNU_RELRO,
rather than trying to accommodate arbitrarily complex linker
scripts. Looking at the code, it looks like
removeUnusedSyntheticSections() should remove zero sized synthetic
sections. It does, but it doesn't set the Parent to nullptr, this has
the side effect that Sec == InX::BssRelRo->getParent() will make the
parent OutputSection of InX::BssRelRo RelRo even if there is no
InX::BssRelRo.

I tried a quick experiment with setting the Parent to nullptr and this
flushed out a few interesting test failures, it feels like playing
Jenga with every change:

    In the isRelroSection() we have to consider the case where there
    is no .plt and .plt.got but there is a ifunc plt with accompanying
    (ifunc .got or .plt.got)

    The PPC64 has PltHeaderSize == 0. Unfortunately HeaderSize == 0 is
    used to choose between the ifunc plt or normal plt. We seem to get
    away with this at the moment, but tests start to fail when Parent
    is set to nullptr for the .got.plt.

    The InX::BssRelRo and InX::Bss never get their sizes set and they
    are always removed by removeUnusedSyntheticSections(), their
    purpose seems to be as some kind of proxy for add .bss or
    .bss.relro InputSections into their parent OutputSections, they
    therefore don't behave like other SyntheticSections anyway.

My thinking is that some work is needed to make sure that the Sec ==
SyntheticSection->getParent() does a bit more checking before
returning true, particularly for InX::BssRelRo as that has special
behaviour. I'll hope to post something for review as soon as possible.

Patch by Peter Smith!

llvm-svn: 319563

This reverts commit r319556.

Something is not working with this when used with sample-based profiling.
Investigating...

llvm-svn: 319562

Summary:
When debugging function passes it happens to be rather useful to dump
the whole module before the transformation and then use this dump
to analyze this single transformation by running it separately
on that particular module state.

Introducing
    -print-module-scope
debugging option that forces all the function-level IR dumps
to become whole-module dumps.

This option builds on top of normal dumping controls like
   -print-before/after
   -filter-print-funcs

The plan is to eventually extend this option to cover other local passes
(at least loop passes) but that should go as a separate change.

Reviewers: sanjoy, weimingz, silvas, fedor.sergeev

Reviewed By: weimingz

Subscribers: apilipenko, skatkov, llvm-commits, mehdi_amini

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

llvm-svn: 319561

distribute directives.

OpenMP standard does not allow to mark the variables as firstprivate and lastprivate at the same time in distribute-based directives. Patch fixes this problem.

llvm-svn: 319560

llvm-svn: 319559

llvm-svn: 319558

Summary:
This will be used for rescoring code completion results based on partial
identifiers.
Short-term use:
  - we want to limit the number of code completion results returned to
  improve performance of global completion. The scorer will be used to
  rerank the results to return when the user has applied a filter.
Long-term use case:
  - ranking of completion results from in-memory index
  - merging of completion results from multiple sources (merging usually
  works best when done at the component-score level, rescoring the
  fuzzy-match quality avoids different backends needing to have
  comparable scores)

Reviewers: ilya-biryukov

Subscribers: cfe-commits, mgorny

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

llvm-svn: 319557

These are blocks that haven't not been executed during training.  For large
projects this could make a significant difference.  For the project, I was
looking at, I got an order of magnitude decrease in the size of the total YAML
files with this and r319235.

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

llvm-svn: 319556

Disallow a cleanup attribute from appertaining to a parameter (the attribute only appertains to local variables and is silently a noop on parameters). This repurposes the unused (and syntactically incorrect) NormalVar attribute subject.

llvm-svn: 319555

llvm-svn: 319554

llvm-svn: 319553

Summary:
This allows us to limit the number of results we return and still allow them
to be surfaced by refining a query (D39852).

The initial algorithm is very conservative - it accepts a completion if the
filter is any case-insensitive sub-sequence. It does not attempt to rank items
based on match quality.

Reviewers: ilya-biryukov

Subscribers: cfe-commits

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

llvm-svn: 319552

llvm-svn: 319551

Revert r319531 "[SLPVectorizer] Failure to beneficially vectorize 'copyable' elements in integer binary ops."

It causes builds to fail with "Instruction does not dominate all uses" (PR35497).

> Patch tries to improve vectorization of the following code:
>
> void add1(int * __restrict dst, const int * __restrict src) {
>   *dst++ = *src++;
>   *dst++ = *src++ + 1;
>   *dst++ = *src++ + 2;
>   *dst++ = *src++ + 3;
> }
> Allows to vectorize even if the very first operation is not a binary add, but just a load.
>
> Fixed issues related to previous commit.
>
> Reviewers: spatel, mzolotukhin, mkuper, hfinkel, RKSimon, filcab, ABataev
>
> Reviewed By: ABataev, RKSimon
>
> Subscribers: llvm-commits, RKSimon
>
> Differential Revision: https://reviews.llvm.org/D28907

llvm-svn: 319550

Remove duplicate, nonsense information from an attribute diagnostic. The NonParmVar subject does not need to mention functions, and the resulting diagnostic definitely does not need to mention functions twice.

llvm-svn: 319549

Add a few more tests cases.

llvm-svn: 319548

Summary: Reenable post-legalize stores with constant merging computation and cofrresponding test case.

Reviewers: eastig, efriedma

Subscribers: aemerson, javed.absar, kristof.beyls, hiraditya, llvm-commits

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

llvm-svn: 319547

This has no effect because we explicitly choose our actions.
(If it had an effect, we'd want to add it to commands we get from a CDB)

llvm-svn: 319546

Added some commonly used Arm triples to the script, with and without
the -eabi suffix.

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

llvm-svn: 319545

Using numeric registers is flaky, since as soon as one additional
instruction is generated by us, all the tests need to be adapted.

llvm-svn: 319544