llvm supports specifying a non-standard layout where each project lies in its
own place. Do not assume a fixed layout and use the appropriate cmake variable
instead.

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

(cherry picked from commit f51ab187)

If emit inlined region for master/critical directives, no need to clear
lambda/block context data, otherwise the variables cannot be found and
it causes a crash at compile time.

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

(cherry picked from commit 7654bb63)

The current code can scan an unlimited number of instructions,
if the containing basic block is very large. The test case from
PR50155 contains a basic block with approximately 100k instructions.

To avoid this, limit the number of instructions we inspect. At
the same time, drop the limit on the number of basic blocks, as
this will be implicitly limited by the number of instructions as
well.

(cherry picked from commit 2cd78686)

For a global weak symbol defined as below:
  char g __attribute__((weak)) = 2;
LLVM generates an allocated global with WeakAnyLinkage,
for which BPF backend generates proper BTF info.

For the above example, if a modifier "const" is added like
  const char g __attribute__((weak)) = 2;
LLVM generates an allocated global with WeakODRLinkage,
for which BPF backend didn't generate any BTF as it
didn't handle WeakODRLinkage.

This patch addes support for WeakODRLinkage and proper
BTF info can be generated for weak symbol defined with
"const" modifier.

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

(cherry picked from commit 968292cb)

This permits extern function (BTF_KIND_FUNC) be added
to BTF_KIND_DATASEC if a section name is specified.
For example,

-bash-4.4$ cat t.c
void foo(int) __attribute__((section(".kernel.funcs")));
int test(void) {
  foo(5);
  return 0;
}

The extern function foo (BTF_KIND_FUNC) will be put into
BTF_KIND_DATASEC with name ".kernel.funcs".

This will help to differentiate two kinds of external functions,
functions in kernel and functions defined in other bpf programs.

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

(cherry picked from commit 886f9ff5)

Some BPF programs compiled on s390 fail to load, because s390
arch-specific linux headers contain float and double types. At the
moment there is no BTF_KIND for floats and doubles, so the release
version of LLVM ends up emitting type id 0 for them, which the
in-kernel verifier does not accept.

Introduce support for such types to libbpf by representing them using
the new BTF_KIND_FLOAT.

Reviewed By: yonghong-song

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

(cherry picked from commit a7137b23)

As shown in:
https://llvm.org/PR50623
...and the similar tests here, we were not accounting for
store merging of different sizes that do not cover the
entire range of the wide value to be stored.

This is the easy fix: just make sure that all of the
original stores are the same size, so when we calculate
the wide width, it's a simple N * M check.

This still allows all of the motivating optimizations from:
D86420 / 54a5dd48
D87112 / 7a06b166

We could enhance this code to track individual bytes and
allow merging multiple sizes.

(cherry picked from commit dd763ac7)

(cherry picked from commit 2ef81cb2)

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

(cherry picked from commit ecf93a71)

Apply the same logic used to check if CMPXCHG nodes should be expanded
at -O0: the register allocator may end up spilling some register in
between the atomic load/store pairs, breaking the atomicity and possibly
stalling the execution.

Fixes PR48017

Reviewed By: efriedman

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

(cherry picked from commit 4751cadc)

This fixes PR49821, and avoids "ld.lld: error: test.o:(.rodata.str1.1):
offset is outside the section" errors when linking MIPS objects with
negative R_MIPS_LO16 implicit addends.

ld.lld handles R_MIPS_HI16/R_MIPS_LO16 separately, not as a whole, so it
doesn't know that an R_MIPS_HI16 with implicit addend 1 and an
R_MIPS_LO16 with implicit addend -32768 represents 32768, which is in
range of a MergeInputSection. We could introduce a new RelExpr member
(like R_RISCV_PC_INDIRECT for R_RISCV_PCREL_HI20 / R_RISCV_PCREL_LO12)
but the complexity is unnecessary given that GNU as keeps the original
symbol for this case as well.

Adds a new test case for PR49821, and also updates two other test cases
that are affected by this change.

Reviewed By: atanasyan, MaskRay

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

(cherry picked from commit 7e83a7f1)

Don't fail the shared_ptr test if libc++ has insufficient debug info.

This addresses https://bugs.llvm.org/show_bug.cgi?id=48937

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

(cherry picked from commit 0e837803)

Certain fields of shared ptr have virtual functions and therefore
have their debug info homed in libc++. But if libc++ wasn't built
with debug info, the pretty printer would fail.

This patch makes the pretty printer tolerate such conditions and
updates the test harness.

This patch significantly reworks a previous attempt.

This addresses https://bugs.llvm.org/show_bug.cgi?id=48937

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

(cherry picked from commit 55b70611)

This is a workaround for PR48937. GDB can sometimes print additional
warnings which currently fails the test. Use re.search instead of
re.match to ignore this additional output.

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

(cherry picked from commit 9ac988f6)

Switch StdTuple printer from python 2-style "next" to python 3.

Nested iteration changed enough to make the original bitset iteration
code a bit trickier than it needs to be, so unnest.

