[NFC][libc++] Reindent #ifdefs

I don't understand why we don't always do that. We do it for normal `if`s
in the code, but not for preprocessor `if`s? It's a lot more readable when
indented properly.

llvm-svn: 356693

[llvm-pdbutil] Add -type-ref-stats to help find unused type info

Summary:
This considers module symbol streams and the global symbol stream to be
roots. Most types that this considers "unreferenced" are referenced by
LF_UDT_MOD_SRC_LINE id records, which VC seems to always include.
Essentially, they are types that the user can only find in the debugger
if they call them by name, they cannot be found by traversing a symbol.

In practice, around 80% of type information in a PDB is referenced by a
symbol. That seems like a reasonable number.

I don't really plan to do anything with this tool. It mostly just exists
for informational purposes, and to confirm that we probably don't need
to implement type reference tracking in LLD. We can continue to merge
all types as we do today without wasting space.

Reviewers: zturner, aganea

Subscribers: mgorny, hiraditya, arphaman, jdoerfert, llvm-commits

Tags: #llvm

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

llvm-svn: 356692

[x86] add tests with movmsk potential (PR39665); NFC

llvm-svn: 356691

[InstCombine] Don't transform ((C1 OP zext(X)) & C2) -> zext((C1 OP X) & C2) if either zext or OP has another use.

If they have other users we'll just end up increasing the instruction count.

We might be able to weaken this to only one of them having a single use if we can prove that the and will be removed.

Fixes PR41164.

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

llvm-svn: 356690

[X86] Add __popcntd and __popcntq to ia32intrin.h to match gcc and icc. Remove popcnt feature flag from _popcnt32/_popcnt64 and move to ia32intrin.h to match gcc

gcc and icc both implement popcntd and popcntq which we did not. gcc doesn't seem to require a feature flag for the _popcnt32/_popcnt64 spelling and will use a libcall if its not supported.

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

llvm-svn: 356689

[X86] Don't avoid folding multiple use sign extended 8-bit immediate into instructions under optsize.

Under optsize we try to avoid folding immediates into instructions under optsize. But if the immediate is 16-bits or 32 bits, but can be encoded as an 8-bit immediate we don't save enough from disabling the folding unless the immediate has enough uses to make up for the size of the move which is either 3 bytes or 5 bytes since there are no sign extended 8-bit moves. We would also save something if the immediate was a live out of the basic block and thus a move was unavoidable, but that would require a more advanced heuristic than just counting uses.

Note we only avoid folding multiple use immediates into the patterns that use X86ISD::ADD/SUB/XOR/OR/AND/CMP/ADC/SBB nodes and not the more common ISD::ADD/SUB/XOR/OR/AND nodes.

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

llvm-svn: 356688

[ScalarizeMaskedMemIntrin] Add support for scalarizing expandload and compressstore intrinsics.

This adds support for scalarizing these intrinsics as well the X86TargetTransformInfo support to avoid scalarizing them in the cases X86 can handle.

I've omitted handling special cases for constant masks for this first pass. Though CodeGenPrepare can constant fold the branch conditions and remove some of the control flow anyway.

Fixes PR40994 and is covers most of PR3666. Might want to implement constant masks to close that.

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

llvm-svn: 356687

[X86] Use the CPUKind enum from PROC_ALIAS to directly get the CPUKind in fillValidCPUList.

We were using getCPUKind which translates the string to the enum also using PROC_ALIAS. This just cuts out the string compares.

llvm-svn: 356686

[ValueTracking] Use ConstantRange based overflow check for signed sub

This is D59450, but for signed sub. This case is not NFC, because
the overflow logic in ConstantRange is more powerful than the existing
check. This resolves the TODO in the function.

I've added two tests to show that this indeed catches more cases than
the previous logic, but the main correctness test coverage here is in
the existing ConstantRange unit tests.

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

llvm-svn: 356685

[ELF][ARM] Revert Redesign of .ARM.exidx handling to use a SyntheticSection

There is a reproducible buildbot failure (segfault) on the 2 stage
clang-cmake-armv8-lld bot. Reverting while I investigate.

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

llvm-svn: 356684

Add more rotate tests, including ORs of rotates

This is a part of https://reviews.llvm.org/D47735.

llvm-svn: 356683

Move the rest of the sections over to DWARFContext.

This is mostly mechanical, and just moves the remaining non-DWO
related sections over to DWARFContext.

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

llvm-svn: 356682

[libc++] Re-document how to use <filesystem> with various versions of libc++

This documentation was removed when we added <filesystem> to the dylib
in r356518, but it really should have been updated to reflect the new
state of things. Keeping documentation around doesn't hurt and users
will have an easier time migrating.

