Such pointers are often used by the core parts of mingw-w64, to locally
define a function that might have been referred to with dllimport.

(MSVC style linkers can automatically provide such pointers, if there
are undefined references to `__imp_<func>` left but a definition of
`<func>` is available - although this prints the warning LNK4217. GNU ld
doesn't do this, so in mingw-w64, such things are generally handled by
manually providing the relevant `__imp_` pointers.)

Make sure that a full LTO build, that does LTO of both the `__imp_`
pointer and the object file referencing it, successfully resolves such
symbols.

This solution admittedly probably reduces the effect of the LTO
compilation if there would happen to be `__imp_` prefixed symbols
included, in LTO objects, that aren't actually used. Such symbols are
mostly used in the base toolchain, not often in user code, and usually
only the relevant object files are linked in anyway.

This fixes https://github.com/llvm/llvm-project/issues/57982.

This patch adds the following semantic check for target update

```
At least one motion-clause must be specified.
```

A motion clause is either a `to` or a `from` clause.

This patch also adds a test for the following semantic check which was
already supported.

```
At most one nowait clause can appear on the directive.
```

This patch fixes:

  clang/lib/Serialization/ASTWriterStmt.cpp:576:3: error: default
  label in switch which covers all enumeration values
  [-Werror,-Wcovered-switch-default]

  clang/lib/Serialization/ASTReaderStmt.cpp:561:3: error: default
  label in switch which covers all enumeration values
  [-Werror,-Wcovered-switch-default]

This reverts commit 28ae42e6.

The assert in getIConstantVRegVal was not updated for this change.
The ValAndVReg->VReg == VReg check fails if any look through happens.

RISC-V was the only target using the lookthrough functionality, but I'm
not sure it was needed so I'm removing that too.

Since PR's #69343 and #67166 we probably have enough support for
`llvm.ptrmask` to make it preferable to the GEP stategy.

Closes #71238

This supports any G_FCONSTANT for F and D extensions.

This builds the constant in the integer domain and moves it to FP
using either FMV or the stack.

Eventually we should use the constant pool for some constants that
require many instructions, but this is a good starting point to
get something working.

Move the G_CONSTANT specific parts up to the switch that calls it.

The materialization function will be used by G_FCONSTANT too.

The only functional change is we now create COPY from X0 for the 0
case instead of changing the G_CONSTANT in place.

- Literal ops are emitted as unused variables under declare-variables-at-top
- Translator fails to emit literals used as emitc.call arguments

[DAG] Don't fold (zext (bitop (load x), cst)) -> (bitop (zextload x), (zext cst)) if the zext is free

Prevents an infinite loop if we've been trying to narrow the bitop to a more preferable type

The goal of this patch is to refine how the `SVal` base and sub-kinds
are represented by forming one unified enum describing the possible
SVals. This means that the `unsigned SVal::Kind` and the attached
bit-packing semantics would be replaced by a single unified enum. This
is more conventional and leads to a better debugging experience by
default. This eases the need of using debug pretty-printers, or the use
of runtime functions doing the printing for us like we do today by
calling `Val.dump()` whenever we inspect the values.

Previously, the first 2 bits of the `unsigned SVal::Kind` discriminated
the following quartet: `UndefinedVal`, `UnknownVal`, `Loc`, or `NonLoc`.
The rest of the upper bits represented the sub-kind, where the value
represented the index among only the `Loc`s or `NonLoc`s, effectively
attaching 2 meanings of the upper bits depending on the base-kind. We
don't need to pack these bits, as we have plenty even if we would use
just a plan-old `unsigned char`.

Consequently, in this patch, I propose to lay out all the (non-abstract)
`SVal` kinds into a single enum, along with some metadata (`BEGIN_Loc`,
`END_Loc`, `BEGIN_NonLoc`, `END_NonLoc`) artificial enum values, similar
how we do with the `MemRegions`.

Note that in the unified `SVal::Kind` enum, to differentiate
`nonloc::ConcreteInt` from `loc::ConcreteInt`, I had to prefix them with
`Loc` and `NonLoc` to resolve this ambiguity.
This should not surface in general, because I'm replacing the
`nonloc::Kind` enum items with `inline constexpr` global constants to
mimic the original behavior - and offer nicer spelling to these enum
values.

Some `SVal` constructors were not marked explicit, which I now mark as
such to follow best practices, and marked others as `/*implicit*/` to
clarify the intent.
During refactoring, I also found at least one function not marked
`LLVM_ATTRIBUTE_RETURNS_NONNULL`, so I did that.

The `TypeRetrievingVisitor` visitor had some accidental dead code,
namely: `VisitNonLocConcreteInt` and `VisitLocConcreteInt`.

Previously, the `SValVisitor` expected visit handlers of
`VisitNonLocXXXXX(nonloc::XXXXX)` and `VisitLocXXXXX(loc::XXXXX)`, where
I felt that envoding `NonLoc` and `Loc` in the name is not necessary as
the type of the parameter would select the right overload anyways, so I
simplified the naming of those visit functions.

The rest of the diff is a lot of times just formatting, because
`getKind()` by nature, frequently appears in switches, which means that
the whole switch gets automatically reformatted. I could probably undo
the formatting, but I didn't want to deviate from the rule unless
explicitly requested.

This commit removes all references to typed pointers. Typed pointers
have been deprecated for a while now and they will be removed in a
followup.

Related PSA:
https://discourse.llvm.org/t/psa-removal-of-typed-pointers-from-the-llvm-dialect/74502

