llvm-svn: 354378

Summary:
The goal of the test to check that msan does not crash when code is racy on __cxa_atexit. Original crash was caused by race condition in the glibc. With
the msan patch the msan does not crashes however the race is still there and the test triggers it.

Because the test relies on triggering of undefined behavior results are not
very predictable and it may occasionally crashes or hangs.

I don't see how to reasonably improve the test, so I remove it.

Reviewers: eugenis, peter.smith

Subscribers: jfb, jdoerfert, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

llvm-svn: 354377

[X86] Don't consider functions ABI compatible for ArgumentPromotion pass if they view 512-bit vectors differently.

The use of the -mprefer-vector-width=256 command line option mixed with functions
using vector intrinsics can create situations where one function thinks 512 vectors
are legal, but another fucntion does not.

If a 512 bit vector is passed between them via a pointer, its possible ArgumentPromotion
might try to pass by value instead. This will result in type legalization for the two
functions handling the 512 bit vector differently leading to runtime failures.

Had the 512 bit vector been passed by value from clang codegen, both functions would
have been tagged with a min-legal-vector-width=512 function attribute. That would
make them be legalized the same way.

I observed this issue in 32-bit mode where a union containing a 512 bit vector was
being passed by a function that used intrinsics to one that did not. The caller
ended up passing in zmm0 and the callee tried to read it from ymm0 and ymm1.

The fix implemented here is just to consider it a mismatch if two functions
would handle 512 bit differently without looking at the types that are being
considered. This is the easist and safest fix, but it can be improved in the future.

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

llvm-svn: 354376

  - Tests that use multiple short switches now test them grouped and ungrouped.

  - Ensure the output of ungrouped and grouped variants is identical

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

llvm-svn: 354375

Surprisingly, check_symbol_exists is not sufficient. The macOS linker checks the
called functions against a compatibility list for the given deployment target
and check_symbol_exists doesn't trigger this check as it never calls the
function.

This fixes the GreenDragon bots where the deployment target is 10.9

llvm-svn: 354374

llvm-svn: 354373

llvm-svn: 354370

This patch adds the new 5.0 API function omp_get_supported_active_levels().

Patch by Terry Wilmarth

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

llvm-svn: 354368

Remove fatal error messages from the cancellation API for GOMP
Add __kmp_barrier_gomp_cancel() to implement cancellation of parallel regions.
This new function uses the linear barrier algorithm with a cancellable
nonsleepable wait loop.

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

llvm-svn: 354367

[sanitizer] fix a memory safety bug (!!!) in sanitizer suppressions code, discovered by Aaron Jacobs

llvm-svn: 354366

Summary:
Instruments is a useful tool for finding performance issues in LLVM but it can
be difficult to identify regions of interest on the timeline that we can use
to filter the profiler or allocations instrument. Xcode 10 and the latest
macOS/iOS/etc. added support for the os_signpost() API which allows us to
annotate the timeline with information that's meaningful to LLVM.

This patch causes timer start and end events to emit signposts. When used with
-time-passes, this causes the passes to be annotated on the Instruments timeline.
In addition to visually showing the duration of passes on the timeline, it also
allows us to filter the profile and allocations instrument down to an individual
pass allowing us to find the issues within that pass without being drowned out
by the noise from other parts of the compiler.

Using this in conjunction with the Time Profiler (in high frequency mode) and
the Allocations instrument is how I found the SparseBitVector that should have
been a BitVector and the DenseMap that could be replaced by a sorted vector a
couple months ago. I added NamedRegionTimers to TableGen and used the resulting
annotations to identify the slow portions of the Register Info Emitter. Some of
these were placed according to educated guesses while others were placed
according to hot functions from a previous profile. From there I filtered the
profile to a slow portion and the aforementioned issues stood out in the
profile.

To use this feature enable LLVM_SUPPORT_XCODE_SIGNPOSTS in CMake and run the
compiler under Instruments with -time-passes like so:
  instruments -t 'Time Profiler' bin/llc -time-passes -o - input.ll'
Then open the resulting trace in Instruments.

There was a talk at WWDC 2018 that explained the feature which can be found at
https://developer.apple.com/videos/play/wwdc2018/405/ if you'd like to know
more about it.

Reviewers: bogner

Reviewed By: bogner

Subscribers: jdoerfert, mgorny, kristina, llvm-commits

Tags: #llvm

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

llvm-svn: 354365

Summary: As suggested in rL353995

Reviewers: compnerd

Reviewed By: compnerd

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 354364

D42042 introduced the ability for the ExecutionDomainFixPass to more easily change between BLENDPD/BLENDPS/PBLENDW as the domains required.

With this ability, we can avoid most bitcasts/scaling in the DAG that was occurring with X86ISD::BLENDI lowering/combining, blend with the vXi32/vXi64 vectors directly and use isel patterns to lower to the float vector equivalent vectors.

This helps the shuffle combining and SimplifyDemandedVectorElts be more aggressive as we lose track of fewer UNDEF elements than when we go up/down through bitcasts.

I've introduced a basic blend(bitcast(x),bitcast(y)) -> bitcast(blend(x,y)) fold, there are more generalizations I can do there (e.g. widening/scaling and handling the tricky v16i16 repeated mask case).

The vector-reduce-smin/smax regressions will be fixed in a future improvement to SimplifyDemandedBits to peek through bitcasts and support X86ISD::BLENDV.

Reapplied after reversion at rL353699 - AVX2 isel fix was applied at rL354358, additional test at rL354360/rL354361

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

llvm-svn: 354363

llvm-svn: 354362

llvm-svn: 354361