llvm-svn: 356681

Add relational benchmark against a string constant.

Summary:
Add relational benchmark against a string constant.
These can potentially trigger inlining of the operations. We want to
benchmark that.

Reviewers: EricWF

Subscribers: christof, jdoerfert, libcxx-commits

Tags: #libc

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

llvm-svn: 356680

[AST] OMPStructuredBlockTest: two matchers were promoted into ASTMatchers.h

llvm-svn: 356679

[libc++] Mark bad_any_cast tests as unsupported when the dylib doesn't support bad_any_cast

With the latest compiler fix to availability, some availability failures
that didn't trigger before now trigger.

llvm-svn: 356678

[ASTMatcher] Add clang-query disclaimer to two more matchers that take enum

As we have figured out in
https://reviews.llvm.org/D57112
and
https://bugs.llvm.org/show_bug.cgi?id=41176

this kind-of works, but needs special care.

llvm-svn: 356677

[ASTMatchers][OpenMP] OpenMP Structured-block-related matchers

Summary: Exposes to the  for ASTMatchers the interface/modelling
of OpenMP structured-block.

Reviewers: gribozavr, aaron.ballman, JonasToth, george.karpenkov

Reviewed By: gribozavr, aaron.ballman

Subscribers: guansong, jdoerfert, cfe-commits

Tags: #clang, #openmp

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

llvm-svn: 356676

[ASTTypeTraits][ASTMatchers][OpenMP] OMPClause handling

Summary:
`OMPClause` is the base class, it is not descendant from **any**
other class, therefore for it to work with e.g.
`VariadicDynCastAllOfMatcher<>`, it needs to be handled here.

Reviewers: sbenza, bkramer, pcc, klimek, hokein, gribozavr, aaron.ballman, george.karpenkov

Reviewed By: gribozavr, aaron.ballman

Subscribers: guansong, jdoerfert, alexfh, ABataev, cfe-commits

Tags: #openmp, #clang

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

llvm-svn: 356675

[ASTMatchers][OpenMP] Add base ompExecutableDirective() matcher.

Summary:
A simple matcher for `OMPExecutableDirective` Stmt type.
Split off from D57113.

Reviewers: gribozavr, aaron.ballman, JonasToth, george.karpenkov

Reviewed By: gribozavr, aaron.ballman

Subscribers: guansong, jdoerfert, cfe-commits

Tags: #clang

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

llvm-svn: 356674

Workaround items/iteritems difference between Python2 and Python3

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

llvm-svn: 356673

Workaround Python's map difference between Python2/3

When the output of map is not used, using a list comprehension or an explicit
call to list looks awkward.

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

llvm-svn: 356672

Portable int/long conversion across Python 2 / Python 3

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

llvm-svn: 356671

Portable exception value access across Python 2 / Python 3

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

llvm-svn: 356670

Fixup opt-remarks.ll gold plugin test. NFC

Now that rL356594 has added a TailCallElim pass to LTO, the call gets marked as
tail.

llvm-svn: 356669

[DAGCombiner] Use getTokenFactor in a few more cases.

SDNodes can only have 64k operands and for some inputs (e.g. large
number of stores), we can reach this limit when creating TokenFactor
nodes. This patch is a follow up to D56740 and updates a few more places
that potentially can create TokenFactors with too many operands.

Reviewers: efriedma, craig.topper, aemerson, RKSimon

Reviewed By: RKSimon

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

llvm-svn: 356668

[DAGCombine] SimplifySelectCC - call FoldSetCC with the setcc result type

We were calling FoldSetCC with the compare operand type instead of the result type.

Found by OSS-Fuzz #13838 (https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13838)

llvm-svn: 356667

[ELF][ARM] Redesign of .ARM.exidx handling to use a SyntheticSection

Instead of creating extra Synthetic .ARM.exidx sections to account for
gaps in the table, create a single .ARM.exidx SyntheticSection that can
derive the contents of the gaps from a sorted list of the executable
InputSections. This has the benefit of moving the ARM specific code for
SyntheticSections in SHF_LINK_ORDER processing and the table merging code
into the ARM specific SyntheticSection. This also makes it easier to create
EXIDX_CANTUNWIND table entries for executable InputSections that don't
have an associated .ARM.exidx section.

Fixes pr40277

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

llvm-svn: 356666

[CodeGenPrepare] limit formation of overflow intrinsics (PR41129)

This is probably a bigger limitation than necessary, but since we don't have any evidence yet
that this transform led to real-world perf improvements rather than regressions, I'm making a
quick, blunt fix.

