Building Flang on Windows *is supported*. It's been tested there for
quite a while now:
  * https://lab.llvm.org/buildbot/#/builders/172

Submitting this without a review as the current note in the readme file
is clearly incorrect.

These assert that there are no "useless" assertzext/assertsext nodes
(that assert a wider width than a following trunc), but I don't think
there is anything preventing such nodes from reaching this code.
I don't think the assertion is relevant for correctness of this
transform either -- if such an assert is present, then the other
one will always be to a smaller width, and we'll pick that one.
The assertion dates back to D37017.

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

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

Add complex.conj op to calculate the complex conjugate which is widely used for the mathematical operation on the complex space.

Reviewed By: pifon2a

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

Follow-up to c031378c .
The class is mostly consistent now.

This supports lowering parse-tree to MLIR for threadprivate directive
following the OpenMP 5.1 [2.21.2] standard. Take the following as an
example:

```
program m
  integer, save :: i
  !$omp threadprivate(i)
  call sub(i)
  !$omp parallel
    call sub(i)
  !$omp end parallel
end
```
```
func.func @_QQmain() {
  %0 = fir.address_of(@_QFEi) : !fir.ref<i32>
  %1 = omp.threadprivate %0 : !fir.ref<i32> -> !fir.ref<i32>
  fir.call @_QPsub(%1) : (!fir.ref<i32>) -> ()
  omp.parallel   {
    %2 = omp.threadprivate %0 : !fir.ref<i32> -> !fir.ref<i32>
    fir.call @_QPsub(%2) : (!fir.ref<i32>) -> ()
    omp.terminator
  }
  return
}
```

A threadprivate operation (omp.threadprivate) is created for all
references to a threadprivate variable. The runtime will appropriately
return a threadprivate var (%1 as above) or its copy (%2 as above)
depending on whether it is outside or inside a parallel region. For
threadprivate access outside the parallel region, the threadprivate
operation is created in instantiateVar. Inside the parallel region, it
is created in createBodyOfOp.

One new utility function collectSymbolSet is created for collecting
all the variables with a property within a evaluation, which may be one
Fortran, or OpenMP, or OpenACC construct.

Reviewed By: kiranchandramohan

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

The previous XArrayCoorOp conversion forgot to change getting the
operands from OpAdaptor for upper bound and step of slice. This leads to
the fail of incompatible of types of codegen when slices are index type.

Reviewed By: kiranchandramohan, schweitz

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

The previous semantic analysis does not consider when the last part-ref
is scalar or complex part. Refactor the previous code and bring all the
checks into one place. The check starts from the designator by
extracting the dataref wrapped including the substring and complex part
and recursively check the base objects.

Co-authored-by: Peter Klausler <pklausler@nvidia.com>

Reviewed By: klausler

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

Rewrite the introduction of the page to state clearly the goals of
LLVM's libc project.

Reviewed By: sivachandra

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

Assume functions might recurse (see `reAssume` or `tryRearrange`).
During the recursion, the State might not change anymore, that means we
reached a fixpoint. In this patch, we avoid infinite recursion of assume
calls by checking already visited States on the stack of assume function
calls. This patch renders the previous "workaround" solution (D47155)
unnecessary. Note that this is not an NFC patch. If we were to limit the
maximum stack depth of the assume calls to 1 then would it be equivalent
with the previous solution in D47155.

Additionally, in D113753, we simplify the symbols right at the beginning
of evalBinOpNN. So, a call to `simplifySVal` in `getKnownValue` (added
in D51252) is no longer needed.

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

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

Fix https://github.com/llvm/llvm-project/issues/55816

Before this patch, MCConstantExpr were reused, but MCSymbolExpr were
not. To reuse symbol value, this patch added a DenseMap to record the
symbol value.

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

Since version 0.8 we've added:

* Switched PDLL and TableGen to use incremental doc updates
* Added support to PDLL for inlay hints

These allow for displaying additional inline information,
such as the types of variables, names operands/results,
constraint/rewrite arguments, etc. This requires a bump in the
vscode extension to a newer version, as inlay hints are a new LSP feature.

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

This is much more efficient over the full mode, as it only requires sending
smalls chunks of files. It also works around a weird command ordering
issue (full document updates are being sent after other commands like
code completion) in newer versions of vscode.

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

Currently, we only check !nosanitize metadata for instruction passed to function `getInterestingMemoryOperands()` or instruction which is a cannot return callable instruction.
This patch add this check to any instruction.

E.g. ASan shouldn't instrument the instruction inserted by UBSan/pointer-overflow.

