[InstCombine] simplify icmps with same operands based on dominating cmp

The tests here are based on the motivating cases from D54827.

More background:
1. We don't get these cases in general with SimplifyCFG because the root
   of the pattern match is an icmp, not a branch. I'm not sure how often
   we encounter this pattern vs. the seemingly more likely case with
   branches, but I don't see evidence to leave the minimal pattern
   unoptimized.

2. This has a chance of increasing compile-time because we're using a
   ValueTracking call to handle the match. The motivating cases could be
   handled with a simpler pair of calls to isImpliedTrueByMatchingCmp/
   isImpliedFalseByMatchingCmp, but I saw that we have a more
   comprehensive wrapper around those, so we might as well use it here
   unless there's evidence that it's significantly slower.

3. Ideally, we'd handle the fold to constants in InstSimplify, but as
   with the existing code here, we could extend this to handle cases
   where the result is not a constant, but a new combined predicate.
   That would mean splitting the logic across the 2 passes and possibly
   duplicating the pattern-matching cost.

4. As mentioned in D54827, this seems like the kind of thing that should
   be handled in Correlated Value Propagation, but that pass is currently
   limited to dealing with instructions with constant operands, so extending
   this bit of InstCombine is the smallest/easiest way to get these patterns
   optimized.

llvm-svn: 348367

[X86][SSE] Begun adding modulo rotate support to LowerRotate

Prep work for PR38243 - mainly adding comments on where we need to add modulo support (doing so at the moment causes massive codegen regressions).

I've also consistently added support for modulo folding for uniform constants (although at the moment we have no way to trigger this) and removed the old assertions.

llvm-svn: 348366

Move detection of libc++ include dirs to Driver on MacOS

Summary:
The intention is to make the tools replaying compilations from 'compile_commands.json'
(clang-tidy, clangd, etc.) find the same standard library as the original compiler
specified in 'compile_commands.json'.

Previously, the library detection logic was in the frontend (InitHeaderSearch.cpp) and relied
on the value of resource dir as an approximation of the compiler install dir. The new logic
uses the actual compiler install dir and is performed in the driver. This is consistent with
the C++ standard library detection on other platforms and allows to override the resource dir
in the tools using the compile_commands.json without altering the
standard library detection mechanism. The tools have to override the resource dir to make sure
they use a consistent version of the builtin headers.

There is still logic in InitHeaderSearch that attemps to add the absolute includes for the
the C++ standard library, so we keep passing the -stdlib=libc++ from the driver to the frontend
via cc1 args to avoid breaking that. In the long run, we should move this logic to the driver too,
but it could potentially break the library detection on other systems, so we don't tackle it in this
patch to keep its scope manageable.

This is a second attempt to fix the issue, first one was commited in r346652 and reverted in r346675.
The original fix relied on an ad-hoc propagation (bypassing the cc1 flags) of the install dir from the
driver to the frontend's HeaderSearchOptions. Unsurpisingly, the propagation was incomplete, it broke
the libc++ detection in clang itself, which caused LLDB tests to break.

The LLDB tests pass with new fix.

Reviewers: JDevlieghere, arphaman, EricWF

Reviewed By: arphaman

Subscribers: mclow.lists, ldionne, dexonsmith, ioeric, christof, kadircet, cfe-commits

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

llvm-svn: 348365

Revert: Honor -fdebug-prefix-map when creating function names for the debug info.

This commit reverts r348060 and r348062 due to it breaking the AArch64 Full
buildbot: https://bugs.llvm.org/show_bug.cgi?id=39892

llvm-svn: 348364

[llvm-rc] Support not expressions.

Patch by Jacek Caban!

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

llvm-svn: 348363

[TargetLowering] Remove ISD::ANY_EXTEND/ANY_EXTEND_VECTOR_INREG opcodes from SimplifyDemandedVectorElts

These have no test coverage and the KnownZero flags can't be guaranteed unlike SIGN/ZERO_EXTEND cases.

llvm-svn: 348361

[CMake] Fix side-effect from LLDB_VERSION change in r346668 for framework-enabled builds

llvm-svn: 348360

[clangd] Dont provide locations for non-existent files.

Summary:
We were getting assertion errors when we had bad file names, instead we
should skip those.

Reviewers: hokein

Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, cfe-commits

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

llvm-svn: 348359

[DAG] Add fshl/fshr tblgen opcodes

Missed off from https://reviews.llvm.org/D54698

llvm-svn: 348358

Fix compilation error when using clang 3.6.0

llvm-svn: 348357

[test] Disable Modules/prune.m on NetBSD as it requires 'touch -a'

llvm-svn: 348356

[test] Skip ThinLTO cache tests requiring atime setting on NetBSD

Skip the ThinLTO cache tests on NetBSD.  They require 'touch' being
able to alter atime of files, while NetBSD inhibits atime updates
when filesystem is mounted noatime.

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

llvm-svn: 348355