In the motivating x86 example from:
https://bugs.llvm.org/show_bug.cgi?id=41129
...and shown in the regression test, we want to avoid an extra instruction in the dominating
block because that could be costly.

The x86 LSR test diff is reversing the changes from D57789. There's no evidence that 1 version
is any better than the other yet.

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

llvm-svn: 356665

[llvm-readobj] Format codes. NFC.

llvm-svn: 356664

Permit redeclarations of a builtin to specify calling convention.

After https://reviews.llvm.org/rL355317 we noticed that quite a decent
amount of code redeclares builtins (memcpy in particular, I believe
reduced from an MSVC header) with a calling convention specified.
This gets particularly troublesome when the user specifies a new
'default' calling convention on the command line.

When looking to add a diagnostic for this case, it was noticed that we
had 3 other diagnostics that differed only slightly.  This patch ALSO
unifies those under a 'select'.  Unfortunately, the order of words in
ONE of these diagnostics was reversed ("'thiscall' calling convention"
vs "calling convention 'thiscall'"), so this patch also standardizes on
the former.

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

Change-Id: I79f99fe7c2301640755ffdd774b46eb44526bb22
llvm-svn: 356663

[clang-format] Add basic support for formatting C# files

Summary:

This revision adds basic support for formatting C# files with clang-format, I know the barrier to entry is high here  so I'm sending this revision in to test the water as to whether this might be something we'd consider landing.

Tracking in Bugzilla as:
https://bugs.llvm.org/show_bug.cgi?id=40850

Justification:
C# code just looks ugly in comparison to the C++ code in our source tree which is clang-formatted.

I've struggled with Visual Studio reformatting to get a clean and consistent style, I want to format our C# code on saving like I do now for C++ and i want it to have the same style as defined in our .clang-format file, so it consistent as it can be with C++.  (Braces/Breaking/Spaces/Indent etc..)

Using clang format without this patch leaves the code in a bad state, sometimes when the BreakStringLiterals is set, it  fails to compile.

Mostly the C# is similar to Java, except instead of JavaAnnotations I try to reuse the TT_AttributeSquare.

Almost the most valuable portion is to have a new Language in order to partition the configuration for C# within a common .clang-format file, with the auto detection on the .cs extension. But there are other C# specific styles that could be added later if this is accepted. in particular how  `{ set;get }` is formatted.

Reviewers: djasper, klimek, krasimir, benhamilton, JonasToth

Reviewed By: klimek

Subscribers: llvm-commits, mgorny, jdoerfert, cfe-commits

Tags: #clang, #clang-tools-extra

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

llvm-svn: 356662

[Thumb] Fix infinite loop in ABS expansion (PR41160)

Don't expand ISD::ABS node if its legal.

llvm-svn: 356661

[AMDGPU] Support for v3i32/v3f32

Added support for dwordx3 for most load/store types, but not DS, and not
intrinsics yet.

SI (gfx6) does not have dwordx3 instructions, so they are not enabled
there.

Some of this patch is from Matt Arsenault, also of AMD.

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

Change-Id: I913ef54f1433a7149da8d72f4af54dbb13436bd9
llvm-svn: 356659

Fix -Wmisleading-indentation gcc7 warning. NFCI.

llvm-svn: 356658

[AArch64] Allow -mattr=tpidr-el[1|2|3]

Added subtarget features for AArch64 to use TPIDR_EL[1|2|3] as the TLS base
register, rather than the default TPIDR_EL0.

Patch by Philip Derrin!

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

llvm-svn: 356657

[SelectionDAG] Add scalarization of ABS node (PR41149)

Patch by: @ikulagin (Ivan Kulagin)

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

llvm-svn: 356656

Fix two more issues with r356652

The first problem was a use-after-free in the tests (detected by asan
bots). The temporary array created for the "create" call is guaranteed
to live only until the end of the statement. The fix there is to store
the test data in a local variable to ensure it has the right lifetime

The second issue is broken BUILD_SHARED_LIBS build, which I fix by
adding the appropriate BinaryFormat dependency to the Object unit tests.

llvm-svn: 356655

[RISCV][NFC] Remove old CHECK lines from linker-relaxation.s test

The RELOC: check lines are no longer used.

llvm-svn: 356654

Attempt to fix modules build for r356652

The commit added a new .def file. This adds it to the list of textual
headers.

llvm-svn: 356653

[Object] Add basic minidump support

Summary:
This patch adds basic support for reading minidump files. It contains
the definitions of various important minidump data structures (header,
stream directory), and of one minidump stream (SystemInfo). The ability
to read other streams will be added in follow-up patches. However, all
streams can be read even now as raw data, which means lldb's minidump
support (where this code is taken from) can be immediately rebased on
top of this patch as soon as it lands.

