This reverts commit 657d20dc.  A correctness problem was reported against the review and the fix warrants re-review.

MSVC makes these string literals [1][2].

[1] https://godbolt.org/z/6vnTzbExx
[2] https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170

Fixes #114

Initial commit didn't check if there was a function name when stepping through expressions ignoring parens.

Reviewed By: aaron.ballman

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

Clang currently updates the mtime of .timestamp files on each load of the corresponding .pcm file. This is not necessary. In a given build session, Clang only needs to write the .timestamp file once, when we first validate the input files. This patch makes it so that we only touch the .timestamp file when it's older than the build session, alleviating some filesystem contention in clang-scan-deps.

Reviewed By: benlangmuir

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

Add scheduling information for vector extension in SiFive7,
while using new LMUL & SEW scheduling constructs.

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

When building with compilers that do not support the Blocks extension,
we would fail to compile due to the missing type specifier on the
`typedef`.  This should repair those builds.

Fixes: #62640

Reviewed By: ldionne, #libc

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

We recently added implications for F and D to Zve32f and Zve64d
which V implies. So these have become redundant.

The implementation of these methods is not reliant on the availability
of the Blocks extension in the compiler.  However, when building on
Windows, the interface declaration is important for the attribution of
the DLL storage.  Without the attribution, the method implementation is
built but not made available as part of the ABI.  Use a check for the
blocks extension to determine how method signature is viewed rather than
controlling whether it is part of the interface.

This reverts commit 103fc0f6.
Causes a clang crash in ChromeOS builds.
Testcase provided at D149344.

- Rename `LimitForRegisterSize` to `MaxVFOnly` to make the meaning of the limit less ambiguous
- Rename `OpsWidth` to `ActualVF`, which makes it clear that this is the VF we are using for vectorization.
- Replace the if-else code for the initialization of OpsWidth with an std::min.

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

The generic ABI says:

> Padding is present, if necessary, to ensure 8 or 4-byte alignment for the next note entry (depending on whether the file is a 64-bit or 32-bit object). Such padding is not included in descsz.

Our parsing code currently aligns n_namesz. Fix the bug by aligning the start
offset of the descriptor instead. This issue has been benign because the primary
uses of sh_addralign=8 notes are `.note.gnu.property`, where
`sizeof(Elf_Nhdr) + sizeof("GNU") = 16` (already aligned by 8).

In practice, many 64-bit systems incorrectly use sh_addralign=4 notes.
We can use sh_addralign (= p_align) to decide the descriptor padding.
Treat an alignment of 0 and 1 as 4. This approach matches modern GNU readelf
(since 2018).

We have a few tests incorrectly using sh_addralign=0. We may make our behavior
stricter after fixing these tests.

Linux kernel dumped core files use `p_align=0` notes, so we need to support the
case for compatibility.

Reviewed By: jhenderson

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

Reviewed By: ldionne, #libc

Spies: sstefan1, jplehr, arichardson, libcxx-commits, miyuki

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

This reverts commit 624dcd8d.
Breaks check-llvm on Windows, see https://reviews.llvm.org/D149996#4332381

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

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

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

Remove old clause operands from acc.kernels operation since
the new dataOperands is now in place.
private and firstprivate will receive some redesign but are
not part of the new dataOperands.

Depends on D150224

Reviewed By: vzakhari

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

Remove old clause operands from acc.serial operation since
the new dataOperands is now in place.
private and firstprivate will receive some redesign but are
not part of the new dataOperands.

Depends on D150207

Reviewed By: vzakhari

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

The order of operand in clauses that are decomposed was not
preserved. This patch change how operands are handled and preserve
the user ordering for the entry data operation on the acc.parallel
operation.

Reviewed By: vzakhari

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

D149909 was missing the check lines in the ops.mlir lit test.

Reviewed By: vzakhari

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

The order of operand in clauses that are decomposed was not
preserved. This patch change how operands are handled and preserve
the user ordering for the entry data operation on the acc.data
operation.

Reviewed By: vzakhari

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

This patch enables signed truncation check transforms for i8 on rv32 when XVT is i64 and Zbb is enabled.

It is a small improvement of D149977.

Reviewed By: craig.topper

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

Revert "[clang] [test] Narrow down MSVC specific behaviours from "any windows" to only MSVC/clang-cl"

This reverts commit 7f037e56.
Breaks tests, see https://reviews.llvm.org/D149997#4331937

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

Contributed by @jankuehle!

Users can choose to only import/export the type of the symbol (not value nor namespace) by adding a `type` keyword, e.g.:

```
import type {x} from 'y';
import {type x} from 'y';
export type {x};
export {type x};
```

Previously, this was not handled and would:
- Terminate import sorting
- Remove the space before the curly bracket in `export type {`

With this change, both formatting and import sorting work as expected.

Reviewed By: MyDeveloperDay, krasimir

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

This reverts commit 21f226fc. Crashes on
this test case:

define void @test2() nounwind {
entry:
  br label %bb.nph

bb.nph:                                           ; preds = %entry
  %and.i13521 = and <4 x i1> undef, undef
  br label %for.body

for.body:                                         ; preds = %for.body, %bb.nph
  %or.i = select <4 x i1> %and.i13521, <4 x i32> undef, <4 x i32> undef
  br i1 false, label %for.body, label %for.end

for.end:                                          ; preds = %for.body, %entry
  ret void
}

Emit FNMADD instead of FNEG(FMADD) for optimization levels
above Oz when fast-math flags (nsz+contract) permit it.

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

These don't require any special handling, apart checking for unsupported
metadata, which is already implemented.

Reviewed By: gysit

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

This also fixes a possible use-after-free in the IdentifierNamingCheck.

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

The new test case showed that the NoPHIs flag needs to be cleared.

Original commit message:

[SystemZ] Bugfix in expansion of memmem operations.

Since NC, OC, and XC clobber CC, the EXRL_Pseudo targeting these must also be
marked to do so.

Original patch by uweigand.

Reviewed by: uweigand

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

Fixes: https://github.com/llvm/llvm-project/issues/62572

This is showing up on our profiles with ~100ms contribution @95th% for
buildAST latencies.
The patch is unlikely to address it all, but should help with some low-hanging
fruit.

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