This patch updates the regular expression matching stackframes in
crashlog to allow addresses that are 7 characters long and more (vs. 8
characters previously).

It changes the `0x[0-9a-fA-F]{7}[0-9a-fA-F]+` by `0x[0-9a-fA-F]{7,}`.

rdar://97684839

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

This patch allows the crashlog script to surface its errors to lldb by
using the provided SBCommandReturnObject argument.

rdar://95048193

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

This patch introduces a new flag for the interactive crashlog mode, that
allow the user to specify, which target to use to create the scripted
process.

This can be very useful when lldb already have few targets created:
Instead of taking the first one (zeroth index), we will use that flag to
create a new target. If the user didn't provide a target path, we will rely
on the symbolicator to create a targer.If that fails and there are already
some targets loaded in lldb, we use the first one.

rdar://94682869

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

Windows builds require all control paths return. Since we don't have
`llvm_unreachable` in the Python bindings, just return `None`.

Previously, calling `Value.owner()` would C++ assert in debug builds if
`Value` was a block argument. Additionally, the behavior was just wrong
in release builds. This patch adds support for BlockArg Values.

Fix the mising change for truncdfbf2.c

Reviewed By: bkramer

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

This reverts commit 0ae2a41d.

Revert due to buildbot fail.

#56854 shows a backwards compatibility problem when builtins of compiler-rt don't follow ABI. We need to prevent to fall into the trap again for BF16.

Reviewed By: bkramer

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

X86 psABI has updated to support __bf16 type, the ABI of which is the
same as FP16. See https://discourse.llvm.org/t/patch-add-optional-bfloat16-support/63149

Reviewed By: pengfei

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

X86 psABI has updated to support __bf16 type, the ABI of which is the
same as FP16. See https://discourse.llvm.org/t/patch-add-optional-bfloat16-support/63149

This is an alternative of D129858, which has less code modification and
supports the vector type as well.

Reviewed By: LuoYuanke

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

The former stores strings and is therefore more expensive.

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

https://reviews.llvm.org/D115031 improved printing of non-type template
parameter args. But checking if the end of Inits is 0 without checking
if APValue is an integer, causes clang to segfault. This patch adds
the code to check the type. (May not be a proper bugfix.)

Reviewed By: aaron.ballman, lichray

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

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

Reviewed By: Peiming

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

Implements part of P1614R2 "The Mothership has Landed"

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

This patch should fix the interactive crashlog test by checking in the
binary as a yaml to regeneate the binary with the addresses and offsets
when running the test.

rdar://93655633

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

The corresponding _LIBCPP_HAS_NO_SPACESHIP_OPERATOR macro was already
removed in commit c0f87e83

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

This patch teaches llvm-profdata to output the sample profile in the
JSON format.  The new option is intended to be used for research and
development purposes.  For example, one can write a Python script to
take a JSON file and analyze how similar different inline instances of
a given function are to each other.

I've chosen JSON because Python can parse it reasonably fast, and it
just takes a couple of lines to read the whole data:

  import json
  with open ('profile.json') as f:
    profile = json.load(f)

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

As shown in P2544R0 [1] and the accompanying benchmark [2], the
current unwinding logic does not scale for multi-threaded programs.
This is because `dl_iterate_phdr` takes a global lock.

glibc 2.35 added `_dl_find_object` which directly returns the unwind
info for a given target address. `_dl_find_object` is fully lock-free
and hence allows parallel exception unwinding on multiple threads.

With this commit, libunwind now takes advantage of `_dl_find_object`.
Thereby, this commit improves libunwind's performance on benchmark [2]
for unwinding exception on 20 threads from 1103ms to 78ms.
(measured on Intel Xeon Silver 4114 with 20 physical cores)

[1] https://isocpp.org/files/papers/P2544R0.html
[2] https://github.com/neumannt/exceptionperformance

Detailed performance numbers from the benchmark:

Before:
> Testing unwinding performance: sqrt computation with occasional errors
>
> testing baseline using 1 2 4 8 16 20 threads
> failure rate 0%: 34 35 34 35 35 36
> testing exceptions using 1 2 4 8 16 20 threads
> failure rate 0%: 16 32 33 34 35 36
> failure rate 0.1%: 16 32 34 36 35 36
> failure rate 1%: 20 40 40 43 90 113
> failure rate 10%: 59 92 140 304 880 1103
> [...]
>
> Testing invocation overhead: recursive fib with occasional errors
>
> testing exceptions using 1 2 4 8 16 20 threads
> failure rate 0%: 19 32 37 38 39 36
> failure rate 0.1%: 22 32 40 40 39 34
> failure rate 1%: 20 28 38 39 48 40
> failure rate 10%: 25 39 44 50 92 113

