Reviewed By: nicolasvasilache

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

The crash happens in clang::driver::tools::SplitDebugName when Output is
InputInfo::Nothing. It doesn't happen with standalone clang driver because
output is created in Driver::BuildJobsForActionNoCache.

Example backtrace:
```
* thread #1, name = 'clangd', stop reason = hit program assert
  * frame #0: 0x00007ffff5c4eacf libc.so.6`raise + 271
    frame #1: 0x00007ffff5c21ea5 libc.so.6`abort + 295
    frame #2: 0x00007ffff5c21d79 libc.so.6`__assert_fail_base.cold.0 + 15
    frame #3: 0x00007ffff5c47426 libc.so.6`__assert_fail + 70
    frame #4: 0x000055555dc0923c clangd`clang::driver::InputInfo::getFilename(this=0x00007fffffff9398) const at InputInfo.h:84:5
    frame #5: 0x000055555dcd0d8d clangd`clang::driver::tools::SplitDebugName(JA=0x000055555f6c6a50, Args=0x000055555f6d0b80, Input=0x00007fffffff9678, Output=0x00007fffffff9398) at CommonArgs.cpp:1275:40
    frame #6: 0x000055555dc955a5 clangd`clang::driver::tools::Clang::ConstructJob(this=0x000055555f6c69d0, C=0x000055555f6c64a0, JA=0x000055555f6c6a50, Output=0x00007fffffff9398, Inputs=0x00007fffffff9668, Args=0x000055555f6d0b80, LinkingOutput=0x0000000000000000) const at Clang.cpp:5690:33
    frame #7: 0x000055555dbf6b54 clangd`clang::driver::Driver::BuildJobsForActionNoCache(this=0x00007fffffffb5e0, C=0x000055555f6c64a0, A=0x000055555f6c6a50, TC=0x000055555f6c4be0, BoundArch=(Data = 0x0000000000000000, Length = 0), AtTopLevel=true, MultipleArchs=false, LinkingOutput=0x0000000000000000, CachedResults=size=1, TargetDeviceOffloadKind=OFK_None) const at Driver.cpp:5618:10
    frame #8: 0x000055555dbf4ef0 clangd`clang::driver::Driver::BuildJobsForAction(this=0x00007fffffffb5e0, C=0x000055555f6c64a0, A=0x000055555f6c6a50, TC=0x000055555f6c4be0, BoundArch=(Data = 0x0000000000000000, Length = 0), AtTopLevel=true, MultipleArchs=false, LinkingOutput=0x0000000000000000, CachedResults=size=1, TargetDeviceOffloadKind=OFK_None) const at Driver.cpp:5306:26
    frame #9: 0x000055555dbeb590 clangd`clang::driver::Driver::BuildJobs(this=0x00007fffffffb5e0, C=0x000055555f6c64a0) const at Driver.cpp:4844:5
    frame #10: 0x000055555dbe6b0f clangd`clang::driver::Driver::BuildCompilation(this=0x00007fffffffb5e0, ArgList=ArrayRef<const char *> @ 0x00007fffffffb268) at Driver.cpp:1496:3
    frame #11: 0x000055555b0cc0d9 clangd`clang::createInvocation(ArgList=ArrayRef<const char *> @ 0x00007fffffffbb38, Opts=CreateInvocationOptions @ 0x00007fffffffbb90) at CreateInvocationFromCommandLine.cpp:53:52
    frame #12: 0x000055555b378e7b clangd`clang::clangd::buildCompilerInvocation(Inputs=0x00007fffffffca58, D=0x00007fffffffc158, CC1Args=size=0) at Compiler.cpp:116:44
    frame #13: 0x000055555895a6c8 clangd`clang::clangd::(anonymous namespace)::Checker::buildInvocation(this=0x00007fffffffc760, TFS=0x00007fffffffe570, Contents= Has Value=false ) at Check.cpp:212:9
    frame #14: 0x0000555558959cec clangd`clang::clangd::check(File=(Data = "build/test.cpp", Length = 64), TFS=0x00007fffffffe570, Opts=0x00007fffffffe600) at Check.cpp:486:34
    frame #15: 0x000055555892164a clangd`main(argc=4, argv=0x00007fffffffecd8) at ClangdMain.cpp:993:12
    frame #16: 0x00007ffff5c3ad85 libc.so.6`__libc_start_main + 229
    frame #17: 0x00005555585bbe9e clangd`_start + 46