As we don't have any support for generating minidump files (yet), this
tests the code via unit tests with some small handcrafted binaries in
the form of c char arrays.

Reviewers: Bigcheese, jhenderson, zturner

Subscribers: srhines, dschuff, mgorny, fedor.sergeev, lemo, clayborg, JDevlieghere, aprantl, lldb-commits, llvm-commits

Tags: #llvm

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

llvm-svn: 356652

[BasicAA] Use DenseMap::try_emplace after D59151. NFC

llvm-svn: 356651

Reland r356547 after fixing the YAML module missing issue.

[clang-tidy] Parallelize clang-tidy-diff.py

This patch has 2 rationales:

- large patches lead to long command lines and often cause max command line length restrictions imposed by OS;
- clang-tidy runs on modified files are independent and can be done in parallel, the same as done for run-clang-tidy.

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

llvm-svn: 356649

Silence warning about unused variable in builds without asserts [NFC]

llvm-svn: 356648

Use list comprehension instead of map/filter to prepare Python2/3 compat

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

llvm-svn: 356647

[ScalarizeMaskedMemIntrinsics] Reverse some if conditions to reduce indentations to remove curly braces.

Pre-commit for D59180

llvm-svn: 356646

[InstCombine] Add test case for PR41164. NFC

llvm-svn: 356645

[BasicAA] Reduce no of map seaches [NFCI].

Summary:
This is a refactoring patch.
- Reduce the number of map searches by reusing the iterator.
- Add asserts to check that the entry is in the cache, as this is something BasicAA relies on to avoid infinite recursion.

Reviewers: chandlerc, aschwaighofer

Subscribers: sanjoy, jlebar, llvm-commits

Tags: #llvm

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

llvm-svn: 356644

[Reproducers] Properly handle QEnvironment packets

On Linux, a QEnvironment packet is sent for every environment variable.
This breaks replay when the number of environment variables is different
then during capture. The solution is to always reply with OK.

llvm-svn: 356643

[instcombine] Add some todos, and arrange code for readibility

llvm-svn: 356642

[MSSA] Delete move ctor; remove dynamic never-moved verification

Code archaeology in D59315 revealed that MSSA should never be moved.
Rather than trying to check dynamically that this hasn't happened in the
verify() functions of Walkers, it's likely best to just delete its move
constructor.

Since all these verify() functions did is check that MSSA hasn't moved,
this allows us to remove these verify functions.

I can readd the verification checks if someone's super concerned about
us trying to `memcpy` MemorySSA or something somewhere, but I imagine we
have other problems if we're trying anything like that...

llvm-svn: 356641

Add dylib-has-no-filesystem when filesystem is disabled

llvm-svn: 356640

Mark debug death tests as unsupported on Windows

llvm-svn: 356639

[Reproducers] Log inconsistencies during replay (NFC)

Make debugging of the GDB remote packet aspect of reproducers easier by
logging both requests and replies. This enables some sanity checking
during replay.

llvm-svn: 356638

Remove type visibility specifiers from new chrono types.

_LIBCPP_TYPE_VIS is only really needed on types with a vtable.
And on Windows it doesn't work with types that have only inline methods.

This patch removes the unneeded attributes.

llvm-svn: 356637

creduce-clang-crash.py: preprocess file + reduce commandline

This CL causes our creduce-clang-crash.py util to:

- try to preprocess the file before reducing
- try to remove some command line arguments
- now require a llvm bin directory, since the generated crash script
  doesn't have an absolute path for clang

It also marks it as executable, since I forgot to do that in the last
commit. :)

Patch by Amy Huang!

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

llvm-svn: 356636

[libcxx] [test] Revert r356632 add (void) casts to operator new calls, to suppress warnings generated by [[nodiscard]]."

llvm-svn: 356635

[CFG] [analyzer] pr41142: C++17: Skip transparent InitListExprs in constructors.

When searching for construction contexts, i.e. figuring out which statements
define the object that is constructed by each construct-expression, ignore
transparent init-list expressions because they don't add anything to the
context. This allows the Static Analyzer to model construction, destruction,
materialization, lifetime extension correctly in more cases. Also fixes
a crash caused by incorrectly evaluating initial values of variables
initialized with such expressions.

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

llvm-svn: 356634

Allow disabling of filesystem library.

Summary: Filesystem doesn't work on Windows, so we need a mechanism to turn it off for the time being.

Reviewers: ldionne, serge-sans-paille, EricWF

