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

Unlike asan, which isn't supported yet on 64-bit Solaris/x86, there's no reason to disable
ubsan.  This patch does that, but keeps the 64-bit ubsan-with-asan tests disabled.

Tested on x86_64-pc-solaris2.11.

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

llvm-svn: 365302

Defines RISCV registers for getExceptionPointerRegister() and
getExceptionSelectorRegister().

Differential Revision: https://reviews.llvm.org/D63411
Patch by Edward Jones.
Modified by Alex Bradbury to add CHECK lines to exception-pointer-register.ll.

llvm-svn: 365301

Summary:
Change the vuqadd scalar instrinsics to have the second argument as unsigned values, not signed,
accordingly to https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics

So now the compiler correctly warns that a undefined negative float conversion is being done.

Reviewers: LukeCheeseman, john.brawn

Reviewed By: john.brawn

Subscribers: john.brawn, javed.absar, kristof.beyls, cfe-commits

Tags: #clang

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

llvm-svn: 365300

[ARM] Fix null pointer dereference in CodeGen/ARM/Windows/stack-protector-msvc.ll.test after D64292/r365283

CLI.CS may not be set.

llvm-svn: 365299

Summary:
Change the vsqadd scalar instrinsics to have the second argument as signed values, not unsigned,
accordingly to https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics

The existing unsigned argument can cause faulty code as negative float to unsigned conversion is
undefined, which llvm/clang optimizes away.

Reviewers: LukeCheeseman, john.brawn

Reviewed By: john.brawn

Subscribers: john.brawn, javed.absar, kristof.beyls, cfe-commits

Tags: #clang

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

llvm-svn: 365298

This mirrors the change made for X86 in rL336987. Without this patch,
update_llc_test_checks will completely skip functions with personality
functions.

llvm-svn: 365297

On Windows, the bitfield layout rule places `ussigned Referenced : 1` at
byte offset 40, instead of byte offset 37 on *NIX. The consequence is that
sizeof(SymbolUnion) == 104 on Windows while 96 on *NIX.

To eliminate this difference, change these unsigned bitfields to bool.

Reviewed By: ruiu

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

llvm-svn: 365296

Fixes Linux build errors after D64163/r365226

llvm-svn: 365295

Reviewers: arsenm

Reviewed By: arsenm

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

Tags: #llvm

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

llvm-svn: 365294

This can help with code size on SSE targets where SHUFPD requires
a 0x66 prefix and SHUFPS doesn't.

llvm-svn: 365293

This can help avoid a copy or enable load folding.

On SSE4.1 targets we can commute it to blendi instead.

I had to make shufpd with a 0x02 immediate commutable as well
since we expect commuting to be reversible.

llvm-svn: 365292

Differential Revision: https://reviews.llvm.org/D57792
Patch by James Clarke.

llvm-svn: 365291

Make forward_list::remove/remove_if/unique all return void before C++20; undoes that bit of D58332. Thanks to Mikhail Maltsev for pointing this out

llvm-svn: 365290

This speeds up some hot paths significantly (e.g.  dex::generateProximityURIs
by a third or so)

llvm-svn: 365289

llvm-svn: 365288

[X86] Add MOVSDrr->MOVLPDrm entry to load folding table. Add custom handling to turn UNPCKLPDrr->MOVHPDrm when load is under aligned.

If the load is aligned we can turn UNPCKLPDrr into UNPCKLPDrm.

llvm-svn: 365287

This allows us to use the analyzer from unit tests.

* Refactor the interface to use proper error handling for most functions
  after JF's work.
* Move everything into a BitstreamAnalyzer class.
* Move that to Bitcode/BitcodeAnalyzer.h.

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

llvm-svn: 365286

llvm-svn: 365285

This reverts commit r365260 which broke the following tests:

    Clang :: CodeGenCXX/cfi-mfcall.cpp
    Clang :: CodeGenObjC/ubsan-nullability.m
    LLVM :: Transforms/LoopVectorize/AArch64/pr36032.ll

llvm-svn: 365284

Heavily based on the same for AArch64, from SVN r346469.

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

llvm-svn: 365283

The Windows build currently cannot support debugging foreign targets or
debugging Windows ARM NT and Windows ARM64 targets.  Do not assume a
x64/x86 host.  This enables building lldb for Windows ARM64.

llvm-svn: 365282

The implementations of __libcpp_mutex_destroy and __libcpp_condvar_destroy
are already NOPs, so this optimization is safe to perform.

See r365273 and PR27658 for more information.

llvm-svn: 365281

Found by inspection; the sync script doesn't sync .ipp files.

llvm-svn: 365280

llvm-svn: 365279

llvm-svn: 365278

Since these are in a custom list, `gn format` doesn't automatically sort
them.

Now their order matches the CMake build.

No additions or deletions, this just sorts the files that are there.

llvm-svn: 365277

llvm-svn: 365276

llvm-svn: 365275

Some out of tree backend require larger vector type. Since maintaining the changes out of tree is difficult due to the many manual changes needed when adding a new type we are adding it even if no backend currently use it.

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

Patch by Thomas Raoux!

llvm-svn: 365274

Currently std::mutex has a constexpr constructor, but a non-trivial
destruction.

The constexpr constructor is required to ensure the construction of a
mutex with static storage duration happens at compile time, during
constant initialization, and not during dynamic initialization.
This means that static mutex's are always initialized and can be used
safely during dynamic initialization without the "static initialization
order fiasco".

A trivial destructor is important for similar reasons. If a mutex is
used during dynamic initialization it might also be used during program
termination. If a static mutex has a non-trivial destructor it will be
invoked during termination. This can introduce the "static
deinitialization order fiasco".

Additionally, function-local statics emit a guard variable around
non-trivially destructible types. This results in horrible codegen and
adds a runtime cost to every call to that function. non-local static's
also result in slightly worse codegen but it's not as big of a problem.

Example codegen can be found here: https://goo.gl/3CSzbM

Note: This optimization is not safe with every pthread implementation.
Some implementations allocate on the first call to pthread_mutex_lock
and free the allocation in pthread_mutex_destroy.

Also, changing the triviality of the destructor is not an ABI break.
At least to the best of my knowledge :-)

llvm-svn: 365273

Treat the range of representable values of floating-point types as [-inf, +inf] not as [-max, +max].

Summary:
Prior to r329065, we used [-max, max] as the range of representable
values because LLVM's `fptrunc` did not guarantee defined behavior when
truncating from a larger floating-point type to a smaller one. Now that
has been fixed, we can make clang follow normal IEEE 754 semantics in this
regard and take the larger range [-inf, +inf] as the range of representable
values.

In practice, this affects two parts of the frontend:
 * the constant evaluator no longer treats floating-point evaluations
   that result in +-inf as being undefined (because they no longer leave
   the range of representable values of the type)
 * UBSan no longer treats conversions to floating-point type that are
   outside the [-max, +max] range as being undefined

In passing, also remove the float-divide-by-zero sanitizer from
-fsanitize=undefined, on the basis that while it's undefined per C++
rules (and we disallow it in constant expressions for that reason), it
is defined by Clang / LLVM / IEEE 754.

Reviewers: rnk, BillyONeal

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 365272

Fixes cppcheck warning.

llvm-svn: 365271

llvm-svn: 365270