Reviewed By: vitalybuka

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

We should not mark a function as "referenced" if we call it within a
ConstantExpr, because the expression will be folded to a value in LLVM
IR. To prevent emitting consteval function declarations, we should not "jump
over" a ConstantExpr when it is a top-level ParmVarDecl's subexpression.

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

Reviewed By: erichkeane, aaron.ballman, ChuanqiXu

Differenitial Revision: https://reviews.llvm.org/D119646

Casting to non-void causes
  expression result unused [-Wunused-value]

Reviewed By: rriddle

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

DebugTypeVisitor

This recommits d1346e2e. I've added a line to the test case to enable it
only on assert builds.

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

This reverts commit d1346e2e.

The commit broke a few bots.

This commit beefs up the documentation for MLIR language servers by
adding proper documentations/examples/etc for the provided TableGen
language server capabilities. Given that this documentation is also used
for the vscode extension, this commit also updates the user facing vscode
extension documentation.

Note that the images referenced in the new documentation are hosted on
the website, and will be commited to mlir-www shortly after this commit
lands.

Refactor the tablegen definitions for relaxed SIMD min/max instructions to use a
shared RelaxedBinary multiclass modeled on the existing SIMDBinary multiclass. A
future commit will add further instruction definitions that use RelaxedBinary.

Also rename the SIMD_RELAXED_CONVERT multiclass to RelaxedConvert to better fit
existing naming conventions.

Reviewed By: aheejin

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

Clearly I cannot spell...

Another case of reading a value from a struct that has been byte
swapped to write out. This should address the failure on the ppcbe bot.

Some libraries (e.g., arm64rt.lib) from the Windows WDK (version 10.0.22000.0)
contain an undocumented special member '/<ECSYMBOLS>/'. This causes llvm-lib to
fail with the following error:

"truncated or malformed archive (long name offset characters after the '/' are
not all decimal numbers: '<ECSYMBOLS>/' for archive member header at offset 162)"

The '/<ECSYMBOLS>/' member does not seem to be documented anywhere, but might be
related to the ARM64EC ABI Microsoft announced last year.

https://blogs.windows.com/windowsdeveloper/2021/06/28/announcing-arm64ec-building-native-and-interoperable-apps-for-windows-11-on-arm/

Reviewed By: thieta, thakis

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

This patch adds support for parsing the DXIL part data into the
ObjectYAML tooling.

The DXIL part has additional headers describing the shader and bitcode
data and stores serialized bitcode after the headers.

Depends on D124945

Reviewed By: kuhar

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

Lefover from review for https://reviews.llvm.org/D126509#inline-1218795

As there 3 intercepts that depend on libresolv, link tests in ./configure scripts may be confuse by the presence of resolv symbols (i.e. dn_expand) even with -lresolv and get a runtime error.

Android provides the functionality in libc.

https://reviews.llvm.org/D122849
https://reviews.llvm.org/D126851

Reviewed By: eugenis, MaskRay

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

Transpose operations on constant data were getting folded during the
canonicalization process. This has compile time cost proportional to
the constant size. Moving this to a separate pass to enable optionality
and flexibility of how such scenarios can be handled.

Reviewed By: rsuderman, jpienaar, stellaraccident

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

Our rules to determine if the throw expression are within the variable
scope were giving a false negative result in case the throw expression
would appear within a decltype in a nested function declaration.

Per P2266R3, the relevant rule is: [expr.prim.id.unqual]/2
```
    if the id-expression (possibly parenthesized) is the operand of a throw-expression, and names an implicitly movable entity that belongs to a scope that does not contain the compound-statement of the innermost lambda-expression, try-block , or function-try-block (if any) whose compound-statement or ctor-initializer encloses the throw-expression.
```

This fixes PR54341.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: rsmith

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

This reverts commit 99a83b12.

This reverts commit 60798044.

BasicTTI needs to return an invalid cost for scalable vectors instead of crash.  Without this, it is impossible to write tests for missing functionality in a target.

Summary: Emscripten now handles/supports this new mode.

Subscribers: dschuff, jgravelle-google, aheejin, sunfish, cfe-commits

Tags: #clang

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

Currently, only custom sections can be selected by operations that use section
names, because only custom sections have explicit names (whereas known sections
have names defined by the spec and only use their indices in the binary format).
This CL makes objdopy use the spec-defined names for these sections, allowing
them to be used in operations such as dumping and removal.

This is a prerequisite for fixing
https://github.com/emscripten-core/emscripten/issues/13084

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