The end node of a map iterator is sometimes hard to detect in isolation,
don't fail in that case.

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

(cherry picked from commit a34b8b87)

Reviewed By: nemanjai

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

(cherry picked from commit c0b30718)

We have been handling filters and landingpads incorrectly all along. We
pass clauses' (catches') types to `__cxa_find_matching_catch` in JS glue
code, which returns the thrown pointer and sets the selector using
`setTempRet0()`.

We apparently have been doing the same for filters' (exception specs')
types; we pass them to `__cxa_find_matching_catch` just the same way as
clauses. And `__cxa_find_matching_catch` treats all given types as
clauses. So it is a little surprising; maybe we intended to do something
from the JS side and didn't end up doing?

So anyway, I don't think supporting exception specs in Emscripten EH is
a priority, but this can actually cause incorrect results for normal
catches when functions are inlined and the inlined spec type has a
parent-child relationship with the catch's type.

---

The below is an example of a bug that can happen when inlining and class
hierarchy is mixed. If you are busy you can skip this part:
```
struct A {};
struct B : A {};

void bar() throw (B) { throw B(); }

void foo() {
  try {
    bar();
  } catch (A &) {
    fputs ("Expected result\n", stdout);
  }
}
```

In the unoptimized code, `bar`'s landingpad will have a filter for `B`
and `foo`'s landingpad will have a clause for `A`. But when `bar` is
inlined into `foo`, `foo`'s landingpad has both a filter for `B` and a
clause for `A`, and it passes the both types to
`__cxa_find_matching_catch`:
```
__cxa_find_matching_catch(typeinfo for B, typeinfo for A)
```
`__cxa_find_matching_catch` thinks both are clauses, and looks at the
first type `B`, which belongs to a filter. And the thrown type is `B`,
so it thinks the first type `B` is caught. But this makes it return an
incorrect selector, because it is supposed to catch the exception using
the second type `A`, which is a parent of `B`. As a result, the `foo` in
the example program above does not print "Expected result" but just
throws the exception to the caller. (This wouldn't have happened if `A`
and `B` are completely disjoint types, such as `float` and `int`)

Fixes https://bugs.llvm.org/show_bug.cgi?id=50357.

Reviewed By: dschuff, kripken

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

(cherry picked from commit 412a3381)

Fixes bug https://llvm.org/PR48939.

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

(cherry picked from commit 73cdc759)

As discussed in PR50385, strict-fp on PowerPC SPE has not been handled
well. This patch disables it by default for SPE.

Reviewed By: nemanjai, vit9696, jhibbits

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

(cherry picked from commit 5c18d113)

https://bugs.llvm.org/show_bug.cgi?id=50326

{D93626} caused a regression in terms of formatting a function ptr, incorrectly thinking it was a C-Style cast.

This cased a formatter regression between clang-format-11 and clang-format-12

```
void bar()
{
    size_t foo = function(Foooo, Barrrrr, Foooo, Barrrr, FoooooooooLooooong);

    size_t foo = function(
        Foooo, Barrrrr, Foooo, Barrrr, FoooooooooLooooong, BarrrrrrrrrrrrLong,
        FoooooooooLooooong);

    size_t foo = (*(function))(Foooo, Barrrrr, Foooo, FoooooooooLooooong);

    size_t foo = (*(
        function))(Foooo, Barrrrr, Foooo, Barrrr, FoooooooooLooooong,
        BarrrrrrrrrrrrLong, FoooooooooLooooong);
}
```

became

```
void bar()
{
    size_t foo1 = function(Foooo, Barrrrr, Foooo, Barrrr, FoooooooooLooooong);

    size_t foo2 = function(
        Foooo, Barrrrr, Foooo, Barrrr, FoooooooooLooooong, BarrrrrrrrrrrrLong,
        FoooooooooLooooong);

    size_t foo3 = (*(function))(Foooo, Barrrrr, Foooo, FoooooooooLooooong);

    size_t foo4 = (*(
        function))(Foooo, Barrrrr, Foooo, Barrrr, FoooooooooLooooong, BarrrrrrrrrrrrLong, FoooooooooLooooong);
}
```

This fixes this issue by simplify the clause to be specific about what is wanted rather than what is not.

Reviewed By: curdeius, HazardyKnusperkeks

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

(cherry picked from commit eae445f6)

This patch adds the handling of clobbers of the link register LR for inline
assembly.

This patch is to fix:
https://bugs.llvm.org/show_bug.cgi?id=50147

Reviewed By: nemanjai, #powerpc

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

(cherry picked from commit 15051f0b)

Fix bug in MemoryDependence [and thus GVN] for invariant group.

Previously MemDep didn't verify that the store was storing into a
pointer rather than a store simply using a pointer.

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

(cherry picked from commit 875891a1)

llvm::Any::TypeId::Id relies on the uniqueness of the address of a static
variable defined in a template function. hidden visibility implies vague linkage
for that variable, which does not guarantee the uniqueness of the address across
a binary and a shared library. This totally breaks the implementation of
llvm::Any.

