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

This dependency was removed in  r357486, which has lead to a stream of difficult to diagnose bugs.

Without this dependency, when building with `LLVM_OPTIMIZED_TABLEGEN=On` the native tablegen executible may not be rebuilt at all, and often won't get rebuilt before targets that use the tablegen headers. In the best case this results in a build-time failure, in the worst case it results in runtime failures.

llvm-svn: 367895

Summary:
The Arm Neoverse N1 Software Optimization Guide [1], Section "4.8 Branch
instruction alignment" states:

"Consider aligning subroutine entry points and branch targets to 32B
boundaries, within the bounds of the code-density requirements of the
program."

This patch sets the preferred function alignment on Neoverse N1 to 2^4=16B.
This was already the case in some of the latest Cortex-A CPUs. Benchmarking
in previous Cortex-A CPUs suggested that 16B alignment is already better
than the default. See commit d04ee305.

The reason we don't set it to 32B right now (as the optimisation guide
suggests) is that this will impact code size and perhaps the instruction
cache performance. Therefore we need benchmark numbers first.

I have also added testing for A75 and A76 that we were missing.

[1] https://developer.arm.com/docs/swog309707/latest

Reviewers: fhahn, greened, samparker, dmgreen

Reviewed By: dmgreen

Subscribers: dmgreen, javed.absar, kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367894

This reverts commit 58c814614d2ac69bcf79b09543505fac80ada4e6.
Fixes build breakage using LLVM<7.

llvm-svn: 367893

llvm-svn: 367892

This appears to slightly help patterns similar to what's
shown in PR42874:
https://bugs.llvm.org/show_bug.cgi?id=42874
...but not in the way requested.

That fix will require some later IR and/or backend pass to
decompose multiply/shifts into something more optimal per
target. Those transforms already exist in some basic forms,
but probably need enhancing to catch more cases.

https://rise4fun.com/Alive/Qzv2

llvm-svn: 367891

llvm-svn: 367890

Reviewers: aaron.ballman

Subscribers: jkorous, dexonsmith, cfe-commits

Tags: #clang

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

llvm-svn: 367889

llvm-svn: 367888

See r367803 and similar other changes.

llvm-svn: 367887

Some compiler, notably older gccs (< 8) can have trouble with multiline raw
string literals inside macros. This just moves the code outsize the macro, to
attempt to appease the bots.

llvm-svn: 367885

llvm-svn: 367884

llvm-svn: 367883

Summary: During fdiv32 lowering use S_DENORM_MODE to select denorm mode in gfx10.

Reviewers: arsenm, rampitec

Reviewed By: arsenm, rampitec

Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367882

Summary:
This is a follow up to r367237.  MachineFunction::getMachineMemOperand()
adds the offset parameter to the existing offset instead of resetting it.
So we need to reset the offset to the correct value after calling this
function.

Reviewers: arsenm

Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367881

As the test shows, we can end up with more instructions than
we started with if we don't include the extra-use check.

llvm-svn: 367880

Don't assume format loads for f16. Also fixes support for targets
without i16.

llvm-svn: 367879

Summary:
Core files have different descriptions for note values. llvm-readelf currently prints the generic note type, which is wrong when using it to read a core file.

To verify the constants/strings, see:
Values: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=include/elf/common.h;h=75c4fb7e9d7c0f780d635ac305f579546b7b071b;hb=HEAD#l571
Strings: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=binutils/readelf.c;h=c31a5c1266b7bb62a485895b01b49e1f832ade35;hb=HEAD#l16881

Note: this does not handle printing the note data for NT_FILE, it just fixes the descriptions.

Reviewers: MaskRay

Reviewed By: MaskRay

Subscribers: labath, llvm-commits

Tags: #llvm

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

llvm-svn: 367878

Some tls-*.s tests do not test generic TLS behavior but rather are x86 specific.
Rename them to i386-*.s or x86-64-*.s

Delete tls-static.s: covered by tls-opt.s
Delete tls-opt-no-plt.s: add --implicit-check-not=.plt to x86-64-tls-gdie.s to cover it

Rename tls-dynamic-i686.s to i386-tls-dynamic.s
Rename tls-i686.s to i386-tls-le.s
Rename tls-opt-i686.s to i386-tls-opt.s
Rename tls-opt-iele-i686-nopic.s to i386-tls-opt-iele-nopic.s