Reviewed By: EricWF

Subscribers: mstorsjo, mgorny, christof, jdoerfert, libcxx-commits

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

llvm-svn: 356633

[libcxx] [test] Add (void) casts to operator new calls, to suppress warnings generated by [[nodiscard]].

This allows these tests to pass when compiled by MSVC++.

llvm-svn: 356632

[X86] Add CMPXCHG8B feature flag. Set it for all CPUs except i386/i486 including 'generic'. Disable use of CMPXCHG8B when this flag isn't set.

CMPXCHG8B was introduced on i586/pentium generation.

If its not enabled, limit the atomic width to 32 bits so the AtomicExpandPass will expand to lib calls. Unclear if we should be using a different limit for other configs. The default is 1024 and experimentation shows that using an i256 atomic will cause a crash in SelectionDAG.

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

llvm-svn: 356631

Revert "Reland r356547 after fixing the tests for Linux."

This reverts commit 538fb72226cf6dff95af83f7777e12b8dbd061ea (r356565).

This is still breaking a build bot:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/45557

llvm-svn: 356630

Fix Mach-O bind and rebase validation errors in libObject

Summary:
llvm-objdump (via libObject) validates DYLD_INFO rebase and bind
entries against the basic structure found in the Mach-O file before
evaluating the contents of those entries. Certain malformed Mach-Os can
defeat the validation check and force llvm-objdump (libObject) to crash.

The previous logic verified a rebase or bind started in a valid Mach-O
section, but did not verify that the section wholely contained the
fixup. It also generally allows rebases or binds to start immediately
after a valid section even if that range is not itself part of a valid
section. Finally, bind and rebase opcodes that indicate more than one
fixup (apply N times...) are not completely validated: only the first
and final fixups are checked.

The previous logic also rejected certain binaries as false positives.
Some bind and rebase opcodes can modify the state machine such that the
next bind or rebase will fail. libObject will reject these opcodes as
invalid in order to be helpful and print an error message associated
with the instruction that caused the problem, even though the binary is
not actually illegal until it consumes the invalid state in the state
machine. In other words, libObject may reject a Mach-O binary that
Apple's dynamic linker may consider legal. The original version of
macho-rebase-add-addr-uleb-too-big is an example of such a binary.

I have replaced the existing checkSegAndOffset and checkCountAndSkip
functions with a single function, checkSegAndOffsets, which validates
all of the fixups realized by a DYLD_INFO opcode. checkSegAndOffsets
verifies that a Mach-O section fully contains each fixup. Every fixup
realized by an opcode is validated, and some (but not all!)
inconsistencies in the state machine are allowed until a fixup is
realized. This means that libObject may fail on an opcode that realizes
a fixup, not on the opcode that introduced the arithmetic error.

Existing test cases have been modified to reflect the changes in error
messages returned by libObject. What's more, the test case for
macho-rebase-add-addr-uleb-too-big has been modified so that it actually
triggers the error condition; the new code in libObject considers the
original test binary "legal".

rdar://47797757

Reviewers: lhames, pete, ab

Reviewed By: pete

Subscribers: rupprecht, jdoerfert, llvm-commits

Tags: #llvm

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

llvm-svn: 356629

Remove extra white spaces

llvm-svn: 356628

[clang-tidy] Disable google-runtime-int in Objective-C++ 🔓

Summary:
In contrast to Google C++, Objective-C often uses built-in integer types
other than `int`. In fact, the Objective-C runtime itself defines the
types NSInteger¹ and NSUInteger² which are variant types depending on
the target architecture. The Objective-C style guide indicates that
usage of system types with variant sizes is appropriate when handling
values provided by system interfaces³. Objective-C++ is commonly the
result of conversion from Objective-C to Objective-C++ for the purpose
of integrating C++ functionality. The opposite of Objective-C++ being
used to expose Objective-C functionality to C++ is less common,
potentially because Objective-C has a signficantly more uneven presence
on different platforms compared to C++. This generally predisposes
Objective-C++ to commonly being more Objective-C than C++. Forcing
Objective-C++ developers to perform conversions between variant system types
and fixed size integer types depending on target architecture when
Objective-C++ commonly uses variant system types from Objective-C is
likely to lead to more bugs and overhead than benefit. For that reason,
this change proposes to disable google-runtime-int in Objective-C++.

[1] https://developer.apple.com/documentation/objectivec/nsinteger?language=objc
[2] https://developer.apple.com/documentation/objectivec/nsuinteger?language=objc
[3] "Types long, NSInteger, NSUInteger, and CGFloat vary in size between
32- and 64-bit builds. Use of these types is appropriate when handling
values exposed by system interfaces, but they should be avoided for most
other computations."
https://github.com/google/styleguide/blob/gh-pages/objcguide.md#types-with-inconsistent-sizes

