This is to reduce the diff in follow-up changes.

This attempts to stop the type promotion pass transforming where it is
not profitable, by not marking PhiNodes as ToPromote and being more
aggressive about pulling extends out of loops.

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

Set the EmulatedTLS option based on `Triple::hasDefaultEmulatedTLS()`
if the user didn't specify it; set `ExplicitEmulatedTLS` to true
in `llvm::TargetOptions` and set `EmulatedTLS` to Clang's
opinion of what the default or preference is.

This avoids any risk of deviance between the two.

This affects one check of `getCodeGenOpts().EmulatedTLS` in
`shouldAssumeDSOLocal` in CodeGenModule, but as that check only
is done for `TT.isWindowsGNUEnvironment()`, and
`hasDefaultEmulatedTLS()` returns false for such environments
it doesn't make any current testable difference - thus NFC.

Some mingw distributions carry a downstream patch, that enables
emulated TLS by default for mingw targets in `hasDefaultEmulatedTLS()`
- and for such cases, this patch does make a difference and fixes the
detection of emulated TLS, if it is implicitly enabled.

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

This patch refators the polynomial Approx test. Now we pass the constant as function argument to avoid constant folder.

Link: https://github.com/llvm/llvm-project/issues/57613

Reviewed By: Mogball

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

By this change the `exploded-graph-rewriter` will display the class kind
of the expression of the environment entry. It makes easier to decide if
the given entry corresponds to the lvalue or to the rvalue of some
expression.

It turns out the rewriter already had support for visualizing it, but
probably was never actually used?

Reviewed By: martong

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

Some select node Pattern with register cmp instruction should be guarded
by iHas2E3.

`LazyCompoundVals` should only appear as `default` bindings in the
store. This fixes the second case in this patch-stack.

Depends on: D132142

Reviewed By: xazax.hun

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

It turns out that in certain cases `SymbolRegions` are wrapped by
`ElementRegions`; in others, it's not. This discrepancy can cause the
analyzer not to recognize if the two regions are actually referring to
the same entity, which then can lead to unreachable paths discovered.

Consider this example:

```lang=C++
struct Node { int* ptr; };
void with_structs(Node* n1) {
  Node c = *n1; // copy
  Node* n2 = &c;
  clang_analyzer_dump(*n1); // lazy...
  clang_analyzer_dump(*n2); // lazy...
  clang_analyzer_dump(n1->ptr); // rval(n1->ptr): reg_$2<int * SymRegion{reg_$0<struct Node * n1>}.ptr>
  clang_analyzer_dump(n2->ptr); // rval(n2->ptr): reg_$1<int * Element{SymRegion{reg_$0<struct Node * n1>},0 S64b,struct Node}.ptr>
  clang_analyzer_eval(n1->ptr != n2->ptr); // UNKNOWN, bad!
  (void)(*n1);
  (void)(*n2);
}
```

The copy of `n1` will insert a new binding to the store; but for doing
that it actually must create a `TypedValueRegion` which it could pass to
the `LazyCompoundVal`. Since the memregion in question is a
`SymbolicRegion` - which is untyped, it needs to first wrap it into an
`ElementRegion` basically implementing this untyped -> typed conversion
for the sake of passing it to the `LazyCompoundVal`.
So, this is why we have `Element{SymRegion{.}, 0,struct Node}` for `n1`.

The problem appears if the analyzer evaluates a read from the expression
`n1->ptr`. The same logic won't apply for `SymbolRegionValues`, since
they accept raw `SubRegions`, hence the `SymbolicRegion` won't be
wrapped into an `ElementRegion` in that case.

Later when we arrive at the equality comparison, we cannot prove that
they are equal.

For more details check the corresponding thread on discourse:
https://discourse.llvm.org/t/are-symbolicregions-really-untyped/64406

---

In this patch, I'm eagerly wrapping each `SymbolicRegion` by an
`ElementRegion`; basically canonicalizing to this form.
It seems reasonable to do so since any object can be thought of as a single
array of that object; so this should not make much of a difference.

The tests also underpin this assumption, as only a few were broken by
this change; and actually fixed a FIXME along the way.