```

Test Plan: ninja ClangDriverTests && tools/clang/unittests/Driver/ClangDriverTests

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

Provide platform-specific x87 FPU definitions and operations

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

Fixed compilation error and reudndant copy warning

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

Documentation for TargetLowering::getShiftAmountTy says that LegalTypes
should generally be true during type legalization, so this patch does
that.

On AMDGPU the effect is that we use i32 (a sane type) instead of i64
(pointer sized type) for more shift amounts, which in turn allows more
formation of rotates and funnel shifts pre-legalization.

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

This is a reboot of the original design and implementation by
Nicolai Haehnle <nicolai.haehnle@amd.com>:
https://reviews.llvm.org/D85603

This change also obsoletes an earlier attempt at restarting the work on
convergence tokens:
https://reviews.llvm.org/D104504

Changes relative to D85603:

 1. Clean up the definition of a "convergent operation", a convergent
    call and convergent function.
 2. Clean up the relationship between dynamic instances, sets of threads and
    convergence tokens.
 3. Redistribute the formal rules into the definitions of the convergence
    intrinsics.
 4. Expand on the semantics of entering a function from outside LLVM,
    and the environment-defined outcome of the entry intrinsic.
 5. Replace the term "cycle" with "closed path". The static rules are defined
    in terms of closed paths, and then a relation is established with cycles.
 6. Specify that if a function contains a controlled convergent operation, then
    all convergent operations in that function must be controlled.
 7. Describe an optional procedure to infer tokens for uncontrolled convergent
    operations.
 8. Introduce controlled maximal convergence-before and controlled m-converged
    property as an update to the original properties in UniformityAnalysis.
 9. Additional constraint that a cycle heart can only occur in the header of a
    reducible cycle (natural loop).

Reviewed By: nhaehnle

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

Add more legal types for SMIN, SMAX, UMIN, UMAX in cost modelling for AArch64

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

This adds operations for binary multiplicative arithmetic operators to
EmitC. The input and output arguments for the remainder operator are
restricted to index (emitted as size_t), integers and the EmitC opaque
types (as the operator can be overloaded for a custom type). The
multiplication and division operator further support floating point
numbers.

Reviewed By: jpienaar

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

Clarify a few diagnostics so that they are more consistent with the
corresponding condition. For example:

```
  if (positionAttr.size() >
      static_cast<unsigned>(getSourceVectorType().getRank()))
```

should lead to ("no greater than"):

```
    return emitOpError(
        "expected position attribute of rank no greater than vector rank");

```

as opposed to ("smaller"):

```
    return emitOpError(
        "expected position attribute of rank smaller than vector rank");