After:
> Testing unwinding performance: sqrt computation with occasional errors
>
> testing baseline using 1 2 4 8 16 20 threads
> failure rate 0%: 19 30 35 38 39 35
> testing baseline using 1 2 4 8 16 20 threads
> failure rate 0%: 32 35 33 34 34 36
> testing exceptions using 1 2 4 8 16 20 threads
> failure rate 0%: 16 35 33 37 35 35
> failure rate 0.1%: 16 32 36 33 34 37
> failure rate 1%: 21 37 39 40 40 41
> failure rate 10%: 72 75 76 80 80 78
> [...]
>
> Testing invocation overhead: recursive fib with occasional errors
>
> testing baseline using 1 2 4 8 16 20 threads
> failure rate 0%: 18 35 37 34 38 37
> testing exceptions using 1 2 4 8 16 20 threads
> failure rate 0%: 19 33 40 40 41 39
> failure rate 0.1%: 21 33 39 38 39 38
> failure rate 1%: 20 36 39 40 41 40
> failure rate 10%: 25 45 41 42 44 43

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

This change finalizes the series of patches aiming to replace old
strategy of VGPR to SGPR copies loweriong.  Following the
https://reviews.llvm.org/D128252 and https://reviews.llvm.org/D130367 code
parts that are no longer used were removed.  Pass main loop is no longer used
for the MIR changes but collect information for further analysis.  Actual MIR
lowering happens further according the analysys result in the set of separate
functions. Another important change concerns the order of lowering: VGPR to
SGPR copies lowering is done first to have priority on the rest of the MIR
changes.

Reviewed By: rampitec

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

This is currently exercising scalarization code path; with vectors enabled, we hit a different code path.  Explicitly exercise both so that both configurations have testing.

ROPI/RWPI are not supported with LOAD_STACK_GUARD currently.

Reviewed By: nickdesaulniers, rengolin

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

These two tests were each of them too long when running under ASAN,
so we have to skip both to get a clean ASAN bot run.

Reviewed By: abrachet

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

This data structure uses a backing cpp::array object and supports a
vector like push_back API. In comparison with a traditional vector
data structure, it is of a fixed capacity and cannot be resized.

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

After D121595 was commited, I noticed regressions assosicated with small trip
count numbersvectorisation by tail folding with scalable vectors. As a solution
for those issues I propose to introduce the minimal trip count threshold value.

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

bot.  This happens because they are building a long result into
a Python string, and the asan checker is making that very slow.

The last two tests here are both slow, but the 'test_command' is the
really slow one.  I'm going to start disabling just that one and see
if that gets the ASAN bots clean.

It should be `sizeof(*this)`.

This patch cleans up the definition of `DenseArrayAttrBase` by relying
more on ODS-generated methods. It also exposes an API for using the raw
data of a dense array, similar to `DenseIntOrFPElementsAttr::getRaw`.

Reviewed By: lattner, mehdi_amini

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

To move from TF C API to TFLite, we found that the argmax op in TFLite does not work for int64 inputs, so cast the int64 inputs to int32 inputs to make TFLite argmax op work

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

And clean up some of the user code

With D26647, we can already identify input object files compiled by cl.exe with
/GL. It seems to be helpful to do the same and print an error message for those
object files compiled with /GL but are inside libraries/archives too.

Reviewed By: rnk, thieta

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

Adds support for reduction of multiplcation
by extending OpenMP.cpp::genOpenMPReduction()
and altering the identity constant emitted in
OpenMP.cpp::createReductionDelc()

This patch builds D130077 and as such,
only supports reductions for interger types in
worksharping loops.

Reviewed By: awarzynski

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

Procedure bindings with explicit interfaces don't work when the
interface is shadowed by a generic interface of the same name,
and can produce spurious semantic error messages.  Extend the
characterization and checking code for such things, and the utility
functionns on which they depend, to dig through generics when they
occlude interface-defining subprograms.  This is done on demand in
checking code, not once during name resolution, because the
procedures in question may also be forward-referenced.

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

diff --git a/flang/include/flang/Semantics/symbol.h b/flang/include/flang/Semantics/symbol.h
index e79f8ab6503e..0b03bf06eb73 100644
--- a/flang/include/flang/Semantics/symbol.h