Subscribers: xazax.hun, jdoerfert, cfe-commits

Tags: #clang

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

llvm-svn: 356627

Change the logging on ptrace(PT_KILL) in MachProcess::Kill to log
if LOG_PROCESS is enabled or if there was an error making that call.

<rdar://problem/49036508>

llvm-svn: 356626

Update DWARF files.

llvm-svn: 356625

libc++/win: Make once_flag have the same size as a pointer.

`unsigned long` is 32-bit on 32-bit systems and 64-bit on 64-bit systems
on LP64 systems -- which most Unix systems are, but Windows isn't.
Windows is LLP64, which means unsigned long is 32-bit even on 64-bit
systems.

pplwin.h contains

    static_assert(alignof(void *) == alignof(::std::once_flag), ...)

which fails due to this problem.

Instead of unsigned long, use uintptr_t, which consistently is 32-bit
on 32-bit systems and 64-bit on 64-bit systems.

No functional change except on 64-bit Windows.

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

llvm-svn: 356624

Revert "[clangd] Print arguments in template specializations"

This reverts commit 44a63f6a150dec72dea43730d2a89d292e58bd6f. It segfaults on an internal test case (will follow up off thread).

llvm-svn: 356623

[WebAssembly][NFC] Fix formatting error from rL356610

llvm-svn: 356622

[AMDGPU] Do not generate spurious PAL metadata

My previous fix rL356591 "[AMDGPU] Added MsgPack format PAL metadata"
accidentally caused a spurious PAL metadata .note record to be emitted
for any AMDGPU output. That caused failures in the lld test
amdgpu-relocs.s. Fixed.

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

Change-Id: Ie04a2aaae890dcd490f22c89edf9913a77ce070e
llvm-svn: 356621

[InstCombine] Add additional sub nsw inference tests; NFC

nsw can be determined based on known bits here, but currently
isn't.

llvm-svn: 356620

Allow machine dce to remove uses in the same instruction

Machine DCE cannot remove a dead definition if there are non-dbg uses.
A use however can be in the same instruction:

  dead %0 = INST %0

Such instructions sometimes created by Detect dead lanes pass.

Allow this instruction to be deleted despite the use if the only use
belongs to the same instruction.

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

llvm-svn: 356619

[X86] Call lowerShuffleAsBitMask for 512-bit vectors in lowerShuffleAsBlend.

This patch enables the use of lowerShuffleAsBitMask for 512-bit blends before
falling back to move immedate, GPR to k-register, and masked op.

I had to make some changes to support v8i64 when i64 is not a legal type. And to
support floating point types.

This trades a load for the move immediate and GPR move which is higher latency.
But its probably better for register pressure not having to hop through other
register classes. The load+and should play better with LICM and
rematerialization I think.

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

llvm-svn: 356618

[AMDGPU] Fix dependency on `BinaryFormat`

Summary: - The linking is broken when this library is built as shared one.

Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 356617

[libc++] Mark <filesystem> as unavailable on Apple platforms using pragmas

Summary:
Also add the corresponding XFAILs to tests that require filesystem.
The approach taken to mark <filesystem> as unavailable in this patch
is to mark all the header as unavailable using #pragma clang attribute.
Marking each declaration using the attribute is more intrusive and
does not provide a lot of value right now because pretty much everything
in <filesystem> requires dylib support, often transitively.

This is an alternative to https://reviews.llvm.org/D59093.
A similar (but partial) patch was already applied in r356558.

Reviewers: mclow.lists, EricWF, serge-sans-paille

Subscribers: christof, jkorous, dexonsmith, libcxx-commits

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

llvm-svn: 356616

[clang-format][NFC] fix release notes build issue

build issue from r356613

llvm-svn: 356615

[clang][OpenMP] Fix build when using libgomp

Summary: rL356570 introduced a test which only passes with the default openmp library, libomp, and fails with other openmp libraries, such as libgomp. Explicitly choose libomp.

Reviewers: lebedev.ri

Subscribers: guansong, jdoerfert, cfe-commits

Tags: #clang

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

llvm-svn: 356614

[clang-format] BeforeHash added to IndentPPDirectives

Summary:
The option BeforeHash added to IndentPPDirectives.
Fixes Bug 36019. https://bugs.llvm.org/show_bug.cgi?id=36019

Reviewers: djasper, klimek, krasimir, sammccall, mprobst, Nicola, MyDeveloperDay

Reviewed By: klimek, MyDeveloperDay