Rename tls-dynamic.s to x86-64-tls-dynamic.s . IE should be split off in the future.
Rename tls-error.s to x86-64-reloc-tpoff32-error.s
Rename tls-opt-gdie.s to x86-64-tls-gdie.s
Rename tls-opt-x86_64-noplt.s to x86-64-tls-opt-noplt.s
Rename tls-opt-local.s => x86-64-tls-ie-opt-local.s . It can be merged with x86-64-tls-ie-local.s in the future.

llvm-svn: 367877

llvm-svn: 367876

The MSan bot was (rightfully) complaining that NumASTLoaded was
unitialized, so put the initialization removed in r367829 back in.

While here, remove two needless semicolons added in that change.

llvm-svn: 367875

See PR42868 for more details.

The affected list of tests is:

Failing Tests (8):
    AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test.exe/AddressSanitizer.LargeOOBRightTest
    AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test.exe/AddressSanitizer.OOBRightTest
    AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test.exe/AddressSanitizer.OOB_char
    AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test.exe/AddressSanitizer.OOB_int
    AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test.exe/AddressSanitizer.LargeOOBRightTest
    AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test.exe/AddressSanitizer.OOBRightTest
    AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test.exe/AddressSanitizer.OOB_char
    AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test.exe/AddressSanitizer.OOB_int

llvm-svn: 367874

gtest's built-in regex engine doesn't support (). Looks like it's not
needed, just remove it.

See PR42868 for more details.

llvm-svn: 367873

This was switching to use a format store for a non-format store for
f16 types. Also fixes i16/f16 stores on targets without legal f16.

The corresponding loads also need to be fixed.

llvm-svn: 367872

Without context we assume SGPR. Allowing VGPR constants theoretically
helps avoid a copy. This seems to not actually work now, and the
choice isn't based on the use bank.

llvm-svn: 367871

I'm not sure what complications these present, but the current
argument lowering is pretty much directly copied from the DAG
lowering, so I assume these work as they should.

No tests because I'm lazy and things are getting pretty close to the
point where the existing calling-conventions.ll can be shared with
SelectionDAG.

llvm-svn: 367870

We prioritize non-* wildcards overs VER_NDX_LOCAL/VER_NDX_GLOBAL "*".
This patch generalizes the rule to "*" of other versions and thus fixes PR40176.
I don't feel strongly about this GNU linkers' behavior but the
generalization simplifies code.

Delete `config->defaultSymbolVersion` which was used to special case
VER_NDX_LOCAL/VER_NDX_GLOBAL "*".

In `SymbolTable::scanVersionScript`, custom versions are handled the same
way as VER_NDX_LOCAL/VER_NDX_GLOBAL. So merge
`config->versionScript{Locals,Globals}` into `config->versionDefinitions`.
Overall this seems to simplify the code.

In `SymbolTable::assign{Exact,Wildcard}Versions`,
`sym->verdefIndex == config->defaultSymbolVersion` is changed to
`verdefIndex == UINT32_C(-1)`.
This allows us to give duplicate assignment diagnostics for
`{ global: foo; };` `V1 { global: foo; };`

In test/linkerscript/version-script.s:
  vs_index of an undefined symbol changes from 0 to 1. This doesn't matter (arguably 1 is better because the binding is STB_GLOBAL) because vs_index of an undefined symbol is ignored.

Reviewed By: ruiu

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

llvm-svn: 367869

llvm-svn: 367868

Changing representation of .cv_def_range directives in Codeview debug info assembly format for better readability

llvm-svn: 367867

Builtins-*-sunos :: compiler_rt_logbf_test.c currently FAILs on Solaris, both SPARC and
x86, 32 and 64-bit.

It turned out that this is due to different behaviour of logb depending on the C
standard compiled for, as documented on logb(3M):

  RETURN VALUES
         Upon successful completion, these functions return the exponent of x.
  
         If x is subnormal:
  
             o      For SUSv3-conforming applications compiled with the c99 com-
                    piler  driver  (see standards(7)), the exponent of x as if x
                    were normalized is returned.
  
             o      Otherwise, if compiled with the cc compiler  driver,  -1022,
                    -126,  and  -16382  are  returned  for  logb(), logbf(), and
                    logbl(), respectively.

Studio c99 and gcc control this by linking with the appropriate version of values-xpg[46].o, but clang uses neither of those.

The following patch fixes this by following what gcc does, as corrected some time ago in

  Fix use of Solaris values-Xc.o (PR target/40411)
  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02350.html and
  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02384.html.

Tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.

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

llvm-svn: 367866

D65562 <https://reviews.llvm.org/D65562> moves LangStandard.h from clang/Frontend to clang/Basic.  This patch
adjusts the single file in lldb that uses it to match.

Tested on x86_64-pc-linux-gnu.

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

llvm-svn: 367865