Otherwise, when testing trunk libc++ on an older system, lit will think
that the dylib features are disabled. Ideally, we'd have a notion of
running the tests with/without a deployment target (or, equivalently,
a deployment target representing trunk where everything is as recent
as can be). Since we always have a deployment target right now (which
defaults to the current system), we only enable those features when
we're going to also be testing with the system libc++.

We also need to disable the availability markup when we are not running
a system library flavor, because availability markup does not make sense
when building against the trunk libc++ (which has everything regardless
of what the current system is).

This is a re-application of r353319, which had been reverted due to
CI breakage. This time around, I made sure it didn't break our internal
CI before submitting.

This is also a partial undoing of r348296, in spirit at least. However,
with this patch, availability markup is enabled based on whether we're
using a system library or not, whereas previously one could enable
it or disable it arbitrarily. This was confusing as it led to testing
configurations that don't make sense (such as testing a system library
without availability markup, or trunk testing with availability markup).

llvm-svn: 355451

Summary:
A Lamdba with a return type template with a boolean literal (true,false) behaves differently to an integer literal

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

Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, jkorous

Reviewed By: jkorous

Subscribers: jkorous, cfe-commits

Tags: #clang-tools-extra

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

llvm-svn: 355450

causing lldb-mi testsuite failures?  

llvm-svn: 355449

This test is also no longer reliably failing or passing on Windows and it is hanging every few runs.

llvm-svn: 355448

Some platforms for which TSAN has build rules are omitted for the lack of
known build bots.

llvm-svn: 355445

Summary:
- Replaces some uses of `MachineFunction::iterator(MBB)` with
  `MBB->getIterator()` and `MachineBasicBlock::iterator(MI)` with
  `MI->getIterator()`, which are simpler.
- Replaces some uses of `std::prev` of `std::next` that takes a
  MachineFunction or MachineBasicBlock iterator with `getPrevNode` and
  `getNextNode`, which are also simpler.

Reviewers: sbc100

Subscribers: dschuff, sunfish, jgravelle-google, llvm-commits

Tags: #llvm

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

llvm-svn: 355444

These tests are flakey on Windows and recently they have started failing AND also hanging the whole suite when they fail.

llvm-svn: 355443

llvm-svn: 355442

Rename it to reflect that it's parsing YAML remarks.

llvm-svn: 355441

Add this in the Apple-stage2.cmake to ship the remark tooling library
with the compiler.

llvm-svn: 355440

Getting rid of the name "optimization remarks" for anything that
involves handling remarks on the client side.

It's safer to do this now, before we get stuck with that name in all the
APIs and public interfaces we decide to export to users in the future.

This renames llvm/tools/opt-remarks to llvm/tools/remarks-shlib, and now
generates `libRemarks.dylib` instead of `libOptRemarks.dylib`.

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

llvm-svn: 355439

Summary:
We disabled MachineBlockPlacement pass in D58953, and this test result
changes as the result of it.

Reviewers: kripken

Subscribers: dschuff, sbc100, jgravelle-google, sunfish, llvm-commits

Tags: #llvm

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

llvm-svn: 355438

Summary:
This pass hurts code size for wasm and sometimes generates irreducible
control flow.
Context: https://github.com/emscripten-core/emscripten/pull/8233

Reviewers: kripken, dschuff

Subscribers: sunfish, sbc100, jgravelle-google, llvm-commits

Tags: #llvm

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

llvm-svn: 355437

Tests only for integers, not floating point or pointers.

The scalar 8-bit case uses branch instead of CMOV,
because there is no no 8-bit CMOV.

Vector tests are for consistency, since it can be vectorized.

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

llvm-svn: 355436

llvm-svn: 355435

A template specialization of a template foo<int N> can contain integer constants and a whole bunch of operators - e. g.  foo< 1 ? !0 : (3+1)%4 >

Inspired by https://reviews.llvm.org/D58922

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

llvm-svn: 355434

Revert r355224 "[TableGen][SelectionDAG][X86] Add specific isel matchers for immAllZerosV/immAllOnesV. Remove bitcasts from X86 patterns that are no longer necessary."

This caused the first matcher in the isel table for many targets to Opc_Scope instead of Opc_SwitchOpcode. This leads to a significant increase in isel match failures.

llvm-svn: 355433

Part 2 of CSPGO change in Clang: Add test cases.

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

llvm-svn: 355432

These arrays are both keyed by CPU name and go into the same tablegenerated file. Merge them so we only need to store keys once.

This also removes a weird space saving quirk where we used the ProcDesc.size() to create to build an ArrayRef for ProcSched.

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

llvm-svn: 355431

The variable X86DomainReassignment::EnclosedEdges is used to store registers that have been enclosed in some closure, so those registers will be ignored when create new closures. But there is no registers has ever been put into this set, so a single register can be enclosed in multiple closures, it significantly increase compile time.

This patch adds a register into EnclosedEdges when it is enclosed into a closure.

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

llvm-svn: 355430

[Subtarget] Create a separate SubtargetSubtargetKV struct for ProcDesc to remove fields from the stack tables that aren't needed for CPUs

The description for CPUs was just the CPU name wrapped with "Select the " and " processor". We can just do that directly in the help printer instead of making a separate version in the binary for each CPU.

Also remove the Value field that isn't needed and was always 0.

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

llvm-svn: 355429