About the second example, which does the same copy operation - but on
the heap - it will be fixed by the next patch.

Reviewed By: martong

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

This patch adds cost model for vector compare and select instructions. For vector FP compare instruction, it only add the comparisions supported natively.

Reviewed By: reames

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

Instruction being hoisted could have nuw/nsw flags inferred from the old
context, and we cannot simply move it to the new location keeping them
because we are going to introduce new uses to them that didn't exist before.

Example in https://github.com/llvm/llvm-project/issues/57187 shows how
this can produce branch by poison from initially well-defined program.

This patch forcefully recomputes poison-generating flag in the new context.

Differential Revision: https://reviews.llvm.org/D132022
Reviewed By: fhahn, nikic

Extend the llvm-dwp to support searching the DWOs that from relative path for the
case that build from remote building system(different comp_dir).

Reviewd By: dblaikie

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

According to [dcl.inline]p7/note4,

> In the global module, a function defined within a class definition is
> implicitly inline.

And the declarations in the header unit are attached to the global
module fragment. So the function defined within a class definition in
header units should be implicitly inline too.

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

For now, we report nothing if the execution/dwo file is missing, which is confusing.

Reviewed By: dblaikie

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

Reviewed By: lkail

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

I believe the result for fp_to_uint_sat is incorrect for this case.

While auxv keys are usually small, e.g. less than 50, they can sometimes be larger, especially on a downstream kernel where a custom auxv entry is intentionally high to avoid conflicting with the standard lower numbers. This test fails on a system with an auxv value bigger than 1000, but instead of putting this test at that value plus one, it looks like 2023 (i.e. `AT_SUN_CAP_HW2`) is another large one out there. Use 2500 as a limit to still have this be a reasonable "small" check but still allow all known auxv keys.

Semi-related change: this test case prints the auxv dict at the trace level, but only _after_ the assertion fails, making it not print what the offending value is as the test case aborts. Move it earlier so we can see what the "unreasonable" auxv value is.

The original code may have incorrect result if there is a masked instruction
without policy operand to make us set its policy to TUMU. The patch adds an
assertion to catch the instruction.

Reviewed By: reames

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

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

https://reviews.llvm.org/D133729 broke the buildbots because some
don't build with both x86 and aarch64 targets. Adding REQUIRES
to make sure this test only runs when specifying for both arch.

llvm-lipo crashes when trying to use inputs that contain bitcode asm instructions.
This happens when trying to create universal binaries for LLVM with LTO.
https://reviews.llvm.org/D118575 is a similar change that ran into this same issue, and I'm
mirroring the same change by registering the targets to fix this issue.

Reviewed By: alexander-shaposhnikov, keith

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

Fold cases where a tosa.reverse is a splat or reversing a dim
of length-1.

Reviewed By: jpienaar

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

The ORC runtime include directory was renamed from 'orc' to 'orc_rt' in
a85e4aa3. Update includes to match.

Some compilers (like all the ones I've tried) seem to NVRO the
Expected<std::vector<unique_ptr>> but other ones (like some of the bots) seem
to not want to.

Change the return type to Error and pass in the vector as an output parameter
to try and fix things.

Debugging some DWARF5 binaries was causing errors to appear when DWARFExpression::Evaluate was called:

    error: GetDIE for DIE 0x31 is outside of its CU 0x123450

The issue is in the DWARF expression evaluator. Fixed with this.

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

The ORC runtime isn't used by clang -- the prefix was just cargo-culted with
the rest of the XRay config when the ORC runtime was introduced. We now want to
make parts of it available for clients to link directly, so this seems like a
good time to fix the name.

Unfortunately these options are still not upstream.

This patch refactors SlotIndex::getInstrDistance to
SlotIndex::getApproxInstrDistance to better describe the actual
functionality of this function. This patch also adds in some additional
comments better documenting the assumptions that this function makes to
increase clarity.

Based on discussion on the LLVM Discourse:
https://discourse.llvm.org/t/odd-behavior-in-slotindex-getinstrdistance/64934/5

Reviewed By: mtrofin, foad

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

The bit masking lowering only works for vectors of scalars, so for pointer
element types we need to add some casting.

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