Reviewers: jhenderson, grimar, rupprecht

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

llvm-svn: 367942

This has come up twice already (once in pr42763 and once in the commit thread), so give warning of a new way in which UB can result in unexpected program behavior.

llvm-svn: 367941

This patch adds a warning that diagnoses comparisons of pointers to
'\0'. This is often indicative of a bug (e.g. the user might've
forgotten to dereference the pointer).

Patch by Elaina Guan!

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

llvm-svn: 367940

New OMPT tests with teams construct should be disabled for GCC as it
emits code with a GOMP entry not supported in the LLVM runtime.

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

llvm-svn: 367939

Once we start instrumenting globals, all addresses including those of string literals
that we pass to the operating system will start being tagged. Since we can't rely
on the operating system to be able to cope with these addresses, we need to untag
them before passing them to the operating system. This change introduces a macro
that does so and uses it everywhere it is needed.

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

llvm-svn: 367938

llvm-svn: 367937

llvm-svn: 367936

Summary:
When the WebAssembly backend encounters a return type that doesn't
fit within i32, SelectionDAG performs sret demotion, adding an
additional argument to the start of the function that contains
a pointer to an sret buffer to use instead. However, this conflicts
with the emscripten sjlj lowering pass. There we translate calls like:

```
	call {i32, i32} @foo()
```

into (in pseudo-llvm)
```
	%addr = @foo
	call {i32, i32} @__invoke_{i32,i32}(%addr)
```

i.e. we perform an indirect call through an extra function.
However, the sret transform now transforms this into
the equivalent of
```
        %addr = @foo
        %sret = alloca {i32, i32}
        call {i32, i32} @__invoke_{i32,i32}(%sret, %addr)
```
(while simultaneously translation the implementation of @foo as well).
Unfortunately, this doesn't work out. The __invoke_ ABI expected
the function address to be the first argument, causing crashes.

There is several possible ways to fix this:
1. Implementing the sret rewrite at the IR level as well and performing
   it as part of lowering to __invoke
2. Fixing the wasm backend to recognize that __invoke has a special ABI
3. A change to the binaryen/emscripten ABI to recognize this situation

This revision implements the middle option, teaching the backend to
treat __invoke_ functions specially in sret lowering. This is achieved
by
1) Introducing a new CallingConv ID for invoke functions
2) When this CallingConv ID is seen in the backend and the first argument
   is marked as sret (a function pointer would never be marked as sret),
   swapping the first two arguments.

Reviewed By: tlively, aheejin
Differential Revision: https://reviews.llvm.org/D65463

llvm-svn: 367935

When we remove instructions cached references could still be live. This
patch avoids removing invoke instructions that are replaced by calls and
instead keeps them around but in a dead block.

llvm-svn: 367933

Revert Register/MCRegister: Add conversion operators to avoid use of implicit convert to unsigned. NFC

MSVC finds ambiguity where clang doesn't and it looks like it's not going to be an easy fix
Reverting while I figure out how to fix it

This reverts r367916 (git commit aa15ec3c)
This reverts r367920 (git commit 5d14efe2)

llvm-svn: 367932

Similar to other places where we transform invokes to calls we need to
be careful if the handler (=personality) can catch asynchronous
exceptions as they are not modeled as part of nounwind.

This is tested with D59978.

llvm-svn: 367931

llvm-svn: 367930

See Intel SDM, Vol 2A, Table 3-8:
https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-2a-manual.pdf#page=296

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

llvm-svn: 367929

llvm-svn: 367928

Any addresses that we pass to llvm-symbolizer are going to be untagged,
while any HWASAN instrumented globals are going to be tagged in the
symbol table. Therefore we need to untag the addresses before using them.

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

llvm-svn: 367926

Disabling Transparent huge page mode refactored in one function.

Reviewers: vitalybuka

Reviewed By: vitalybuka

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

llvm-svn: 367925

The UpdateLanguageForExpr should only update the language, but over
time it started to do also do different things related to the generation
of the expression source code. This patch refactors all the source code
generation part into its own function.

llvm-svn: 367922

This should fix the bots that have been failing due to r367712.

llvm-svn: 367921

It seems that MSVC sees ambiguity between the operator==()'s where clang
doesn't

llvm-svn: 367920

FastISel already does this since the initial arm64 port was upstreamed, so
it seems there are no issues with doing this at -O0 for very small memcpys.

Gives a 0.2% geomean code size improvement on CTMark.

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

llvm-svn: 367919

The bots are sad that they're not documented.

llvm-svn: 367918

Summary:
FuzzedDataProvider is a helper class for writing fuzz targets that fuzz
multple inputs simultaneously. The header is supposed to be used for fuzzing
engine agnostic fuzz targets (i.e. the same target can be used with libFuzzer,
AFL, honggfuzz, and other engines). The common thing though is that fuzz targets
are typically compiled with clang, as it provides all sanitizers as well as
different coverage instrumentation modes. Therefore, making this FDP class a
part of the compiler-rt installation package would make it easier to develop
and distribute fuzz targets across different projects, build systems, etc.
Some context also available in https://github.com/google/oss-fuzz/pull/2547.

