After feedback from D122861, do the same thing with some of the other headers. Try to move the
headers so they have a similar style and way of doing things.
Reviewed By: ldionne, daltenty
Differential Revision: https://reviews.llvm.org/D124227
The globals are better expressed as members of the Symbolizer, and all
functions operating on it should be methods instead.
Also using the standard idiom of wrapping the main code in
`if __name__ == '__main__'`.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D125032
Since D97044, libc++ implements <stdatomic.h>, which is not compatible
with the <atomic> header in C++03 mode. To fix the tests, avoid using
<stdatomic.h> at all, since it is not strictly required.
rdar://92867529
Differential Revision: https://reviews.llvm.org/D125118
This only adds the customization point object (which isn't pipeable),
the view itself has already been implemented previously.
Differential Revision: https://reviews.llvm.org/D124978
This patch adds a test case for i256 additions and subtractions. I'm
leaving out multiplications for now, which would result in very long
sequences.
Differential Revision: https://reviews.llvm.org/D125125
This change was intended to add the tests check-clang and check-clang-pseudo,
but afterwards it was *only* running those tests.
(This was because unlike add_lit_testsuite, add_lit_testsuite*s* does not
get included in umbrella suites).
This changes the ELFNix platform Orc runtime to use, when available,
the __unw_add_dynamic_eh_frame_section interface provided by libunwind
for registering .eh_frame sections loaded by JITLink. When libunwind
is not being used for unwinding, the ELFNix platform detects this and
defaults to the __register_frame interface provided by libgcc_s.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D114961
Currently we require the `-fopenmp-targets=` option to specify the
triple to use for the offloading toolchains, and the `-Xopenmp-target=`
option to specify architectures to a specific toolchain. The changes
made in D124721 allowed us to use `--offload-arch=` to specify multiple
target architectures. However, this can become combersome with many
different architectures. This patch introduces functinality that
attempts to deduce the target triple and architectures from the
offloading action. Currently we will deduce known GPU architectures when
only `-fopenmp` is specified.
This required a bit of a hack to cache the deduced architectures,
without this we would've just thrown an error when we tried to look up
the architecture again when generating the job. Normally we require the
user to manually specify the toolchain arguments, but here they would
confict unless we overrode them.
Depends on: D124721
Reviewed By: saiislam
Differential Revision: https://reviews.llvm.org/D125050
This patch adds support for OpenMP to use the `--offload-arch` and
`--no-offload-arch` options. Traditionally, OpenMP has only supported
compiling for a single architecture via the `-Xopenmp-target` option.
Now we can pass in a bound architecture and use that if given, otherwise
we default to the value of the `-march` option as before.
Note that this only applies the basic support, the OpenMP target runtime
does not yet know how to choose between multiple architectures.
Additionally other parts of the offloading toolchain (e.g. LTO) require
the `-march` option, these should be worked out later.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D124721
This was leftover from when the standard dialect was destroyed, and
when FuncOp moved to the func dialect. Now that these transitions
have settled a bit we can drop these.
Most updates were handled using a simple regex: replace `^( *)func` with `$1func.func`
Differential Revision: https://reviews.llvm.org/D124146
For the unary shuffle pattern, this is opposite to what we try
to do with binops, but it seems better to keep it consistent
with the motivating binary shuffle pattern. On that, it is
clearly better on the usual no-extra uses case.
There is a chance that this will pull an fneg away from some
other binop and cause a regression in codegen, but that should
be invertible in the backend. The transform is birectional:
https://alive2.llvm.org/ce/z/kKaKCUhttps://alive2.llvm.org/ce/z/3DesfwFixes#45631
When targeting cortex-a53, set this linker flag rather than relying
on the toolchain users to do it in their build.
Differential Revision: https://reviews.llvm.org/D114023
If the income state hasn't changed, and the step function is fixed by assumption, then the output state can't have changed.
In the current algorithm, this is a very minor win and mostly allows adding tracing output without being horrible verbose.
That makes it possible to reuse libc++abi targets from the libc++
configuration, which is necessary to allow major CMake simplifications.
As a fly-by fix, we also unify how compiler-rt ordering is handled so
it matches how libc++ and libc++abi are handled (compiler-rt always
ends up first).
Differential Revision: https://reviews.llvm.org/D120719
The LLVM ThreadPool recently got the addition of the concept of
ThreadPoolTaskGroup: this is a way to "partition" the threadpool
into a group of tasks and enable nested parallelism through this
grouping at every level of nesting.
We make use of this feature in MLIR threading abstraction to fix a long
lasting TODO and enable nested parallelism.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D124902
This patch is a followup to the previous patch which implemented the
main printf parsing logic as well as sequential mode. This patch adds
index mode.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D123424
This check verifies the safety of access to `std::optional` and related
types (including `absl::optional`). It is based on a corresponding Clang
Dataflow Analysis, which does most of the work. This check merely runs it and
converts its findings into diagnostics.
Differential Revision: https://reviews.llvm.org/D121120
fcgl option will make compilation stop after clang codeGen and output the llvm ir.
It is added to check clang codeGen output for HLSL.
It will be translated into -S -emit-llvm and -disable-llvm-passes.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D124983
The entrypoint list for windows hasn't been updated in a while, this
adds all of the entrypoints that are working for windows now.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D125058