Subscribers: kadircet, MyDeveloperDay, mnussbaum, geleji, ufna, cfe-commits

Patch by to-mix.

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

llvm-svn: 356613

Introduce DWARFContext.

LLVM's DWARF parsing library has a class called DWARFContext which holds
all of the various DWARF data sections and lots of other information.
LLDB's on the other hand stores all of this directly in SymbolFileDWARF
/ SymbolFileDWARFDwo and passes this interface around through the
parsing library. Obviously this is incompatible with a world where the
low level interface does not depend on the high level interface, so we
need to move towards a model similar to LLVM's - i.e. all of the context
needed for low level parsing should be in a single class, and that class
gets passed around.

This patch is a small incremental step towards achieving this. The
interface and internals deviate from LLVM's for technical reasons, but
the high level idea is the same. The goal is, eventually, to remove all
occurrences of SymbolFileDWARF from the low level parsing code.

For now I've chosen a very simple section - the .debug_aranges section
to move into DWARFContext while leaving everything else unchanged. In
the short term this is a bit confusing because now the information you
need might come from either of 2 different locations. But it's a huge
refactor to do this all at once and runs a much higher risk of breaking
things. So I think it would be wise to do this in very small pieces.

TL;DR - No functional change

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

llvm-svn: 356612

AMDGPU: Don't look for constant in insert/extract_vector_elt regbankselect

The constantness shouldn't change the register bank choice. We also
don't need to restrict this to only indexing VGPRs, since it's
possible to index SGPRs (but SelectionDAG made using this
difficult). Allow directly indexing SGPRs when appropriate.

llvm-svn: 356611

[WebAssembly] Target features section

Summary:
Implements a new target features section in assembly and object files
that records what features are used, required, and disallowed in
WebAssembly objects. The linker uses this information to ensure that
all objects participating in a link are feature-compatible and records
the set of used features in the output binary for use by optimizers
and other tools later in the toolchain.

The "atomics" feature is always required or disallowed to prevent
linking code with stripped atomics into multithreaded binaries. Other
features are marked used if they are enabled globally or on any
function in a module.

Future CLs will add linker flags for ignoring feature compatibility
checks and for specifying the set of allowed features, implement using
the presence of the "atomics" feature to control the type of memory
and segments in the linked binary, and add front-end flags for
relaxing the linkage policy for atomics.

Reviewers: aheejin, sbc100, dschuff

Subscribers: jgravelle-google, hiraditya, sunfish, mgrang, jfb, jdoerfert, llvm-commits

Tags: #llvm

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

llvm-svn: 356610

[X86] Add __crc32b/__crc32w/__crc32d/__crc32q intrinsics to match gcc and icc.

gcc has these intrinsics in ia32intrin.h as well. And icc implements them
though they aren't documented in the Intel Intrinsics Guide.

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

llvm-svn: 356609

[AMDGPU] Fix clamp bit DAG operand

Summary:
- Should use `targetconstant` instead of `constant` operand for clamp
  bit, which is expected as an immediate operand. Under certain
  conditions, such as a common `i1 false` constant is used in other
  place and selected before the instruction with clamp bit, register
  operand may be added instead of immediate one. Use `targetcosntant` to
  enforce that.

Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 356608

[OPENMP]Improve detection of omp_allocator_handle_t type and predefined
allocators.

It is better to deduce omp_allocator_handle_t type from the predefined
allocators, because omp.h header might not define it explicitly. Plus,
it allows to identify the predefined allocators correctly when trying to
build the allcoator for the global variables.

llvm-svn: 356607

[ARC] Add ARCOptAddrMode pass to generate postincrement loads/stores.

Build on newly introduced ARC postincrement loads/stores from r356200.

Patch By Denis Antrushin! <denis@synopsys.com>

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

llvm-svn: 356606

Fix implicit ios -> watchOS availability version mapping for
versions that have the major number only

rdar://48018651

llvm-svn: 356605

[AArch64] Fix formatting (NFC)

Indent macro instances properly.

llvm-svn: 356604

AMDHSA: Fix COMPUTE_PGM_RSRC2.USER_SGPR calculation when parsing ISA assembly

It must match https://llvm.org/docs/AMDGPUUsage.html#initial-kernel-execution-state

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

llvm-svn: 356603

Mark <charconv> tests as unsupported for C++11 and C++14 if you're not testing libc++. Thanks to Louis for the suggestion.

llvm-svn: 356602

[ARM] Eliminate redundant "mov rN, sp" instructions in Thumb1.

This takes sequences like "mov r4, sp; str r0, [r4]", and optimizes them
to something like "str r0, [sp]".

