Similar to fdbe7c7f, refactor OptionValueProperties to return a
std::optional instead of taking a fail value. This allows the caller to
handle situations where there's no value, instead of being unable to
distinguish between the absence of a value and the value happening the
match the fail value. When a fail value is required,
std::optional::value_or() provides the same functionality.

Revert "Don't loop unswitch vector selects"

Breaks msan. Details in D138526.

This reverts commit bf089732.
This reverts commit e479ed90.

Remove TestExternalEditor.test as the code to open the transcript in an
external editor is conditional on lldb running in a graphical session.
As a result this test passes locally but not on the bots.

Fix warning, remove trailing whitespace and fix formatting.

I didn't account for the scenario where the string was set but was
empty. This commit restores the old behavior and fixes
TestMemoryFind.py.

Refactor OptionValue to return a std::optional instead of taking a fail
value. This allows the caller to handle situations where there's no
value, instead of being unable to distinguish between the absence of a
value and the value happening the match the fail value. When a fail
value is required, std::optional::value_or() provides the same
functionality.

`$<TARGET_OBJECTS:llvm-min-tblgen>` was too lazy.
It has `rc.res` in the list with MS toolchain.

Fixup for D146352

`llvm-min-tblgen` is capable of building `llvm/include/llvm`;

- `-gen-attrs`
- `-gen-directive-*`
- `-gen-intrinsics-*`
- `-gen-riscv-target-def`

`llvm-min-tblgen` is built and used only when `llvm-tblgen` is built in-tree.
This is not installed.

`llvm-tblgen` is built with complete set and may be installed.
`check-llvm` uses not `llvm-min-tblgen` but `llvm-tblgen`.

`LLVM_TABLEGEN_PROJECT` overrides the definition of `tablegen(project)`.
`LLVM_HEADERS` is used as the overridden prefix for LLVM header generators.

If `EXPORT` is not specified in `add_tablegen`, its tablegen is treated as internal.

Let `llvm-tblgen` depend on `intrinsics_gen`

Depends on D149072

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

Since `llvm-min-tblgen` has been introduced, `llvm-min-tblgen-host`
would make more sense than `LLVM_HEADERS-tablegen-host`.

Depends on D146352

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

We had previously been going through the stack.

A couple small notes:
    We have the vslide1down idiom in a few other places. As a post patch, I plan to try to common the code a bit.
    VF=2 case is still going through the splat + insert path. Picking the optimal sequence for this seems to be a bit fiddly (due to constant mat costs), so I restricted this to cases which would have previously hit the stack.
    I'm only handling integer vectors for the moment. Mostly because I don't see the existing vfslide1down ISD nodes being in place. This will be an obvious followup.
    One of the test diffs does expose a missing combine - a build_vector with a prefix coming from a vector extract sequence. The code after this is arguably worse (due to domain crossing vs stack store), but I think this is a narrow enough case to be non-blocking for now. Let me know if you disagree.

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

Noticed this while looking at some SLP output. If we have an extractelement, we're probably using a slidedown into an destination with no contents. Given this, we can allow the slideup to use a larger VL and clobber tail elements of the destination vector. Doing this allows us to avoid vsetvli toggles in many fixed length vector examples.

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

Reviewed By: MaskRay

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

MinGW and CrossWindows crash if the target is an unsupported target architecture.
Changed it to emit an error message.

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

Reviewed By: MaskRay, mstorsjo

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

For an unknown target triple, the ", please use -triple or -arch" hint of the
diagnostic is almost always wrong.
For cc1, the error is due to a specified but unknown -triple.
For driver, -triple and -arch are not driver options.

Add the following Decimal Floating Point (DFP) instructions for PowerPC.
dadd, daddq, dsub, dsubq

In order to add these instructions a new register class for a pair
of floating point registers is added.

This patch is only to allow the user to specify the instructions in
assembly. There is no scheduling or patterns for the instructions.

Reviewed By: amyk

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

This is done by removing configurations we don't support.

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

This avoid CUDA compilation errors caused by CUDA headers defining __noinline__
and conflicting with __noinline__ use in libstdc++.

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

Fix buildbot failure after landing D149385

This reverts commit 45351120.

llvm has a structure for maps where the key's type is a string. Using
that also means that the keys for OptionValueDictionary don't stick
around forever in ConstString's StringPool (even after they are gone).

