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

llvm-svn: 365269

[X86] Add PS<->PD domain changing support for MOVH/MOVL load instructions and MOVH store instructions.

These instructions don't have an integer domain equivalent, but
we can at least change between the two floating point domains.

This allows a smaller encoding on SSE targets if we can turn
PD into PS.

llvm-svn: 365268

These patterns are the same as the MOVLPDmr and MOVHPDmr patterns,
but with a bitcast at the end. We can just select the PD instruction
and let execution domain fixing switch to PS.

llvm-svn: 365267

These narrow the load so we can only do it if the load isn't
volatile.

There also tests in vector-shuffle-128-v4.ll that this should
support, but we don't seem to fold bitcast+load on pre-sse4.2
targets due to the slow unaligned mem 16 flag.

llvm-svn: 365266

[X86] Copy some test cases from vector-shuffle-sse1.ll to vector-shuffle-128-v4.ll and v8 where sse1 did better load folding. NFC

llvm-svn: 365265

http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/10272

llvm-svn: 365264

http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/10270

llvm-svn: 365263

llvm-svn: 365262

Make 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: 365261

Without this, we have the unfortunate property that tests are dependent on the order of operads passed the CreateOr and CreateAnd functions.  In actual usage, we'd promptly optimize them away, but it made tests slightly more verbose than they should have been.

llvm-svn: 365260

We had versions of this code scattered around, so consolidate into one location.

Not strictly NFC since the order of intermediate results may change in some places, but since these operations are associatives, should not change results.

llvm-svn: 365259

Some Rewrite functions are already overloaded to accept
CharSourceRange, and this extends others in the same manner.  I'm
calling these in code that's not ready to upstream, but I figure they
might be useful to others in the meantime.

Reviewed By: jdoerfert

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

llvm-svn: 365258

llvm-svn: 365257

Although removeCopyByCommutingDef deals with full copies, it is still
possible to copy undef lanes and thus, we wouldn't have any a value
number for these lanes.

This fixes PR40215.

llvm-svn: 365256

I'm not sure if it's worth it or not to add a hook to disable the pass
for an arbitrary function.

This pass is taking up to 5% of compile time in tiny programs by
iterating through all of the physical registers in every register
class. This pass should be rewritten in terms of regunits. For now,
skip doing anything for entry point functions. The vast majority of
functions in the real world aren't callable, so just not running this
will give the majority of the benefit.

llvm-svn: 365255

llvm-svn: 365254

llvm-svn: 365253

This reverts commit 096600a4.

llvm-svn: 365251

As per Davide's suggestion offline.

llvm-svn: 365250

Summary:
This patch simplifies 2 aspects in the FileCheckNumericVariable code.

First, setValue() method is turned into a void function since being
called only on undefined variable is an invariant and is now asserted
rather than returned. This remove the assert from the callers.

Second, clearValue() method is also turned into a void function since
the only caller does not check its return value since it may be trying
to clear the value of variable that is already cleared without this
being noteworthy.

Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk

Subscribers: JonChesterfield, rogfer01, hfinkel, kristina, rnk, tra, arichardson, grimar, dblaikie, probinson, llvm-commits, hiraditya

Tags: #llvm

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

llvm-svn: 365249