[Subtarget] Move SubtargetFeatureKV/SubtargetInfoKV from SubtargetFeature.h to MCSubtargetInfo.h. Move all code that operates on ProcFeatures and ProcDesc arrays to MCSubtargetInfo.

The SubtargetFeature class managed a list of features as strings. And it also had functions for setting bits in a FeatureBitset.

The methods that operated on the Feature list as strings are used in other parts of the backend. But the parts that operate on FeatureBitset are very tightly coupled to MCSubtargetInfo and requires passing in the arrays that MCSubtargetInfo owns. And the same struct type is used for ProcFeatures and ProcDesc.

This has led to MCSubtargetInfo having 2 arrays keyed by CPU name. One containing a mapping from a CPU name to its features. And one containing a mapping from CPU name to its scheduler model.

I would like to make a single CPU array containing all CPU information and remove some unneeded fields the ProcDesc array currently has. But I don't want to make SubtargetFeatures.h have to know about the scheduler model type and have to forward declare or pull in the header file.

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

llvm-svn: 355428

"[libc++] Fix <atomic> failures on GCC"
"[libc++] Change memory_order to an enum class"
"[libc++] decoupling Freestanding atomic<T> from libatomic.a"

llvm-svn: 355427

Fixes undefined value verifier error.

llvm-svn: 355426

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

llvm-svn: 355425

We already do this for 16/32/64 as well as 8-bit add with register/immediate. Might as well do it for 8-bit INC/DEC too.

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

llvm-svn: 355424

We already support 8-bits adds in convertToThreeAddress. But we can also support 8-bit OR if the bits are disjoint. We already do this for 16/32/64.

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

llvm-svn: 355423

[DataFormatters] Fix regression in libc++ std::atomic formatter caused by https://reviews.llvm.org/D56913

rdar://problem/48568543

llvm-svn: 355422

If a kernel template has a function as its template parameter, a device function should be
allowed as template argument since a kernel can call a device function. However,
currently if the kernel template is instantiated in a host function, clang will emit an error
message saying the device function is an invalid candidate for the template parameter.

This happens because clang checks the reference to the device function during parsing
the template arguments. At this point, the template is not instantiated yet. Clang incorrectly
assumes the device function is called by the host function and emits the error message.

This patch fixes the issue by disabling checking of device function during parsing template
arguments and deferring the check to the instantion of the template. At that point, the
template decl is already available, therefore the check can be done against the instantiated
function template decl.

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

llvm-svn: 355421

x86-64 is an invalid architecture in triples. Changing it to the correct
triple (x86_64) changes some tests, because SLP is not deemed profitable
any more.

Reviewers: ABataev, RKSimon, spatel

Reviewed By: RKSimon

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

llvm-svn: 355420

HIP uses clang-offload-bundler to create fat binary. The bundle for host is empty.
Currently clang-offload-bundler checks if the bundle size is 0 when unbundling.
If so it will exit without unbundling the remaining bundles. This causes
clang-offload-bundler not being able to unbundle fat binaries generated for HIP.

This patch allows bundles size to be 0 when clang-offload-bundler unbundles
input files.

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

llvm-svn: 355419

memory.

If the variable with the constant non-scalar type is firstprivatized in
the target region, the local copy is created with the data copying.
Instead, we allocate the copy in the constant memory and avoid extra
copying in the outlined target regions. This global copy is used in the
target regions without loss of the performance.

llvm-svn: 355418

Revert "[libc++] Fix <atomic> failures on GCC"
Revert "[libc++] Change memory_order to an enum class"
Revert "[libc++] decoupling Freestanding atomic<T> from libatomic.a"

The lldb formatter nededs to be updated. Shafik and Louis will
coordinate to do so.

llvm-svn: 355417

Summary:
The bytemap classes will be used by the primary32 allocator to associate
classes with memory regions. It's similar to the sanitizer_common one
except for the fact that the base (level1) maps are mapped instead of
being static to reduce the memory footprint of an uninitialized allocator.

Reviewers: vitalybuka, eugenis, morehouse, flowerhack, dmmoore415, mcgrathr

Reviewed By: vitalybuka, morehouse

Subscribers: mgorny, delcypher, jfb, #sanitizers, llvm-commits

Tags: #llvm, #sanitizers

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

llvm-svn: 355416

This passes locally but breaks on the bots. Maybe an SDK difference.
Reverting while I investigate.

llvm-svn: 355415

Currently one can concatenate strings using hash(#),
but not lists, although that would be a natural thing to do. 

This patch allows one to write something like:
def : A<!listconcat([1,2], [3,4])>;
simply as :
def : A<[1,2] # [3,4]>;

This was missing feature was highlighted by Nicolai
at FOSDEM talk.

Reviewed by: nhaehnle, hfinkel

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

llvm-svn: 355414

The test expect sample executable code be built, but fails on Windows.

Review comment https://reviews.llvm.org/D57689#1418597

Tags: #lldb

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

llvm-svn: 355413

llvm-svn: 355412

llvm-svn: 355411

When -fno-gpu-rdc is set, device code is compiled, linked, and assembled into fat binary
and embedded as string in object files. The object files are normal object files which
can be linked by host linker. In the linking stage, the object files should not be unbundled
when -fno-gpu-rdc is set since they are normal object files, not bundles. The object files
only need to be unbundled when -fgpu-rdc is set.

Currently clang always unbundles object files, disregarding -fgpu-rdc option.

This patch fixes that.

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

llvm-svn: 355410