The only thing we lose here is ordering: iterating over the map where the keys
are ConstStrings guarantees that we iterate in alphabetical order.
StringMap makes no guarantees about the ordering when you iterate over
the entire map.

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

Add lowering support for derived type component appearing
in a data clause to the newly added data operand operations.

Depends on D149297

Reviewed By: razvanlupusoru, jeanPerier

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

Reviewed By: wrengr

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

In `libomptarget` we use a couple of functions from `libomp`, but we didn't link
`libomptarget` against `libomp`. That will not work on some platforms such
as macOS. A linker error will be encountered because those symbols are not resolved
at link time when building `libomptarget`. This patch simply makes `libomptarget`
link agains `libomp`, makes it a "user" of `libomp`. I think this will not break
the policies between `libomp` and `libomptarget`.

Reviewed By: jdoerfert

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

This reverts commit d572cd1b.

Some bots are broken and investigation is needed before relanding.

D132005 introduced function calls from `libomp` to `libomptarget` if offloading
is enabled. However, the external function declaration may not always work. For
example, it causes a link error on macOS. Currently it is guarded properly by
a macro, but in order to get OpenMP target offloading working on macOS, it has
to be handled correctly. This patch applies the same idea of how we support
target memory extension by using function pointer indirect call for that function.

Reviewed By: jdoerfert

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

This new features enabled to dedicate custom storage inline within operations.
This storage can be used as an alternative to attributes to store data that is
specific to an operation. Attribute can also be stored inside the properties
storage if desired, but any kind of data can be present as well. This offers
a way to store and mutate data without uniquing in the Context like Attribute.
See the OpPropertiesTest.cpp for an example where a struct with a
std::vector<> is attached to an operation and mutated in-place:

struct TestProperties {
  int a = -1;
  float b = -1.;
  std::vector<int64_t> array = {-33};
};

More complex scheme (including reference-counting) are also possible.

The only constraint to enable storing a C++ object as "properties" on an
operation is to implement three functions:

- convert from the candidate object to an Attribute
- convert from the Attribute to the candidate object
- hash the object

Optional the parsing and printing can also be customized with 2 extra
functions.

A new options is introduced to ODS to allow dialects to specify:

  let usePropertiesForAttributes = 1;

When set to true, the inherent attributes for all the ops in this dialect
will be using properties instead of being stored alongside discardable
attributes.
The TestDialect showcases this feature.

Another change is that we introduce new APIs on the Operation class
to access separately the inherent attributes from the discardable ones.
We envision deprecating and removing the `getAttr()`, `getAttrsDictionary()`,
and other similar method which don't make the distinction explicit, leading
to an entirely separate namespace for discardable attributes.

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

This field is never used today. If you have a pointer to the row
you can find the CPUKind by subtracting the pointer from the start
of the array.

This value is never used outside and is only used as a sentinel
internally which we can solve with other means.

We can iterate over the RISCVCPUInfo table instead of using a
separate StringSwitch.

Recommit "[ValueTracking] Use knownbits interface for determining if `div`/`rem` are safe to speculate" (2nd Try)

Add `poison` checks that where missing.

Reviewed By: nikic

D146349 Introduced the ability to use the information from the
`select` condition to deduce constants as we folded a binop into
select. I.e if the `select` cond was `icmp eq %A, 10`, then in the
true-arm of `select`, we would be able to replace usage of `A` with
`10`.

This is broken for vectors that contain `undef` elements. I.e with
`icmp eq %A, <10, undef>`, subsituting `<10, undef>` for `A` can
result in creating a more undefined result than we otherwise would
have.

We fix the issue with simply checking if the candidate constant for
substituting may contain `undef` elements and don't do it in that
case.

Reviewed By: nikic

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits, miyuki, carlosgalvezp

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

This reverts commit 479e335f.

The assertion at `kmp_tasking.cpp(29)` is triggered.

D132005 introduced function calls from `libomp` to `libomptarget` if offloading
is enabled. However, the external function declaration may not always work. For
example, it causes a link error on macOS. Currently it is guarded properly by
a macro, but in order to get OpenMP target offloading working on macOS, it has
to be handled correctly. This patch applies the same idea of how we support
target memory extension by using function pointer indirect call for that function.

Reviewed By: jdoerfert

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