We recognize a splat from element 0 in (VectorUtils) llvm::getSplatValue()
and also in ShuffleVectorInst::isZeroEltSplatMask(), so this converts
to that form for better matching.

The backend generically turns these patterns into build_vector,
so there should be no codegen difference.

llvm-svn: 365342

The revision at https://reviews.llvm.org/rL365336 added inference of the nofree
attribute.  This revision updates the test to reflect this.

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

llvm-svn: 365341

llvm-svn: 365340

The IRBuilder has calls to create floating point instructions like fadd.
It does not have calls to create constrained versions of them. This patch
adds support for constrained creation of fadd, fsub, fmul, fdiv, and frem.

Reviewed by:	John McCall, Sanjay Patel
Approved by:	John McCall
Differential Revision:	https://reviews.llvm.org/D53157

llvm-svn: 365339

llvm-svn: 365338

Also, use a single point of customization to set what namespace __par_backend
"points to", which provides a better separation of concerns.

llvm-svn: 365337

This patch adds a function attribute, nofree, to indicate that a function does
not, directly or indirectly, call a memory-deallocation function (e.g., free,
C++'s operator delete).

Reviewers: jdoerfert

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

llvm-svn: 365336

llvm-svn: 365335

NFC.

llvm-svn: 365334

I added this test in rL365325, but didn't mean to create an undef insert.

llvm-svn: 365333

Summary:
__kmpc_push_tripcount function is not thread safe and may lead to data
race when the target regions are executed in parallel threads. The patch
makes loopTripCnt counter thread aware and stores the tripcount value
per thread in the map. Access to map is guarded by mutex to prevent
data race in the map itself.
Test is for NVPTX target because it does not work correctly on the
host. Seems to me, there is a problem in libomp with target regions in
the parallel threads.

Reviewers: grokos

Subscribers: guansong, jfb, jdoerfert, openmp-commits, kkwli0, caomhin

Tags: #openmp

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

llvm-svn: 365332

Reviewers: sammccall

Reviewed By: sammccall

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

Tags: #clang

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

llvm-svn: 365331

llvm-svn: 365330

Use new helper introduced in rL365327.

llvm-svn: 365329

Keep the uint64_t type from getConstantOperandVal to stop truncation/extension overflow warnings in MSVC in subvector index math.

llvm-svn: 365328

This matches isARM, isThumb, isAArch64 and similar helpers. Future commits
which clean-up code that currently checks for Triple::riscv32 ||
Triple::riscv64.

Differential Revision: https://reviews.llvm.org/D54215
Patch by Simon Cook.
Test case added by Alex Bradbury.

llvm-svn: 365327

Summary:
Otherwise, when libcxxabi is not an enabled project in the monorepo, we
get a link error because we try to link against non-existent cxxabi_shared.

More generally, we shouldn't change the behavior of the build based on
implicit things like whether a file happens to be at a specific path or
not.

This is a re-application of r365222 that had been reverted in r365233
because it broke the build bots. However, the build bots now specify
explicitly what ABI library they want to use (libc++abi), so this
commit should now be OK to merge.

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

llvm-svn: 365326

llvm-svn: 365325

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

llvm-svn: 365324

Select gprb or fprb when loaded value is used by either:
 copy to physical register or
 instruction with only one mapping available for that use operand.

Load of integer s64 is handled with narrowScalar when mapping is applied,
produced artifacts are combined away. Manually set gprb to all register
operands of instructions created during narrowScalar.

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

llvm-svn: 365323

Select gprb or fprb when stored value is defined by either:
 copy from physical register or
 instruction with only one mapping available for that def operand.

Store of integer s64 is handled with narrowScalar when mapping is applied,
produced artifacts are combined away. Manually set gprb to all register
operands of instructions created during narrowScalar.

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

llvm-svn: 365322

Summary of changes:

- simplified handling of FLAT offset: offset_s13 and offset_u12 have been replaced with flat_offset;
- provided information about error position for pre-gfx9 targets;
- improved errors handling.

Reviewers: artem.tamazov, arsenm, rampitec

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

llvm-svn: 365321

llvm-svn: 365320

Fixes AMDGPU patterns for 32-bit address spaces always failing. Tests
will be included in future patches when additional issues are solved.

llvm-svn: 365319

This change adds tests to cover existing llvm-ar functionality.

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

llvm-svn: 365318

Reverted due to test failures

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

llvm-svn: 365317

This change adds tests to cover existing llvm-ar functionality.

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

llvm-svn: 365316

Summary:
The current import implementation fails to import the definition of a
lambda class if the lambda class is defined in a function param.
E.g., the lambda class below will be imported without any methods:
```
  template <typename F>
  void f(F L = [](){}) {}
```

Reviewers: a_sidorin, a.sidorin, shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

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

llvm-svn: 365315

Summary:
During CTU analysis of complex projects, the loaded AST-contents of
imported TUs can grow bigger than available system memory. This option
introduces a threshold on the number of TUs to be imported for a single
TU in order to prevent such cases.

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

llvm-svn: 365314

Similar to `FILECHECK_OPTS` for FileCheck, `LIT_OPTS` makes it easy to
adjust lit behavior when running the test suite via ninja.  For
example:

```
$ LIT_OPTS='--time-tests -vv --filter=threadprivate' \
  ninja check-clang-openmp
```

Reviewed By: probinson

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

llvm-svn: 365313

We briefly referred to being able to specify --target=binary without
explaining what binary input/output meant. This change adds a section on
this.

Reviewed by: MaskRay, abrachet

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

llvm-svn: 365312

Summary:
Currently SHA1 is about 10% of our CPU, this patch reduces it to ~1%.

xxhash is a well-defined (stable) non-cryptographic hash optimized for
fast checksums (like crc32).
Collisions shouldn't be a problem, despite the reduced length:
 - for actual file content (used to invalidate bg index shards), there
   are only two versions that can collide (new shard and old shard).
 - for file paths in bg index shard filenames, we would need 2^32 files
   with the same filename to expect a collision. Imperfect hashing may
   reduce this a bit but it's well beyond what's plausible.

This will invalidate shards on disk (as usual; I bumped the version),
but this time the filenames are changing so the old files will stick
around :-( So this is more expensive than the usual bump, but would be
good to land before the v9 branch when everyone will start using bg index.

Reviewers: kadircet

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, llvm-commits

Tags: #llvm

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

llvm-svn: 365311

Fix for feedback nit from rL364998

llvm-svn: 365310

Don't do this locally, computeKnownBits does this better (and can handle non-constant cases as well).

A next step would be to actually simplify non-constant elements - building on what we already do in SimplifyDemandedVectorElts.

llvm-svn: 365309

We should be generating one __start/__stop pair per output segment
not per input segment.  The test wasn't catching this because it was
only linking a single object file.

Fixes PR41565

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

llvm-svn: 365308

llvm-svn: 365307

Summary:
According to a recently updated Armv8-M spec
(https://static.docs.arm.com/ddi0553/bh/DDI0553B_h_armv8m_arm.pdf) the
32-bit width versions of the following instructions:
* VQDMLADH
* VQDMLADHX
* VQRDMLADH
* VQRDMLADHX
* VQDMLSDH
* VQDMLSDHX
* VQRDMLSDH
* VQRDMLSDHX
are no longer unpredictable when their output register is the same as
one of the input registers.

This patch updates the assembler parser and the corresponding tests
and also removes @earlyclobber from the instruction constraints.

Reviewers: simon_tatham, ostannard, dmgreen, SjoerdMeijer, samparker

Reviewed By: simon_tatham

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

Tags: #llvm

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

llvm-svn: 365306

Implements the handling of __builtin_eh_return_regno().

Differential Revision: https://reviews.llvm.org/D63417
Patch by Edward Jones.

llvm-svn: 365305

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

llvm-svn: 365304

A couple of UBSan-*  :: TestCases/ImplicitConversion testcases FAIL on Solaris/x86
(and Solaris/SPARC with https://reviews.llvm.org/D40900):

  FAIL: UBSan-AddressSanitizer-i386 :: TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c (49187 of 49849)
  ******************** TEST 'UBSan-AddressSanitizer-i386 :: TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c' FAILED ********************
  [...]
  Command Output (stderr):
  --
  /vol/llvm/src/compiler-rt/local/test/ubsan/TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c:53:11: error: CHECK: expected string not found in input
  // CHECK: {{.*}}signed-integer-truncation-or-sign-change-blacklist.c:[[@LINE-1]]:10: runtime error: implicit conversion from type '{{.*}}' (aka 'unsigned int') of value 4294967295 (32-bit, unsigned) to type '{{.*}}' (aka 'signed char') changed the value to -1 (8-bit, signed)
            ^
  <stdin>:1:1: note: scanning from here
  /vol/llvm/src/compiler-rt/local/test/ubsan/TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c:52:10: runtime error: implicit conversion from type 'uint32_t' (aka 'unsigned int') of value 4294967295 (32-bit, unsigned) to type 'int8_t' (aka 'char') changed the value to -1 (8-bit, signed)
  ^
  <stdin>:1:1: note: with "@LINE-1" equal to "52"
  /vol/llvm/src/compiler-rt/local/test/ubsan/TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c:52:10: runtime error: implicit conversion from type 'uint32_t' (aka 'unsigned int') of value 4294967295 (32-bit, unsigned) to type 'int8_t' (aka 'char') changed the value to -1 (8-bit, signed)
  ^
  <stdin>:1:69: note: possible intended match here
  /vol/llvm/src/compiler-rt/local/test/ubsan/TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c:52:10: runtime error: implicit conversion from type 'uint32_t' (aka 'unsigned int') of value 4294967295 (32-bit, unsigned) to type 'int8_t' (aka 'char') changed the value to -1 (8-bit, signed)
                                                                      ^

This is always a difference for int8_t where signed char is expected, but only
char seen.

I could trace this to <sys/int_types.h> which has

  /*
   * Basic / Extended integer types
   *
   * The following defines the basic fixed-size integer types.
   *
   * Implementations are free to typedef them to Standard C integer types or
   * extensions that they support. If an implementation does not support one
   * of the particular integer data types below, then it should not define the
   * typedefs and macros corresponding to that data type.  Note that int8_t
   * is not defined in -Xs mode on ISAs for which the ABI specifies "char"
   * as an unsigned entity because there is no way to define an eight bit
   * signed integral.
   */
  #if defined(_CHAR_IS_SIGNED)
  typedef char			int8_t;
  #else
  #if defined(__STDC__)
  typedef signed char		int8_t;
  #endif
  #endif

_CHAR_IS_SIGNED is always defined on both sparc and x86.  Since it seems ok
to have either form, I've changed the affected tests to use
'{{(signed )?}}char' instead of 'signed char'.

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

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

llvm-svn: 365303