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

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

Mark this as a libcpp specific test; the standard doesn't say that
this method should be noexcept.

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

The standard doesn't declare this overload as noexcept, but doesn't
either say that it strictly cannot be noexcept either. The function
doesn't throw on errors that are signaled via error_code, but the
standard says that it may throw a bad_alloc.

This fixes an error with libstdc++ on linux.

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

This makes them more readable in llvm-lit's output on failures.

This only applies the change on the filesystem test subdir.

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

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

Update clang/lib/Format and clang/lib/Rewrite to use a `MemoryBufferRef`
from `getBufferOrFake` instead of `MemoryBuffer*` from `getBuffer`.

No functionality change here, since the call sites weren't checking if
the buffer was valid.

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

Summary:
Initializer merging generates pretty inefficient code for large allocas
that also happens to trigger an exponential algorithm somewhere in
Machine Instruction Scheduler. See https://bugs.llvm.org/show_bug.cgi?id=47867.

This change adds an upper limit for the alloca size. The default limit
is selected such that worst case size of memtag-generated code is
similar to non-memtag (but because of the ISA quirks, this case is
realized at the different value of alloca size, ex. memset inlining
triggers at sizes below 512, but stack tagging instructions are 2x
shorter, so limit is approx. 256).

We could try harder to emit more compact code with initializer merging,
but that would only affect large, sparsely initialized allocas, and
those are doing fine already.

Reviewers: vitalybuka, pcc

Subscribers: llvm-commits

The NPM runs SpeculateAroundPHIs which breaks critical edges, causing a
branch we check for to not directly jump back to the same block.

This enables these transforms for vectors:
(ctpop x) u< 2 -> (x & x-1) == 0
(ctpop x) u> 1 -> (x & x-1) != 0
(ctpop x) == 1 --> (x != 0) && ((x & x-1) == 0)
(ctpop x) != 1 --> (x == 0) || ((x & x-1) != 0)

All enabled if CTPOP isn't Legal. This differs from the scalar
behavior where the first two are done unconditionally and the
last two are done if CTPOP isn't Legal or Custom. The Legal
check produced better results for vectors based on X86's
custom handling. Might be worth re-visiting scalars here.

I disabled the looking through truncate for vectors. The
code that creates new setcc can use the same result VT as the
original setcc even if we truncated the input. That may work
work for most scalars, but definitely wouldn't work for vectors
unless it was a vector of i1.

Fixes or at least improves PR47825

Reviewed By: spatel

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

We have pseudo instructions we use for bitcasts between these types.
We have them in the load folding table, but not the store folding
table. This adds them there so they can be used for stack spills.

I added an exact size check so that we don't fold when the stack slot
is larger than the GPR. Otherwise the upper bits in the stack slot
would be garbage. That would be fine for Eli's test case in PR47874,
but I'm not sure its safe in general.

A step towards fixing PR47874. Next steps are to change the ADDSSrr_Int
pseudo instructions to use FR32 as the second source register class
instead of VR128. That will keep the coalescer from promoting the
register class of the bitcast instruction which will make the stack
slot 4 bytes instead of 16 bytes.

Reviewed By: RKSimon

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

AA computes the correct result for phi/a1 aliasing, while BatchAA
produces an incorrect result depening on which queries have been
performed beforehand.

Generally tests run -O# before other passes, not after.

Use the Todo.h header file introduce in D88909 to marke part of the lowering that are
not done yet.

Reviewed By: jeanPerier

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

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

Remove `experimental` from the intrinsic names.

Also moved most of the common type definitions from libc/spec/stdc.td
to libc/spec/spec.td so that they can be used to list functions in llvm_libc_ext.td.

Reviewed By: sivachandra

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

These were introduced in r279902 on the grounds that using separate
MUL_U24/MUL_I24 and MULHI_U24/MULHI_I24 nodes would introduce multiple
uses of the operands, which would prevent SimplifyDemandedBits from
simplifying the operands.

This has since been fixed by D24672 "AMDGPU/SI: Use new SimplifyDemandedBits helper for multi-use operations"

No functional change intended. At least it has no effect on lit tests.

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

The changes made in D88594 caused the test OpenMP/driver.c to fail on a 32-bit host becuase it was offloading to a 64-bit architecture by default. The offloading test was moved to a new file and a feature was added to the lit config to check for a 64-bit host.

Reviewed By: jdoerfert

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

LLVM IR currently assumes some form of forward progress. This form is
not explicitly defined anywhere, and is the cause of miscompilations
in most languages that are not C++11 or later. This implicit forward progress
guarantee can not be opted out of on a function level nor on a loop
level. Languages such as C (C11 and later), C++ (pre-C++11), and Rust
have different forward progress requirements and this needs to be
evident in the IR.