For regular stack variables, this optimization was already implemented:
we lower loads and stores using frame indexes, which are expanded later.
However, when constructing a call frame for a call with more than four
arguments, the existing optimization doesn't apply.  We need to use
stores which are actually relative to the current value of sp, and don't
have an associated frame index.

This patch adds a special case to handle that construct.  At the DAG
level, this is an ISD::STORE where the address is a CopyFromReg from SP
(plus a small constant offset).

This applies only to Thumb1: in Thumb2 or ARM mode, a regular store
instruction can access SP directly, so the COPY gets eliminated by
existing code.

The change to ARMDAGToDAGISel::SelectThumbAddrModeSP is a related
cleanup: we shouldn't pretend that it can select anything other than
frame indexes.

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

llvm-svn: 356601

Add a __has_extension check for '#pragma clang attribute' as an external-declaration

This was added in r356075.

llvm-svn: 356600

[Sema] Deduplicate some availability checking logic

Before this commit, we emit unavailable errors for calls to functions during
overload resolution, and for references to all other declarations in
DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as
the DiagnoseAvailabilityOfDecl based checks, as they error on the code from
PR40991. This commit fixes this by removing the early checking.

llvm.org/PR40991
rdar://48564179

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

llvm-svn: 356599

Recommit "Support attribute used in member funcs of class templates"

This diff previously exposed a bug in LLVM's IRLinker, breaking
buildbots that tried to self-host LLVM with monolithic LTO.
The bug is now in LLVM by D59552

Original commit message:
As PR17480 describes, clang does not support the used attribute
for member functions of class templates. This means that if the member
function is not used, its definition is never instantiated. This patch
changes clang to emit the definition if it has the used attribute.

Test Plan: Added a testcase

Reviewed By: aaron.ballman

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

llvm-svn: 356598

[Linker] Fix crash handling appending linkage

Summary:
When linking two llvm.used arrays, if the resulting merged
array ends up with duplicated elements (with the same name) but with
different types, the IRLinker was crashing. This was supposed to be
legal, as the IRLinker bitcasts elements to match types in these
situations.

This bug was exposed by D56928 in clang to support attribute used
in member functions of class templates. Crash happened when self-hosting
with LTO. Since LLVM depends on attribute used to generate code
for the dump() method, ubiquitous in the code base, many input bc
had a definition of this method referenced in their llvm.used array.
Some of these classes got optimized, changing the type of the first
parameter (this) in the dump method, leading to a scenario with a
pool of valid definitions but some with a different type, triggering
this bug.

This is a memory bug: ValueMapper depends on (calls) the materializer
provided by IRLinker, and this materializer was freely calling RAUW
methods whenever a global definition was updated in the temporary merged
output file. However, replaceAllUsesWith may or may not destroy
constants that use this global. If the linked definition has a type
mismatch regarding the new def and the old def, the materializer would
bitcast the old type to the new type and the elements of the llvm.used
array, which already uses bitcast to i8*, would end up with elements
cascading two bitcasts. RAUW would then indirectly call the
constantfolder to update the constant to the new ref, which would,
instead of updating the constant, destroy it to be able to create
a new constant that folds the two bitcasts into one. The problem is that
ValueMapper works with pointers to the same constants that may be
getting destroyed by RAUW. Obviously, RAUW can update references in the
Module to do not use the old destroyed constant, but it can't update
ValueMapper's internal pointers to these constants, which are now
invalid.

The approach here is to move the task of RAUWing old definitions
outside of the materializer.

Test Plan:
Added LIT test case, tested clang self-hosting with D56928 and
verified it works

Reviewed By: efriedma

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

llvm-svn: 356597

[NFC] Fix brace indentation.

llvm-svn: 356596

[libc++] Use the compiler that CMake found when running lit for back-deployment tests

llvm-svn: 356595

Resubmit r356511 "[TailCallElim] Add tailcall elimination pass to LTO pipelines"

Failing LLD tests have been fixed in r356593.

llvm-svn: 356594

[TailCallElim] Update tests for LTO pipeline change

D58391 changed the LTO pipelines to add the tailcall elimination pass.
This caused three LLD tests to fail.

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

llvm-svn: 356593

Remove the unused return value in ASTImporter::Imported [NFC]

Summary:
`ASTImporter::Imported` currently returns a Decl, but that return value is not used by the ASTImporter (or anywhere else)
nor is it documented.

Reviewers: balazske, martong, a.sidorin, shafik

Reviewed By: balazske, martong

Subscribers: rnkovacs, cfe-commits

Tags: #clang

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

llvm-svn: 356592