Ideally, setting visibility to llvm::Any::TypeId::Id should be enough,
unfortunately this doesn't work as expected and we lack time (before 12.0.1
release) to understand why setting the visibility to llvm::Any does work.

See https://gcc.gnu.org/wiki/Visibility and
https://gcc.gnu.org/onlinedocs/gcc/Vague-Linkage.html
for more information on that topic.

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

(cherry picked from commit 3d3abc22)

We can not rely on (C+X)-->(X+C) already happening,
because we might not have visited that `add` yet.
The added testcase would get stuck in an endless combine loop.

(cherry-picked from 554b1bce)

GlobalVariables are Constants, yet should not unconditionally be
considered true for __builtin_constant_p.

Via the LangRef
https://llvm.org/docs/LangRef.html#llvm-is-constant-intrinsic:

    This intrinsic generates no code. If its argument is known to be a
    manifest compile-time constant value, then the intrinsic will be
    converted to a constant true value. Otherwise, it will be converted
    to a constant false value.

    In particular, note that if the argument is a constant expression
    which refers to a global (the address of which _is_ a constant, but
    not manifest during the compile), then the intrinsic evaluates to
    false.

Move isManifestConstant from ConstantFolding to be a method of
Constant so that we can reuse the same logic in
LowerConstantIntrinsics.

pr/41459

Reviewed By: rsmith, george.burgess.iv

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

(cherry picked from commit 8c72749b)

(cherry picked from commit 2f779e79)

This practically only works for the f16 case AMDGPU uses, not wider
types.

Fixes bug 49710 by failing legalization.

(cherry picked from commit 83a25a10)

Instead of using VMap, which may include instructions from the
caller as a result of simplification, iterate over the
(FirstNewBlock, Caller->end()) range, which will only include new
instructions.

Fixes https://bugs.llvm.org/show_bug.cgi?id=50270.

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

(cherry picked from commit aa9b02ac)

I think currently isImpliedViaMerge can incorrectly return true for phis
in a loop/cycle, if the found condition involves the previous value of

Consider the case in exit_cond_depends_on_inner_loop.

At some point, we call (modulo simplifications)
isImpliedViaMerge(<=, %x.lcssa, -1, %call, -1).

The existing code tries to prove IncV <= -1 for all incoming values
InvV using the found condition (%call <= -1). At the moment this succeeds,
but only because it does not compare the same runtime value. The found
condition checks the value of the last iteration, but the incoming value
is from the *previous* iteration.

Hence we incorrectly determine that the *previous* value was <= -1,
which may not be true.

I think we need to be more careful when looking at the incoming values
here. In particular, we need to rule out that a found condition refers to
any value that may refer to one of the previous iterations. I'm not sure
there's a reliable way to do so (that also works of irreducible control
flow).

So for now this patch adds an additional requirement that the incoming
value must properly dominate the phi block. This should ensure the
values do not change in a cycle. I am not entirely sure if will catch
all cases and I appreciate a through second look in that regard.

Alternatively we could also unconditionally bail out in this case,
instead of checking the incoming values

Reviewed By: nikic

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

(cherry picked from commit 6c99e631)

(cherry picked from commit d65e5f60)

An unfetched lazy symbol (undefined weak) should be considered to have its
original versionId which is VER_NDX_GLOBAL, instead of the lazy symbol's
versionId. (The original versionId cannot be non-VER_NDX_GLOBAL because a
undefined versioned symbol is an error.)

The regression was introduced in D77280 when making version scripts work
with lazy symbols fetched by LTO calls.

Fix PR49915

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

(cherry picked from commit 1c00530b)

This reverts commit b89942c3.

There are issues with this patch and also no tracking bug for it.

When run under valgrind, or with a malloc that poisons freed memory,
this can lead to segfaults or other problems.

To avoid modifying the AdditionalUsers DenseMap while still iterating,
save the instructions to be notified in a separate SmallPtrSet, and use
this to later call OperandChangedState on each instruction.

Fixes PR49582.

Reviewed By: fhahn

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

(cherry picked from commit 6abb92f2)

Fix branch coverage merging in FunctionCoverageSummary::get() for instantiation
groups.

This change corrects the implementation for the branch coverage summary to do
the same thing for branches that is done for lines and regions.  That is,
across function instantiations in an instantiation group, the maximum branch
coverage found in any of those instantiations is returned, with the total
number of branches being the same across instantiations.

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

(cherry picked from commit eccb9251)

Expand 128 bit shifts instead of using a libcall.

This patch removes the 128 bit shift libcalls and thereby causes
ExpandShiftWithUnknownAmountBit() to be called.

Review: Ulrich Weigand

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

(cherry picked from commit 1c4cb510)

Fixes PR49904

(cherry picked from commit 40e75caf)

Only verify that there's no negative indent.
Noted by @chapuni in https://reviews.llvm.org/D93494.

Reviewed By: chapuni

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

(cherry picked from commit d9f2960c)

This test case was added by accident and is failing on the release/12.x branch.

The compressed dumps are no longer readable, but I'm not sure why.