This CL does not delete the header from `lib/fuzzer/utils` directory in order to
provide the downstream users some time for a smooth migration to the new
header location.

Reviewers: kcc, morehouse

Reviewed By: morehouse

Subscribers: lebedev.ri, kubamracek, dberris, mgorny, delcypher, #sanitizers, llvm-commits

Tags: #llvm, #sanitizers

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

llvm-svn: 367917

Summary:
This has no functional effect but makes it more obvious which parts of the
compiler do not use Register/MCRegister when you mark the implicit conversion
deprecated.

Implicit conversions for comparisons accounted for ~20% (~3k of ~13k) of
the implicit conversions when I first measured it. I haven't maintained
those numbers as other patches have landed though so it may be out of date.

Reviewers: arsenm

Reviewed By: arsenm

Subscribers: wdng, llvm-commits

Tags: #llvm

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

llvm-svn: 367916

The bots are sad that they're not documented.

llvm-svn: 367914

llvm-svn: 367912

All cc files have been renamed to cpp now.

llvm-svn: 367911

Ensures that CUDA fail reasons (such as "No CUDA-capable device detected")
are printed together with libomptarget's debug message
(e.g. "Error when setting CUDA context"). Previously, the former was
printed only in CMAKE_BUILD_TYPE=Debug builds while the latter was
enabled by LIBOMPTARGET_ENABLE_DEBUG.

With this change, also only call cuGetErrorString when the error will be
printed.

Suggested-by: Ye Luo <xw111luoye@gmail.com>

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

llvm-svn: 367910

This reverts commit r367907, it broke the test.

llvm-svn: 367909

Sets section alignments of the specified architecture slices to the
alignment values.
Alignment values are hexadecimal values that are powers of 2.

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

llvm-svn: 367908

llvm-svn: 367907

Apparently kernel support for IN_EXCL_UNLINK in inotify_add_watch() doesn't imply it's defined in sys/inotify.h.

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

llvm-svn: 367906

This patch implements the code generation for OpenMP 5.0 declare mapper
(user-defined mapper) constructs. For each declare mapper, a mapper
function is generated. These mapper functions will be called by the
runtime and/or other mapper functions to achieve user defined mapping.

The design slides can be found at
https://github.com/lingda-li/public-sharing/blob/master/mapper_runtime_design.pptx

Re-commit after revert in r367773 because r367755 changed the LLVM-IR
output such that a CHECK line failed.

Patch by Lingda Li <lildmh@gmail.com>

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

llvm-svn: 367905

This reverts commit r367882. It broke the test
MC/Disassembler/AMDGPU/gfx10_dasm_all.txt.

llvm-svn: 367904

Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).

The commit also adds support for running the PSTL tests as part of
the libc++ test suite.

The first attempt to commit this failed because it exposed a bug in the
tests for modules. Now that this has been fixed, it should be safe to
commit this.

Reviewers: EricWF

Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF

Tags: #libc

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

llvm-svn: 367903

This patch changes our defualt legalization behavior for 16, 32, and
64 bit vectors with i8/i16/i32/i64 scalar types from promotion to
widening. For example, v8i8 will now be widened to v16i8 instead of
promoted to v8i16. This keeps the elements widths the same and pads
with undef elements. We believe this is a better legalization strategy.
But it carries some issues due to the fragmented vector ISA. For
example, i8 shifts and multiplies get widened and then later have
to be promoted/split into vXi16 vectors.

This has the potential to cause regressions so we wanted to get
it in early in the 10.0 cycle so we have plenty of time to
address them.

Next steps will be to merge tests that explicitly test the command
line option. And then we can remove the option and its associated
code.

llvm-svn: 367901

Robustify update_test_checks.py to non-autogened tests, and add a mode to skip non-autogenerated ones

Intended use case is:
./utils/update_test_checks.py test/Transform/PassDir/* --update-only
(i.e. rapidly be able to see changes in autogened filed, before handing non-autogened tests individually)

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

llvm-svn: 367900

(matching r367495)

llvm-svn: 367899

Patch D56593 by @courbet results in calls to `bcmp()` in some cases, should
the target support the it.  Unless `TTI::MemCmpExpansionOptions()`
is overridden by the target.

In a proprietary benchmark we see a performance drop of about 12% on PNG
compression before this patch, though it passes all tests.

This patch mirrors X86 for AArch64 and initializes
`TTI::MemCmpExpansionOptions()` to then expand calls to `bcmp()` when
appropriate.  No tuning of the parameters was performed, but, at this point,
it's enough to recover the performance drop above.

This problem also exists on ARM.  Once a consensus is reached for AArch64, we
can work to fix ARM as well.

Authors:
- Evandro Menezes (@evandro) <e.menezes@samsung.com>
- Brian Rzycki (@brzycki) <b.rzycki@samsung.com>

Differential revision: https://reviews.llvm.org/D64805

llvm-svn: 367898

As discussed in https://reviews.llvm.org/D65148#1607019

The canonical fold is: https://rise4fun.com/Alive/FKe

llvm-svn: 367897

Adding documentation explaining why this dependency is required and should not be removed again.

llvm-svn: 367896