```

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

Fixes two places where we relied on map iteration order when processing
values, which leaked nondeterminism into the generated SAT formulas.
Adds a couple of tests that directly assert that the SAT system is
equivalent on each run.

It's desirable that the formulas are deterministic based on the input:

 - our SAT solver is naive and perfermance is sensitive to even simple
   semantics-preserving transformations like A|B to B|A.
   (e.g. it's likely to choose a different variable to split on).
   Timeout failures are bad, but *flaky* ones are terrible to debug.
 - similarly when debugging, it's important to have a consistent
   understanding of what e.g. "V23" means across runs.

---

Both changes in this patch were isolated from a nullability analysis of
real-world code which was extremely slow, spending ages in the SAT
solver at "random" points that varied on each run.
I've included a reduced version of the code as a regression test.

One of the changes shows up directly as flow-condition nondeterminism
with a no-op analysis, the other relied on bits of the nullability
analysis but I found a synthetic example to show the problem.

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

This covers
 * P2558R2 (C++, wg21.link/P2558)
 * N2701 (C, https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2701.htm)
 * N3124 (C, https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3124.pdf)

This patch
 * Disallow representing $ as a UCN in all language mode, which did not
   properly work (see GH62133), and which in made ill-formed in
   C++ and C by P2558 and N3124 respectively
 * Allow a UCN for any character in C2X, in string and character
   literals

Fixes #62133

Reviewed By: #clang-language-wg, tahonermann

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

This patch generalizes the fold implemented by foldAndOrOfICmpEqZeroAndICmp,
which are:

(icmp eq X, 0) | (icmp ult Other, X) -> (icmp ule Other, X-1)
(icmp ne X, 0) & (icmp uge Other, X) -> (icmp ugt Other, X-1)

to the following:

(icmp eq X, C) | (icmp ult Other, (X - C)) -> (icmp ule Other, (X - (C + 1)))
(icmp ne X, C) & (icmp uge Other, (X - C)) -> (icmp ugt Other, (X - (C + 1)))

The function foldAndOrOfICmpEqZeroAndICmp is also renamed to
foldAndOrOfICmpEqConstantAndICmp to reflect the changes.

Proofs: https://alive2.llvm.org/ce/z/yXGv6q

Fixes #63749.

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

Create test cases for the following two folds:

(icmp eq X, C) | (icmp ult Other, (X - C)) -> (icmp ule Other, (X - (C + 1)))
(icmp ne X, C) & (icmp uge Other, (X - C)) -> (icmp ugt Other, (X - (C + 1)))

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

This CL adds a new discriminator pass. Also adds a new sample profile
loading pass when MFS is enabled.

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

There's some documentation of this concept at
https://clang.llvm.org/docs/DataFlowAnalysisIntro.html
but it would be nice to have it closer to the code.

I also was laboring under an obvious but wrong mental model that
the flow condition token represented "execution reached this point",
I'd like to explicitly call that out as wrong.

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

Redundant XXSWAPD has been observed on little-endian in D138883 test
case. Remove those associated with vector splat instructions.

Reviewed By: shchenz

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

I added a test for this as the ongoing migration to strict handling of value categories (see https://discourse.llvm.org/t/70086) will change the code that handles this case. It turns out we already didn't handle this correctly, so I fixed the existing implementation.

Depends On D154961

Reviewed By: xazax.hun

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

Previously, we were including these fields only in the specific instance that was initialized by the `InitListExpr`, but not in other instances of the same type. This is inconsistent and error-prone.

Depends On D154952

Reviewed By: xazax.hun, gribozavr2

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

These simplify the code in their own right, but they are also useful in that they minimize the number of changes that will need to be made when then API of `AggregateStorageLocation` and `StructValue` changes as part of the migration to strict handling of value categories (see https://discourse.llvm.org/t/70086).

Depends On D154949

Reviewed By: xazax.hun, gribozavr2

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

For context, see https://reviews.llvm.org/D154935.

Depends On D154935

Reviewed By: ymandel, xazax.hun

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

These insulate tests against changes to the `getChild()` functions of `AggregateStorageLocation` and `StructValue` that will happen as part of the migration to strict handling of value categories (see https://discourse.llvm.org/t/70086 for details):

- `AggregateStorageLocation::getChild()` will soon return a `StorageLocation *`
  instead of a `StorageLocation &`. When this happens, `getFieldValue()` will be
  changed to return null if `AggregateStorageLocation::getChild()` returns null;
  test code will not need to change as it should already be checking whether the
  return value of `getFieldValue()` is null.

- `StructValue::getChild()` will soon return a `StorageLocation *` instead of a
  `Value *`. When this happens, `getFieldValue()` will be changed to look up the
  `Value *` in the `Environment`. Again, test code will not need to change.

The test helpers will continue to serve a useful purpose once the API changes are complete, so the intent is to leave them in place.

This patch changes DataflowEnvironmentTest.cpp and RecordOpsTest.cpp to use the test helpers. TransferTest.cpp will be changed in an upcoming patch to help keep patch sizes manageable for review.

Depends On D154934

Reviewed By: ymandel, xazax.hun, gribozavr2

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

Soon, it will no longer be possible to default-construct `StructValue`. For details, see https://discourse.llvm.org/t/70086.

For completeness, also add a test that `areEquivalentValues()` on different `IntegerValue`s returns false.

Reviewed By: xazax.hun, gribozavr2

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

Currently the transfer splitting patterns will generate an invalid cast
when the source memref for a transfer op has a non-default memory space.
This is handled by first introducing a `memref.memory_space_cast` in
such cases.

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

Reviewed By: fhahn

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

I got confused and must have closed the wrong revision for
https://reviews.llvm.org/D149291

asserts get compiled to empty when built in opt mode, so that makes
certain tests fail, such as emulate-unsupported-floats.mlir.test.

This removes the assert altogether, which is also suboptimal, but
I have reported to the original author.

Replace the last user of CannotBeOrderedLessThanZero with new
version. Makes assumes work in this case.

Found a bug in ElfObjectFile.h that occurred when there was an invalid Symbol Name in an object file. This error affected the behavior of the Expected<> value and leading it to abort, rather than behave as normal. I found this as I was adding tests to llvm-cm, as prompted by @jhenderson.

Without this fix, upon encountering an invalid symbol and trying tot l get its name, the program states that
```Expected<T> must be checked before access or destruction```
 and aborts.

Reviewed By: MaskRay

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

Reformat the source code with RemoveParentheses set to ReturnStatement.

/Users/jiefu/llvm-project/clang/lib/Driver/ToolChains/Clang.cpp:7345:56: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
      (WholeProgramVTables || SanitizeArgs.needsLTO()) &&
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
/Users/jiefu/llvm-project/clang/lib/Driver/ToolChains/Clang.cpp:7345:56: note: place parentheses around the '&&' expression to silence this warning
      (WholeProgramVTables || SanitizeArgs.needsLTO()) &&
                                                       ^
      (
1 error generated.

More robust association between the kernels and lds struct.

Use poison instead of value() for lookup table elements introduced by dynamic lds lowering.

Extracted from D154946, new test from there verbatim. Segv fixed.

Fixes issues/63338

Fixes SWDEV-404491

Reviewed By: arsenm

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

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

  - Unified LTO default for all PlayStation targets
  - Add default case to tests
  - SplitLTOUnit not default for PS4
  - Remove ignorelist requirement to address buildbot failures

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

On Linux crt is typically use in combination with builtins. In the Clang
driver the use of builtins and crt is controlled by the --rtlib option.
Both builtins and crt also have similar build requirements where they
need to be built before any other runtimes and must avoid dependencies.
We also want builtins and crt these to be buildable separately from the
rest of compiler-rt for bootstrapping purposes. Given how simple crt is,
rather than maintaining a separate directory with its own separate build
setup, it's more efficient to just move crt into builtins. We still use
separate CMake option to control whether to built crt same as before.

This is an alternative to D89492 and D136664.

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