Reduced test case for the regression caused in D57888/rL353610

llvm-svn: 354360

Directly use the correct shift amount type if it is possible, and
future-proof the code against vectors. The added test makes sure that
bitwidths that do not fit into the shift amount type do not assert.

Split out from D57997.

llvm-svn: 354359

This was the cause of the regression in D57888 - the commuted load pattern wasn't hidden by the predicate so once we enabled v4i32 blends on SSE41+ targets then isel was incorrectly matched against AVX2+ instructions.

llvm-svn: 354358

klocwork critical issues in CG files:

Patch by Xiang Zhang (xiangzhangllvm)

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

llvm-svn: 354357

When parsing a sequence of tokens beginning with {, it will hit an assert and crash if the token afterwards is not an identifier. Instead of this, return a more verbose error as seen elsewhere in the function.

Patch by Brandon Jones (BrandonTJones)

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

llvm-svn: 354356

[X86] Filter out tuning feature flags and a few ISA feature flags when checking for function inline compatibility.

Tuning flags don't have any effect on the available instructions so aren't a good reason to prevent inlining.

There are also some ISA flags that don't have any intrinsics our ABI requirements that we can exclude. I've put only the most basic ones like cmpxchg16b and lahfsahf. These are interesting because they aren't present in all 64-bit CPUs, but we have codegen workarounds when they aren't present.

Loosening these checks can help with scenarios where a caller has a more specific CPU than a callee. The default tuning flags on our generic 'x86-64' CPU can currently make it inline compatible with other CPUs. I've also added an example test for 'nocona' and 'prescott' where 'nocona' is just a 64-bit capable version of 'prescott' but in 32-bit mode they should be completely compatible.

I've based the implementation here of the similar code in AMDGPU.

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

llvm-svn: 354355

llvm-svn: 354354

llvm-svn: 354353

llvm-svn: 354352

There was an extra space between the file location and the diagnostic
message:

  /tmp/a.c(1,12):  warning: unused parameter 'unused'

the tests didn't catch this due to FileCheck not running in --strict-whitespace mode.

Reported by Marco: http://lists.llvm.org/pipermail/cfe-dev/2019-February/061326.html

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

llvm-svn: 354351

This is another follow up to r354212 which is broken on Darwin when
cross-compiling runtimes to Linux when it ignores the -fuse-ld=lld
linker flag and attempts to use the host linker when performing the
compiler identification. Upon investigation, I noticed that setting
the project with appropriate list of languages makes the error go
away and it shouldn't hurt either.

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

llvm-svn: 354350

Summary:
Only to the APIs, which are used by our embedders.
We do not plan to add a user-facing option for this.

Reviewers: sammccall, ioeric

Reviewed By: sammccall

Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

llvm-svn: 354349

llvm-svn: 354348

This patch implements the parsing and sema support for OpenMP map
clauses with potential user-defined mapper attached. User defined mapper
is a new feature in OpenMP 5.0. A map clause can have an explicit or
implicit associated mapper, which instructs the compiler to generate
extra data mapping. An example is shown below:

    struct S { int len; int *d; };
    #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len])
    struct S ss;
    #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss

Contributed-by: Lingda Li <lildmh@gmail.com>

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

llvm-svn: 354347

The VBROADCAST combines and SimplifyDemandedVectorElts improvements mean that we now more consistently use shorter (128-bit) X86vzload input operands.

Follow up to D58053

llvm-svn: 354346

llvm-svn: 354345

yaml2obj/obj2yaml previously supported SHT_LOOS, SHT_HIOS, and
SHT_LOPROC for section types. These are simply values that delineate a
range and don't really make sense as valid values. For example if a
section has type value 0x70000000, obj2yaml shouldn't print this value
as SHT_LOPROC. Additionally, this was missing the three other range
markers (SHT_HIPROC, SHT_LOUSER and SHT_HIUSER).

This change removes these three range markers. It also adds support for
specifying the type as an integer, to allow section types that LLVM
doesn't know about.

Reviewed by: grimar

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

llvm-svn: 354344

llvm-svn: 354343

llvm-svn: 354342

llvm-svn: 354341

This patch adds scalar/subvector BROADCAST handling to EltsFromConsecutiveLoads.

It mainly shows codegen changes to 32-bit code which failed to handle i64 loads, although 64-bit code is also using this new path to more efficiently combine to a broadcast load.

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

llvm-svn: 354340

yaml2obj was changed in r354338("[yaml2obj][obj2yaml] - Support SHT_GNU_versym (.gnu.version) section.")

llvm-svn: 354339

This patch adds support for parsing dumping the .gnu.version section.
Description of the section is: https://refspecs.linuxfoundation.org/LSB_1.3.0/gLSB/gLSB/symversion.html#SYMVERTBL

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

llvm-svn: 354338

Summary:

For some reason OpenCL blocks in LLVM IR are represented as function pointers.
These pointers do not point to any real function and never get called. Actually
they point to some structure, which in turn contains pointer to the real block
invoke function.
This patch changes represntation of OpenCL blocks in LLVM IR from function
pointers to pointers to `%struct.__block_literal_generic`.
Such representation allows to avoid unnecessary bitcasts and simplifies
further processing (e.g. translation to SPIR-V ) of the module for targets
which do not support function pointers.

Patch by: Alexey Sotkin.

Reviewers: Anastasia, yaxunl, svenvh

Reviewed By: Anastasia

Subscribers: alexbatashev, cfe-commits

Tags: #clang

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

llvm-svn: 354337

The test checks common functionality. Let's use `x86` (generic LLD target)
as a target architecture.

llvm-svn: 354336