Flang was not able to convert simd directive which contains nested
Fortran loops. The nested Fortran loops inside SIMD directive
are modelled as FIR loops and they need to be translated into LLVM
MLIR dialect.

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



Reviewed by: peixin

Signed-off-by: Dominik Adamski <dominik.adamski@amd.com>

1438639a removed a test
that was using undefined behaviour setting a non-typed enum
to a value outside its known range.

That test also checked if we formatted the value properly
when it could contain >1 valid enum value.

I don't think there's anything special about how we format
typed vs non-typed enums so I'm adding a test for ScopedEnum
that will expect to see 2 enum values plus extra.

Reviewed By: labath, Michael137, shafik

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

The relevant property of allocation functions of interest here is
their uniqueness (in the sense of disjoint provenance), which is
encoded by the noalias return attribute.

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

Use find_program() to find the clang-tblgen executable. The current
code ends up using docs/clang-tblgen for me...

This is the same way that mlir-tblgen is obtained in:
https://github.com/llvm/llvm-project/blob/27241435515554bc21105713c9d34cf886c5bced/flang/CMakeLists.txt#L95-L96.

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

Reviewed By: tstellar

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

Use xz -T0 to use your threads

Reviewed By: tstellar

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

llvm-project has switched to require C++17.

Reviewed By: dvyukov

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

Given that we provide an EditGenerator edit(ASTEdit), we can't ever be
sure that the user won't give us an empty replacement.

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

Reviewed By: michaelrj

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

Disable the build on macOS due to the bot fail.

Reviewed By: bkramer

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

This reverts commit ab4e5ed4 since it
causes a build failure on macOS:

https://green.lab.llvm.org/green/job/lldb-cmake/45984/

This patch changes the CrashLogParser class to be both the base class
and a Factory for the JSONCrashLogParser & TextCrashLogParser.

That should help remove some code duplication and ensure both class
have a parse method.

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



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

Sometimes, it can happen that a crash report has null images in its list
of used binaries. This manifests like such:

```
    0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???
```

When fetching debug symbols to symbolicate the crashlog stackframe,
having null images causes `dsymForUUID` to hang for few seconds.

This patch addresses that by skipping null images from being load by the
scripted process.

rdar://97419487

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



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

This patch introduces a new option for the interactive crashlog mode,
that will prevent it from dumping the `process status` & `thread backtrace`
output to the debugger console.

This is necessary when lldb in running from an IDE, to prevent flooding
the console with information that should be already present in the UI.

rdar://96813296

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



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

In can happen when creating stackshot crash report that that key is missing.

Moreover, we try to parse that key but don't use it, or need it, since we
fetch images and symbolicate the stackframes using the binaries UUIDs.

This is why this patch removes everything that is related to the
`process_path`/`procPath` parsing.

rdar://95054188

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



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

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