[test] Split strip-preserve-time.test, and skip atime test on NetBSD

Split timestamp preservation tests into atime and mtime test, and skip
the former on NetBSD.  When the filesystem is mounted noatime, NetBSD
not only inhibits implicit atime updates but also prevents setting atime
via utime(), causing the test to fail.

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

llvm-svn: 348354

[SelectionDAG] Initial support for FSHL/FSHR funnel shift opcodes (PR39467)

This is an initial patch to add a minimum level of support for funnel shifts to the SelectionDAG and to begin wiring it up to the X86 SHLD/SHRD instructions.

Some partial legalization code has been added to handle the case for 'SlowSHLD' where we want to expand instead and I've added a few DAG combines so we don't get regressions from the existing DAG builder expansion code.

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

llvm-svn: 348353

[clang] - Simplify tools::SplitDebugName.

This is an updated version of the D54576, which was reverted.

Problem was that SplitDebugName calls the InputInfo::getFilename
which asserts if InputInfo given is not of type Filename:

const char *getFilename() const {
  assert(isFilename() && "Invalid accessor.");
  return Data.Filename;
}
At the same time at that point, it can be of type Nothing and
we need to use getBaseInput(), like original code did.

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

llvm-svn: 348352

[MC] - Fix build bot.

Error was:
/home/buildslave/slave_as-bldslv8/lld-perf-testsuite/llvm/lib/MC/MCFragment.cpp:241:22: error: field 'Offset' will be initialized after field 'LayoutOrder' [-Werror,-Wreorder]
      Atom(nullptr), Offset(~UINT64_C(0)), LayoutOrder(0) {

http://lab.llvm.org:8011/builders/lld-perf-testsuite/builds/9628/steps/build-bin%2Flld/logs/stdio

llvm-svn: 348351

Remove superfluous comments. NFCI.

As requested in D54698.

llvm-svn: 348350

Recommit r348243 - "[llvm-mc] - Do not crash when referencing undefined debug sections."

The patch triggered an unrelated msan issue: LayoutOrder variable was not initialized.
(http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/26794/steps/check-llvm%20msan/logs/stdio)
It was fixed.

Original commit message:
MC has code that pre-creates few debug sections:
https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCObjectFileInfo.cpp#L396

If users code has a reference to such section but does not redefine it,
MC code currently asserts, because still thinks they are normally defined.

The patch fixes the issue.

Differential revision: https://reviews.llvm.org/D55173
----
Modified : /llvm/trunk/lib/MC/ELFObjectWriter.cpp
Added : /llvm/trunk/test/MC/ELF/undefined-debug.s

llvm-svn: 348349

[TargetLowering] SimplifyDemandedVectorElts - don't alter DemandedElts mask

Fix potential issue with the ISD::INSERT_VECTOR_ELT case tweaking the DemandedElts mask instead of using a local copy - so later uses of the mask use the tweaked version.....

Noticed while investigating adding zero/undef folding to SimplifyDemandedVectorElts and the altered DemandedElts mask was causing mismatches.

llvm-svn: 348348

[ARM GlobalISel] Implement call lowering for Thumb2

The only things that are different from arm are:
* different opcodes for calls and returns
* Thumb calls take predicate operands

llvm-svn: 348347

Revert r348335 "[XRay] Move-only Allocator, FunctionCallTrie, and Array"

.. and also the follow-ups r348336 r348338.

It broke stand-alone compiler-rt builds with GCC 4.8:

In file included from /work/llvm/projects/compiler-rt/lib/xray/xray_function_call_trie.h:20:0,
                 from /work/llvm/projects/compiler-rt/lib/xray/xray_profile_collector.h:21,
                 from /work/llvm/projects/compiler-rt/lib/xray/xray_profile_collector.cc:15:
/work/llvm/projects/compiler-rt/lib/xray/xray_segmented_array.h: In instantiation of ‘T* __xray::Array<T>::AppendEmplace(Args&& ...) [with Args = {const __xray::FunctionCallTrie::mergeInto(__xray::FunctionCallTrie&) const::NodeAndTarget&}; T = __xray::FunctionCallTrie::mergeInto(__xray::FunctionCallTrie&) const::NodeAndTarget]’:
/work/llvm/projects/compiler-rt/lib/xray/xray_segmented_array.h:383:71:   required from ‘T* __xray::Array<T>::Append(const T&) [with T = __xray::FunctionCallTrie::mergeInto(__xray::FunctionCallTrie&) const::NodeAndTarget]’
/work/llvm/projects/compiler-rt/lib/xray/xray_function_call_trie.h:517:54:   required from here
/work/llvm/projects/compiler-rt/lib/xray/xray_segmented_array.h:378:5: error: could not convert ‘{std::forward<const __xray::FunctionCallTrie::mergeInto(__xray::FunctionCallTrie&) const::NodeAndTarget&>((* & args#0))}’ from ‘<brace-enclosed initializer list>’ to ‘__xray::FunctionCallTrie::mergeInto(__xray::FunctionCallTrie&) const::NodeAndTarget’
     new (AlignedOffset) T{std::forward<Args>(args)...};
     ^
/work/llvm/projects/compiler-rt/lib/xray/xray_segmented_array.h: In instantiation of ‘T* __xray::Array<T>::AppendEmplace(Args&& ...) [with Args = {const __xray::profileCollectorService::{anonymous}::ThreadTrie&}; T = __xray::profileCollectorService::{anonymous}::ThreadTrie]’:
/work/llvm/projects/compiler-rt/lib/xray/xray_segmented_array.h:383:71:   required from ‘T* __xray::Array<T>::Append(const T&) [with T = __xray::profileCollectorService::{anonymous}::ThreadTrie]’
/work/llvm/projects/compiler-rt/lib/xray/xray_profile_collector.cc:98:34:   required from here
/work/llvm/projects/compiler-rt/lib/xray/xray_segmented_array.h:378:5: error: could not convert ‘{std::forward<const __xray::profileCollectorService::{anonymous}::ThreadTrie&>((* & args#0))}’ from
‘<brace-enclosed initializer list>’ to ‘__xray::profileCollectorService::{anonymous}::ThreadTrie’
/work/llvm/projects/compiler-rt/lib/xray/xray_segmented_array.h: In instantiation of ‘T* __xray::Array<T>::AppendEmplace(Args&& ...) [with Args = {const __xray::profileCollectorService::{anonymous}::ProfileBuffer&}; T = __xray::profileCollectorService::{anonymous}::ProfileBuffer]’:
/work/llvm/projects/compiler-rt/lib/xray/xray_segmented_array.h:383:71:   required from ‘T* __xray::Array<T>::Append(const T&) [with T = __xray::profileCollectorService::{anonymous}::ProfileBuffer]
’
/work/llvm/projects/compiler-rt/lib/xray/xray_profile_collector.cc:244:44:   required from here
/work/llvm/projects/compiler-rt/lib/xray/xray_segmented_array.h:378:5: error: could not convert ‘{std::forward<const __xray::profileCollectorService::{anonymous}::ProfileBuffer&>((* & args#0))}’ from ‘<brace-enclosed initializer list>’ to ‘__xray::profileCollectorService::{anonymous}::ProfileBuffer’

> Summary:
> This change makes the allocator and function call trie implementations
> move-aware and remove the FunctionCallTrie's reliance on a
> heap-allocated set of allocators.
>
> The change makes it possible to always have storage associated with
> Allocator instances, not necessarily having heap-allocated memory
> obtainable from these allocator instances. We also use thread-local
> uninitialised storage.
>
> We've also re-worked the segmented array implementation to have more
> precondition and post-condition checks when built in debug mode. This
> enables us to better implement some of the operations with surrounding
> documentation as well. The `trim` algorithm now has more documentation
> on the implementation, reducing the requirement to handle special
> conditions, and being more rigorous on the computations involved.
>
> In this change we also introduce an initialisation guard, through which
> we prevent an initialisation operation from racing with a cleanup
> operation.
>
> We also ensure that the ThreadTries array is not destroyed while copies
> into the elements are still being performed by other threads submitting
> profiles.
>
> Note that this change still has an issue with accessing thread-local
> storage from signal handlers that are instrumented with XRay. We also
> learn that with the testing of this patch, that there will be cases
> where calls to mmap(...) (through internal_mmap(...)) might be called in
> signal handlers, but are not async-signal-safe. Subsequent patches will
> address this, by re-using the `BufferQueue` type used in the FDR mode
> implementation for pre-allocated memory segments per active, tracing
> thread.
>
> We still want to land this change despite the known issues, with fixes
> forthcoming.
>
> Reviewers: mboerger, jfb
>
> Subscribers: jfb, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D54989

llvm-svn: 348346

[LICM] *Actually* disable ControlFlowHoisting.

Summary:
The remaining code paths that ControlFlowHoisting introduced that were
not disabled, increased compile time by 3x for some benchmarks.
The time is spent in DominatorTree updates.

Reviewers: john.brawn, mkazantsev

Subscribers: sanjoy, jlebar, llvm-commits

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

llvm-svn: 348345

Revert "[clang-tidy] new check: bugprone-branch-clone"

The patch broke on buildbot with assertion-failure. Revert until this
is figured out.

llvm-svn: 348344

[clang-tidy] new check: bugprone-branch-clone

Summary:
Implement a check for detecting if/else if/else chains where two or more
branches are Type I clones of each other (that is, they contain identical code)
and for detecting switch statements where two or more consecutive branches are
Type I clones of each other.

Patch by donat.nagy.

Reviewers: alexfh, hokein, aaron.ballman, JonasToth

Reviewed By: JonasToth

Subscribers: MTC, lebedev.ri, whisperity, xazax.hun, Eugene.Zelenko, mgorny, rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang-tools-extra

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

llvm-svn: 348343

HowToBuildWithPGO.rst: Fix a few details in the manual steps

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

llvm-svn: 348342

Fix a false positive in misplaced-widening-cast

Summary:
bugprone-misplaced-widening-cast check
used to give a false warning to the
following example.

 enum DaysEnum{
    MON = 0,
    TUE = 1
    };

 day = (DaysEnum)(day + 1);
 //warning: either cast from 'int' to 'DaysEnum' is ineffective...

But i think int to enum cast is not widening neither ineffective.

Patch by dkrupp.

Reviewers: JonasToth, alexfh

Reviewed By: alexfh

Subscribers: rnkovacs, Szelethus, gamesh411, cfe-commits

Tags: #clang-tools-extra

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

llvm-svn: 348341

[X86] Remove -costmodel-reduxcost=true from the experimental vector reduction intrinsic tests as it appears to be unnecessary. NFC

I think this has something to do with matching reductions from extractelement, binops, and shuffles. But we're not matching here.

llvm-svn: 348340

[X86] Add more cost model tests for vector reductions with narrow vector types. NFC

llvm-svn: 348339

[XRay] Use uptr instead of uintptr_t

Follow-up to D54989.

llvm-svn: 348338

AArch64: support funclets in fastcall and swift_call

Functions annotated with `__fastcall` or `__attribute__((__fastcall__))`
or `__attribute__((__swiftcall__))` may contain SEH handlers even on
Win64.  This matches the behaviour of cl which allows for
`__try`/`__except` inside a `__fastcall` function.  This was detected
while trying to self-host clang on Windows ARM64.

llvm-svn: 348337

[XRay] Use deallocateBuffer instead of deallocate

Follow-up to D54989.

llvm-svn: 348336

[XRay] Move-only Allocator, FunctionCallTrie, and Array

Summary:
This change makes the allocator and function call trie implementations
move-aware and remove the FunctionCallTrie's reliance on a
heap-allocated set of allocators.

The change makes it possible to always have storage associated with
Allocator instances, not necessarily having heap-allocated memory
obtainable from these allocator instances. We also use thread-local
uninitialised storage.

We've also re-worked the segmented array implementation to have more
precondition and post-condition checks when built in debug mode. This
enables us to better implement some of the operations with surrounding
documentation as well. The `trim` algorithm now has more documentation
on the implementation, reducing the requirement to handle special
conditions, and being more rigorous on the computations involved.

In this change we also introduce an initialisation guard, through which
we prevent an initialisation operation from racing with a cleanup
operation.

We also ensure that the ThreadTries array is not destroyed while copies
into the elements are still being performed by other threads submitting
profiles.

Note that this change still has an issue with accessing thread-local
storage from signal handlers that are instrumented with XRay. We also
learn that with the testing of this patch, that there will be cases
where calls to mmap(...) (through internal_mmap(...)) might be called in
signal handlers, but are not async-signal-safe. Subsequent patches will
address this, by re-using the `BufferQueue` type used in the FDR mode
implementation for pre-allocated memory segments per active, tracing
thread.

We still want to land this change despite the known issues, with fixes
forthcoming.

Reviewers: mboerger, jfb

Subscribers: jfb, llvm-commits

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

llvm-svn: 348335

[X86] Add narrow vector test cases to vector-reduce* tests. Add copies of the tests with -x86-experimental-vector-widening-legalization

llvm-svn: 348334

[NFC] Verify memoryssa in test for PR39783

llvm-svn: 348333

gdb-remote: use elaborated type specifier for `Module`

When building with MSVC, the type `Module` is ambiguous due to both the
lldb_private and llvm namespaces being used.  Use the elaborated type
instead to resolve the ambiguity.

llvm-svn: 348332

[clang-tidy/checks] Update objc-property-declaration check to allow arbitrary acronyms and initialisms 🔧

Summary:
§1 Description

This changes the objc-property-declaration check to allow arbitrary acronyms and initialisms instead of using whitelisted acronyms. In Objective-C it is relatively common to use project prefixes in property names for the purposes of disambiguation. For example, the CIColor¹ and CGColor² properties on UIColor both represent symbol prefixes being used in proeprty names outside of Apple's accepted acronyms³. The union of Apple's accepted acronyms and all symbol prefixes that might be used for disambiguation in property declarations effectively allows for any arbitrary sequence of capital alphanumeric characters to be acceptable in property declarations. This change updates the check accordingly.

The test variants with custom configurations are deleted as part of this change because their configurations no longer impact behavior. The acronym configurations are currently preserved for backwards compatibility of check configuration.

[1] https://developer.apple.com/documentation/uikit/uicolor/1621951-cicolor?language=objc
[2] https://developer.apple.com/documentation/uikit/uicolor/1621954-cgcolor?language=objc
[3] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/APIAbbreviations.html#//apple_ref/doc/uid/20001285-BCIHCGAE

§2 Test Notes

Changes verified by:
• Running clang-tidy unit tests.
• Used check_clang_tidy.py to verify expected output of processing objc-property-declaration.m

Reviewers: benhamilton, Wizard

Reviewed By: benhamilton

Subscribers: jfb, cfe-commits

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

llvm-svn: 348331

[MachineLICM][X86][AMDGPU] Fix subtle bug in the updating of PhysRegClobbers in post-RA LICM

It looks like MCRegAliasIterator can visit the same physical register twice. When this happens in this code in LICM we end up setting the PhysRegDef and then later in the same loop visit the register again. Now we see that PhysRegDef is set from the earlier iteration so now set PhysRegClobber.

This patch splits the loop so we have one that uses the previous value of PhysRegDef to update PhysRegClobber and second loop that updates PhysRegDef.

The X86 atomic test is an improvement. I had to add sideeffect to the two shrink wrapping tests to prevent hoisting from occurring. I'm not sure about the AMDGPU tests. It looks like the branch instruction changed at end the of the loops. And in the branch-relaxation test I think there is now "and vcc, exec, -1" instruction that wasn't there before.

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

llvm-svn: 348330

Update GET_LINK_MAP_BY_DLOPEN_HANDLE() for NetBSD x86

NetBSD 8.99.26 changed the layout of internal structure
returned by dlopen(3), switch to it.

Set new values for amd64 and i386 based on the results
of &((struct Struct_Obj_Entry*)0)->linkmap.

llvm-svn: 348329

[clang-query] Continue if compilation command not found for some files

When searching for a code pattern in an entire project with a
compilation database it's tempting to run

```
clang-query **.cpp
```

And yet, that often breaks because some files are just not in the
compilation database: tests, sample code, etc..
clang-query should not stop when encountering such cases.

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

llvm-svn: 348328

[asan] Add clang flag -fsanitize-address-use-odr-indicator

Reviewers: eugenis, m.ostapenko, ygribov

Subscribers: hiraditya, llvm-commits

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

llvm-svn: 348327

[TableGen] Preserve order of output operands in DAGISelMatcherGen

Summary:
This fixes support in DAGISelMatcher backend for DAG nodes with multiple
result values. Previously the order of results in selected DAG nodes always
matched the order of results in ISel patterns. After the change the order of
results matches the order of operands in OutOperandList instead.

For example, given this definition from the attached test case:

  def INSTR : Instruction {
    let OutOperandList = (outs GPR:$r1, GPR:$r0);
    let InOperandList = (ins GPR:$t0, GPR:$t1);
    let Pattern = [(set i32:$r0, i32:$r1, (udivrem i32:$t0, i32:$t1))];
  }

the DAGISelMatcher backend currently produces a matcher that creates INSTR
nodes with the first result `$r0` and the second result `$r1`, contrary to the
order in the OutOperandList. The order of operands in OutOperandList does not
matter at all, which is unexpected (and unfortunate) because the order of
results of a DAG node does matters, perhaps a lot.

With this change, if the order in OutOperandList does not match the order in
Pattern, DAGISelMatcherGen emits CompleteMatch opcodes with the order of
results taken from OutOperandList. Backend writers can use it to express
result reorderings in TableGen.

If the order in OutOperandList matches the order in Pattern, the result of
DAGISelMatcherGen is unaffected.

Patch by Eugene Sharygin

Reviewers: andreadb, bjope, hfinkel, RKSimon, craig.topper

Reviewed By: craig.topper

Subscribers: nhaehnle, craig.topper, llvm-commits

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

llvm-svn: 348326

[Sema] Remove some conditions of a failing assert

We should have been checking that this state is consistent, but its
possible for it to be filled later, so it isn't really sound to check
it here anyways.

Fixes llvm.org/PR39742

llvm-svn: 348325

[SelectionDAG] Split very large token factors for loads into 64k chunks.

There's a 64k limit on the number of SDNode operands, and some very large
functions with 64k or more loads can cause crashes due to this limit being hit
when a TokenFactor with this many operands is created. To fix this, create
sub-tokenfactors if we've exceeded the limit.

No test case as it requires a very large function.

rdar://45196621

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

llvm-svn: 348324

[ADT] Add zip_longest iterators.

Like the already existing zip_shortest/zip_first iterators, zip_longest
iterates over multiple iterators at once, but has as many iterations as
the longest sequence.

This means some iterators may reach the end before others do.
zip_longest uses llvm::Optional's None value to mark a
past-the-end value.

zip_longest is not reverse-iteratable because the tuples iterated over
would be different for different length sequences (IMHO for the same
reason neither zip_shortest nor zip_first should be reverse-iteratable;
one can still reverse the ranges individually if that's the expected
behavior).

In contrast to zip_shortest/zip_first, zip_longest tuples contain
rvalues instead of references. This is because llvm::Optional cannot
contain reference types and the value-initialized default does not have
a memory location a reference could point to.

The motivation for these iterators is to use C++ foreach to compare two
lists of ordered attributes in D48100 (SemaOverload.cpp and
ASTReaderDecl.cpp).

Idea by @hfinkel.

This re-commits r348301 which was reverted by r348303.
The compilation error by gcc 5.4 was resolved using make_tuple in the in
the initializer_list.
The compileration error by msvc14 was resolved by splitting
ZipLongestValueType (which already was a workaround for msvc15) into
ZipLongestItemType and ZipLongestTupleType.

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

llvm-svn: 348323

LTO: Don't internalize available_externally globals.

This breaks C and C++ semantics because it can cause the address
of the global inside the module to differ from the address outside
of the module.

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

llvm-svn: 348321

[AArch64][GlobalISel] Re-enable selection of volatile loads.

We previously disabled this in r323371 because of a bug where we selected an
extending load, but didn't delete the old G_LOAD, resulting in two loads being
generated for volatile loads.

Since we now have dedicated G_SEXTLOAD/G_ZEXTLOAD operations, and that the
tablegen patterns should no longer be able to select (ext(load x)) patterns, it
should be safe to re-enable it.

The old test case should still work as expected.

llvm-svn: 348320

[build.py] Disable tests on non-Windows.

This won't work until we get the GCC / clang builder implemented.

llvm-svn: 348319

Remove the hash code from CVRecord.

This is no longer used and is just taking up space in the structure.
Heap allocation of this structure is on the critical path, so space
actually matters.

llvm-svn: 348318

[clang-tidy] Ignore namespaced and C++ member functions in google-objc-function-naming check 🙈

Summary: The google-objc-function-naming check applies to functions that are not namespaced and should not be applied to C++ member functions. Such function declarations should be ignored by the check to avoid false positives in Objective-C++ sources.

Reviewers: benhamilton, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: xazax.hun, cfe-commits

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

llvm-svn: 348317

[asan] Split -asan-use-private-alias to -asan-use-odr-indicator

Reviewers: eugenis, m.ostapenko, ygribov

Subscribers: mehdi_amini, kubamracek, hiraditya, steven_wu, dexonsmith, llvm-commits

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

llvm-svn: 348316

[asan] Remove use_odr_indicator runtime flag

Summary:
Flag was added for testing 3 years ago. Probably it's time
to simplify code and usage by removing it.

Reviewers: eugenis, m.ostapenko

Subscribers: mehdi_amini, kubamracek, steven_wu, dexonsmith, llvm-commits

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

llvm-svn: 348315

Fix LLDB build script.

A local patch was omitted from the original commit.  This makes
the tests pass.

llvm-svn: 348314

Fix crash if an in-class explicit function specialization has explicit
template arguments referring to template paramaeters.

llvm-svn: 348313

[InstCombine] add tests for implied simplifications; NFC

Ideally, we would fold all of these in InstSimplify in a
similar way to rL347896, but this is a bit awkward when
we're trying to simplify a compare directly because the
ValueTracking API expects the compare as an input, but
in InstSimplify, we just have the operands of the compare.

Given that we can do transforms besides just simplifications,
we might as well just extend the code in InstCombine (which
already does simplifications with constant operands).

llvm-svn: 348312

[ELF] Simplify getSectionPiece

Reviewers: ruiu, espindola

Reviewed By: ruiu

Subscribers: grimar, emaste, arichardson, llvm-commits

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

llvm-svn: 348311

AArch64: clean up some whitespace in Windows CC (NFC)

Drive by clean up for Windows ARM64 variadic CC (NFC).

llvm-svn: 348310

Adding tests for -ast-dump; NFC.

This adds tests for the definition data of C++ record objects as well as special member functions.

llvm-svn: 348309

Add tests for dumping base classes; NFC.

llvm-svn: 348308

[llvm-pdbutil] Remove the analyze subcommand.

Nobody has used this since it was introduced, and it doesn't have
test coverage.

llvm-svn: 348307

[PDB] Emit S_UDT records in LLD.

Previously these were dropped.  We now understand them sufficiently
well to start emitting them.  From the debugger's perspective, this
now enables us to have debug info about typedefs (both global and
function-locally scoped)

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

llvm-svn: 348306

[build.py] A few general improvements.

This makes -mode=compile support multiple inputs (and hence
multiple outputs).

It also makes the value of -arch for compiling inferiors default
to the architecture that LLDB is built in.  This can still be
overridden however.

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

llvm-svn: 348305

[AVR] Silence fallthrough warning. NFC.

llvm-svn: 348304

Revert "[ADT] Add zip_longest iterators"

This reverts commit r348301.

Compilation fails on buildbots with older versions of gcc and msvc.

llvm-svn: 348303

[Documentation] Make options section in Clang-tidy readability-uppercase-literal-suffix consistent with other checks.

llvm-svn: 348302

[ADT] Add zip_longest iterators

Like the already existing zip_shortest/zip_first iterators, zip_longest
iterates over multiple iterators at once, but has as many iterations as
the longest sequence.

This means some iterators may reach the end before others do.
zip_longest uses llvm::Optional's None value to mark a
past-the-end value.

zip_longest is not reverse-iteratable because the tuples iterated over
would be different for different length sequences (IMHO for the same
reason neither zip_shortest nor zip_first should be reverse-iteratable;
one can still reverse the ranges individually if that's the expected
behavior).

In contrast to zip_shortest/zip_first, zip_longest tuples contain
rvalues instead of references. This is because llvm::Optional cannot
contain reference types and the value-initialized default does not have
a memory location a reference could point to.

The motivation for these iterators is to use C++ foreach to compare two
lists of ordered attributes in D48100 (SemaOverload.cpp and
ASTReaderDecl.cpp).

Idea by @hfinkel.

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

llvm-svn: 348301

Add SBInitializerOptions.cpp.

llvm-svn: 348300

[PowerPC] Make no-PIC default to match GCC - CLANG

Make -fno-PIC default on PowerPC LE.

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

llvm-svn: 348299

[PowerPC] Make no-PIC default to match GCC - LLVM

Change the default for PowerPC LE to -fno-PIC.

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

llvm-svn: 348298

Fix sanitizer unit test

llvm-svn: 348297

[libcxx] Always enable availability in the lit test suite.

Summary:
Running the tests without availability enabled doesn't really make sense:
availability annotations allow catching errors at compile-time instead
of link-time. Running the tests without availability enabled allows
confirming that a test breaks at link-time under some configuration,
but it is more useful to instead check that it should fail at compile-time.

Always enabling availability in the lit test suite will greatly simplify
XFAILs and troubleshooting of failing tests, which is currently a giant
pain because we have these two levels of possible failure: link-time and
compile-time.

Reviewers: EricWF, mclow.lists

Subscribers: christof, jkorous, dexonsmith, libcxx-commits

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

llvm-svn: 348296

Unbreak build due to style.

llvm-svn: 348295

Remove unreachable code.

llvm-svn: 348294

[Sanitizer] intercept part of sysctl Api

- Distringuish what FreeBSD/NetBSD can and NetBSD specifics.
- Fixing page size value collection.

Reviewers: krytarowski, vitalybuka

Reviewed By: krytarowski

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

llvm-svn: 348293

[CmpInstAnalysis] fix function signature for ICmp code to predicate; NFC

The old function underspecified the return type, took an unused parameter,
and had a misleading name.

llvm-svn: 348292

ELF: allow non allocated sections to go into allocated sections

Patch from Andrew Kelley.

For context, see https://bugs.llvm.org/show_bug.cgi?id=39862

The use case is embedded / OS programming where the kernel wants
access to its own debug info via mapped dwarf info. I have a proof of
concept of this working, using this linker script snippet:

  .rodata : ALIGN(4K) {
    *(.rodata)
    __debug_info_start = .;
    KEEP(*(.debug_info))
    __debug_info_end = .;
    __debug_abbrev_start = .;
    KEEP(*(.debug_abbrev))
    __debug_abbrev_end = .;
    __debug_str_start = .;
    KEEP(*(.debug_str))
    __debug_str_end = .;
    __debug_line_start = .;
    KEEP(*(.debug_line))
    __debug_line_end =
    .;
    __debug_ranges_start
    = .;
    KEEP(*(.debug_ranges))
    __debug_ranges_end
    = .;
  }

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

llvm-svn: 348291

Move llc-start-stop-instance to x86

Avoid bot failures where the host pass
setup might not have 2 dead-mi-elimination runs

llvm-svn: 348290

[Reproducers] Only creaate the bottom-most dir

As Pavel noted on the mailing list we should only create the bottom-most
directory if it doesn't exist. This should also fix the test case on
Windows as we can use lit's temp directory.

llvm-svn: 348289

[SelectionDAG] Redefine isGAPlusOffset in terms of unwrapAddress. NFCI.

llvm-svn: 348288

[FileSystem] Migrate CommandCompletions

Make use of the convenience helpers from FileSystem.

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

llvm-svn: 348287

AMDGPU: Add f32 vectors to SGPR register classes

llvm-svn: 348286

MIR: Add method to stop after specific runs of passes

Currently if you use -{start,stop}-{before,after}, it picks
the first instance with the matching pass name. If you run
the same pass multiple times, there's no way to distinguish them.

Allow specifying a run index wih ,N to specify which you mean.

llvm-svn: 348285

[InstCombine] rearrange foldICmpWithDominatingICmp; NFC

Move it out from under the constant check, reorder
predicates, add comments. This makes it easier to
extend to handle the non-constant case.

llvm-svn: 348284

[dsymutil] Ensure we're comparing time stamps with the same precision.

After TimePoint's precision was increased in LLVM we started seeing
failures because the modification times didn't match. This adds a time
cast to ensure that we're comparing TimePoints with the same amount of
precision.

llvm-svn: 348283

[X86][SSE] Add SimplifyDemandedBitsForTargetNode handling for MOVMSK

Moves existing SimplifyDemandedBits call out of combineMOVMSK and add SimplifyDemandedVectorElts call based on the sign bits we need.

llvm-svn: 348282

[AST] Assert that no type class is polymorphic

Add a static_assert checking that no type class is polymorphic.
People should use LLVM style RTTI instead.

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

Reviewed By: aaron.ballman

llvm-svn: 348281

Revert "Avoid emitting redundant or unusable directories in DIFile metadata entries."

This reverts commit r348154 and follow-up commits r348211 and r3248213.
Reason: the original commit broke compiler-rt tests and a follow-up fix
(r348203) broke our integrate and was reverted.

llvm-svn: 348280

Revert "Adapt gcov to changes in CFE."

This reverts commit r348203.
Reason: this produces absolute paths in .gcno files, breaking us
internally as we rely on them being consistent with the filenames passed
in the command line.

Also reverts r348157 and r348155 to account for revert of r348154 in
clang repository.

llvm-svn: 348279

[AST] Assert that no statement/expression class is polymorphic

Add a static_assert checking that no statement/expression class
is polymorphic. People should use LLVM style RTTI instead.

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

Reviewed By: aaron.ballman

llvm-svn: 348278

[X86][SSE] Add MOVMSK demandedbits/elts tests

llvm-svn: 348277

[AST][NFC] Make ArrayTypeTraitExpr non polymorphic

ArrayTypeTraitExpr is the only expression class which is polymorphic.
As far as I can tell this is completely pointless.

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

Reviewed By: aaron.ballman

llvm-svn: 348276

[Hexagon] Update builtin definitions

llvm-svn: 348275

[InstCombine] auto-generate full checks for icmp overflow tests; NFC

llvm-svn: 348274

[InstCombine] add helper for icmp with dominator; NFC

There's a potential small enhancement to this code that could
solve the cases currently under proposal in D54827 via SimplifyCFG.

Whether instcombine should be doing this kind of semi-non-local
analysis in the first place is an open question, but separating
the logic out can only help if/when we decide to move it to a
different pass.

AFAICT, any proposal to do this in SimplifyCFG could also be seen
as an overreach + it would be incomplete to start the fold from a
branch rather than an icmp.

There's another question here about the code for processUGT_ADDCST_ADD().
That part may be completely dead after rL234638 ?

llvm-svn: 348273

[OPENMP][NVPTX]Fixed emission of the critical region.

Critical regions in NVPTX are the constructs, which, generally speaking,
are not supported by the NVPTX target. Instead we're using special
technique to handle the critical regions. Currently they are supported
only within the loop and all the threads in the loop must execute the
same critical region.
Inside of this special regions the regions still must be emitted as
critical, to avoid possible data races between the teams +
synchronization must use __kmpc_barrier functions.

llvm-svn: 348272

[OPENMP][NVPTX]Mark __kmpc_barrier functions as convergent.

__kmpc_barrier runtime functions must be marked as convergent to prevent
some dangerous optimizations. Also, for NVPTX target all barriers must
be emitted as simple barriers.

llvm-svn: 348271

[InstCombine] auto-generate full checks for icmp dominator tests; NFC

llvm-svn: 348270

[Hexagon] Remove unused checker functions from asm parser

llvm-svn: 348269

Remove reference to recently removed PTH Documentation.

Removed in r348266

Change-Id: Icff0212f57c42ca84ec174ddd4366ae63a7923fa
llvm-svn: 348268

[SimpleLoopUnswitch] Remove debug dump.

llvm-svn: 348267

PTH-- Remove feature entirely-

When debugging a boost build with a modified
version of Clang, I discovered that the PTH implementation
stores TokenKind in 8 bits. However, we currently have 368
TokenKinds.

The result is that the value gets truncated and the wrong token
gets picked up when including PTH files. It seems that this will
go wrong every time someone uses a token that uses the 9th bit.

Upon asking on IRC, it was brought up that this was a highly
experimental features that was considered a failure. I discovered
via googling that BoostBuild (mostly Boost.Math) is the only user of
this
feature, using the CC1 flag directly. I believe that this can be
transferred over to normal PCH with minimal effort:
https://github.com/boostorg/build/issues/367

Based on advice on IRC and research showing that this is a nearly
completely unused feature, this patch removes it entirely.

Note: I considered leaving the build-flags in place and making them
emit an error/warning, however since I've basically identified and
warned the only user, it seemed better to just remove them.

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

Change-Id: If32744275ef1f585357bd6c1c813d96973c4d8d9
llvm-svn: 348266