This commit removes all LLVM dialect typed pointers from the lit tests.
Typed pointers have been deprecated for a while now and it's planned to
soon remove them from the LLVM dialect.

Related PSA:
https://discourse.llvm.org/t/psa-removal-of-typed-pointers-from-the-llvm-dialect/74502

Now that we have more types handled for zext/sext and trunc, it is
possible to get more types working for the vector float to integer
conversions. This patch adds fp16, widening and narrowing vector support
to handle more types. The smaller types wil be expanded to the size of
the larger element type. A couple of case require more awkward truncates
to get working as they go from illegal to illegal types.

This patch converts `ConstantExpr::ResultStorageKind` to a scoped enum in namespace scoped `ConstantResultStorageKind`. This patch makes it possible to forward-declare this enum where it's necessery, e.g. for `preferred_type` annotation for bit-fields.

Workaround the case when the `this` pointer is actually a `NonLoc`, by
returning `Unknown` instead.
The solution isn't ideal, as `this` should be really a `Loc`, but due to
how casts work, I feel this is our easiest and best option.

As this patch presents, I'm evaluating a cast to transform the `NonLoc`.
However, given that `evalCast()` can't be cast from `NonLoc` to a
pointer type thingy (`Loc`), we end up with `Unknown`.
It is because `EvalCastVisitor::VisitNonLocSymbolVal()` only evaluates
casts that happen from NonLoc to NonLocs.

When I tried to actually implement that case, I figured:
1) Create a `SymbolicRegion` from that `nonloc::SymbolVal`; but
`SymbolRegion` ctor expects a pointer type for the symbol.
2) Okay, just have a `SymbolCast`, getting us the pointer type; but
`SymbolRegion` expects `SymbolData` symbols, not generic `SymExpr`s, as
stated:

> // Because pointer arithmetic is represented by ElementRegion layers,
> // the base symbol here should not contain any arithmetic.

3) We can't use `ElementRegion`s to perform this cast because to have an
`ElementRegion`, you already have to have a `SubRegion` that you want to
cast, but the point is that we don't have that.

At this point, I gave up, and just left a FIXME instead, while still
returning `Unknown` on that path.
IMO this is still better than having a crash.

Fixes #69922

This patch converts `SourceLocExpr::IdentKind` into a scoped enum at namespace scope, making it eligible to be forward-declared. This is needed by `preferred_type` annotations on bit-fields.

There are currently a couple jobs that run on all forks of LLVM too (if
there is a PR opened, or in the case of the documentation builds, upon
pushing to main). This isn't desired behavior. This commit disables that
behavior, forcing the jobs to not run if they aren't running against
llvm/llvm-project or a PR against that repo.

This patch enables building the flang docs in Github actions to enable
rapid iteration in PRs and to catch docs build failures more easily
before merge/after merge. This patch currently doesn't fail for Sphinx
warnings, but the intention is to enable this functionality once the
flang docs are fixed to build without warnings after the transition to
Myst.

Namely `Expr.h`, `ExprConcept.h`, `ExprCXX.h`, `ExprObjC.h`.

This patch adds `preferred_type` annotations to `Decl` and `DeclContext` bit-fields. Those annotations help debuggers reason about the type of the value stored in bit-field.

This is just helping with some build failure in some new configurations.

Add a pass that propagates sharding information throughout the graph.
After this pass, each of the operations' operands and results is
annotated with a mesh.shard operation.

The pass is driven by a newly added ShardingInterface, and an implementation
for element-wise and matmul ops in the TOSA dialect is provided.

Loosen up the matching so that a missing leaf debug frame in the profile
does not prevent matching an allocation context if we can match further
up the inlined call context. This relies on the pre-inliner, which was
already the default when performing normal PGO feedback along with the
MemProf feedback, but to ensure matching is not affected by the presence
of PGO, enable the pre-inliner for MemProf feedback as well.

This builds on top of the work started in c3a302d3 to convert
LocateSymbolFile to a SymbolLocator plugin. This commit moves
LocateExecutableSymbolFile.

In g++, empty unions are not ignored like empty structs when flattening
structs to examine whether the structs can be passed via FARs in C++.
This patch aligns clang++ with g++.

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

I'm assuming that because sys::path::append defaults to native path
this fails. Since dsymutil is a Darwin tool, we can just hardcode the
UNIX path separator.

This builds on top of the work started in c3a302d3 to convert
LocateSymbolFile to a SymbolLocator plugin. This commit moves
FindSymbolFileInBundle.

This reverts commit 9d9400d7.
This reverts commit bda763ae.

The buildbot is broken and tests are failing.

/llvm-project/mlir/lib/Dialect/Mesh/IR/MeshOps.cpp:73:1: error: non-void function does not return a value in all control paths [-Werror,-Wreturn-type]
}
^
1 error generated.

Since smaia and ssaia are ratified now, we could remove their
experimental- prefix.

/llvm-project/mlir/lib/Target/LLVM/ROCDL/Target.cpp:181:40: error: unused variable 'targetMachine' [-Werror,-Wunused-variable]
  std::optional<llvm::TargetMachine *> targetMachine =
                                       ^
1 error generated.

Add a pass that propagates sharding information throughout the graph.
After this pass, each of the operations' operands and results is
annotated with a `mesh.shard` operation, and the operations themselves
are added with sharding option attributes.

The pass is driven by  a newly added `ShardingInterface`, and an implementation
for element-wise and matmul ops in the TOSA dialect is provided.