Specifically, C11 and onwards (6.8.5, Paragraph 6) states that "An
iteration statement whose controlling expression is not a constant
expression, that performs no input/output operations, does not access
volatile objects, and performs no synchronization or atomic operations
in its body, controlling expression, or (in the case of for statement)
its expression-3, may be assumed by the implementation to terminate."
C++11 and onwards does not have this assumption, and instead assumes
that every thread must make progress as defined in [intro.progress] when
it comes to scheduling.

This was initially brought up in [0] as a bug, a solution was presented
in [1] which is the current workaround, and the predecessor to this
change was [2].

After defining a notion of forward progress for IR, there are two
options to address this:
1) Set the default to assuming Forward Progress and provide an opt-out for functions and an opt-in for loops.
2) Set the default to not assuming Forward Progress and provide an opt-in for functions, and an opt-in for loops.

Option 2) has been selected because only C++11 and onwards have a
forward progress requirement and it makes sense for them to opt-into it
via the defined `mustprogress` function attribute.  The `mustprogress`
function attribute indicates that the function is required to make
forward progress as defined. This is sharply in contrast to the status
quo where this is implicitly assumed. In addition, `willreturn` implies `mustprogress`.

The background for why this definition was chosen is in [3] and for why
the option was chosen is in [4] and the corresponding thread(s). The implementation is in D85393, the
clang patch is in D86841, the LoopDeletion patch is in D86844, the
Inliner patches are in D87180 and D87262, and there will be more
incoming.

[0] https://bugs.llvm.org/show_bug.cgi?id=965#c25
[1] https://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html
[2] https://reviews.llvm.org/D65718
[3] https://lists.llvm.org/pipermail/llvm-dev/2020-September/144919.html
[4] https://lists.llvm.org/pipermail/llvm-dev/2020-September/145023.html

Reviewed By: jdoerfert, efriedma, nikic

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

SourceLocation implements `operator<`, so `SourceLocation`-s can be used
as keys in `std::map` directly, there is no need to extract the internal
representation.

Since the `operator<` simply compares the internal representations of
its operands, this patch does not introduce any functional changes.

Reviewed By: dexonsmith

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

This patch adds a set of tests where information from assumes can be
used to improve the trip multiple.

See PR47904.

[DAGCombiner][PowerPC] Remove isMulhCheaperThanMulShift TLI hook, Use isOperationLegalOrCustom directly instead.

MULH is often expanded on targets.
This patch removes the isMulhCheaperThanMulShift hook and uses
isOperationLegalOrCustom instead.

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

For testing purposes I need a way to build and install FileCheck and
yaml2obj. I had to choose between making FileCheck an LLVM tool and
making obj2yaml and yaml2obj utilities. I think the distinction is
rather arbitrary but my understanding is that tools are things meant for
the toolchain while utilities are more used for things like testing,
which is the case here.

The functional difference is that these tools now end up in the
${LLVM_UTILS_INSTALL_DIR}, which defaults to the ${LLVM_TOOLS_INSTALL_DIR}.
Unless you specified a different value or you added obj2yaml and
yaml2obj to ${LLVM_TOOLCHAIN_TOOLS}, this patch shouldn't change
anything.

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

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

- Extend hip-toolchin-features.hip to also check the lld attributes
  are passed correctly.

- Add check for cumode attributes.

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

- Use file_check -LABEL markers to prevent false positives being
  reported due to messages from different tests causing success to be
  reported.

- Add checks for all the run commands for more robust testing.

- Add checks for the absence of errors.

- Name and order tests more sensibly.

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

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

It appears that the released version of clang that supports constexpr
destructors is clang 10 and the oldest one that accepts -std=c++2a is 5,
so mark these as UNSUPPORTED for clang-5 to clang-9.

Reviewed By: #libc, ldionne

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

	From OpenACC 3.0 Standards document
	840 • A program may not branch into or out of an OpenACC parallel construct.
	Exits are allowed provided it does not cause an exit outside the parallel region.

	Test case exits out of the inner do loop, but it is still inside the parallel region.
	Patch tries to extract labels from block attached to a construct,
	If the exit is to a label not in the collected list then flags an error.

Reviewed By: tskeith

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

Define all the fuzzing tests in libcxx/test/libcxx/fuzzing, and get
rid of the ad-hoc libcxx/fuzzing directory, which wasn't properly
integrated with the build system or test suite.

As a fly-by change, this also reduces the dependencies of fuzzing tests
on large library components like <iostream>, to make them work on more
platforms.

Fixes a number of stage2 buildbots that were failing when I generalized the m_ConstantInt() logic - that didn't match for pointer types but m_Zero() does......

Allow logging final rewards. A final reward is logged only once, and is
serialized as all-zero values, except for the last one.

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

  NFC patch simply updates the commands.md documentation contents with missing
  links to the DexLimitSteps and DexLabel command documentation.

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

  Author:    Nabeel Omer <nabeel.omer@sony.com>