llvm-svn: 362697

llvm-svn: 362696

Prep work for PR42105 - clang-format, use auto for cast and merge nested if()s

llvm-svn: 362695

Tabs are not our friends.

llvm-svn: 362694

Adds missing lit.local.cfg. Fixes rL362691.

llvm-svn: 362693

Select G_FSQRT for MIPS32.

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

llvm-svn: 362692

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

llvm-svn: 362691

Select G_FABS for MIPS32.

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

llvm-svn: 362690

Select G_FPEXT and G_FPTRUNC for MIPS32.

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

llvm-svn: 362689

Select G_FFLOOR and G_FCEIL for MIPS32.

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

llvm-svn: 362688

If the given SCEVExpr has no (un)signed flags attached to it, transfer
these to the resulting instruction or use them to find an existing
instruction.

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

llvm-svn: 362687

ContainsActiveParameter is not used anywhere, set incorrectly (see the
removed FIXME) and has no unit tests.
Removing it to simplify the code.

llvm-svn: 362686

For more details about these instructions, please refer to the latest
ISE document:
https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference.

Patch by Tianqing Wang (tianqing)

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

llvm-svn: 362685

In that commit, the 'load.ll' test was modified, but still failed.

This commit updates the test so that it now passes.

llvm-svn: 362684

The docs were inconsistent: requesting the user to clone the monorepo,
and then continuing with the `llvm/tools/clang` layout.

Follow-up to a question on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2019-June/062518.html

llvm-svn: 362683

llvm-svn: 362682

We already get support for G_ZEXTLOAD to s32 from the importer, but it can't
deal with the SUBREG_TO_REG in the pattern. Tweaking the existing manual
selection code for G_LOAD to handle an additional SUBREG_TO_REG when dealing
with G_ZEXTLOAD isn't much work.

Also add tests to check the imported pattern selections to s32 work.

llvm-svn: 362681

This reverts commit 7ce7110e, it was
causing sanitizer bot failures due to changing behavior of
std::to_string(). See https://reviews.llvm.org/D59178#1532023

llvm-svn: 362680

Summary:
These test cases are illgal in C++2a ("new Foo{}" needs to see the
default constructor), so move them to the C++14-only tests.

Reviewers: gribozavr

Subscribers: xazax.hun, cfe-commits

Tags: #clang

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

llvm-svn: 362679

Summary: 
A modification of the parallel sorting algorithm, additionally optimized for a partially sorted array.

Reviewers: rodgert
           ldionne

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

llvm-svn: 362678

The changes weren't staged so ended up just re-commiting the unmodified reverted change.

llvm-svn: 362677

Author: Sajjad Mirza

Differential Revision: http://reviews.llvm.org/D62541

llvm-svn: 362676

[X86] Don't turn avx masked.load with constant mask into masked.load+vselect when passthru value is all zeroes.

This is intended to enable the use of an immediate blend or
more optimal instruction. But if the passthru is zero we don't
need any additional instructions.

llvm-svn: 362675

avx/avx2 masked loads only support all zeros for passthru in hardware.
So we have to emit a blend for all other values. We have an optimization
that tries to optimize this blend if the mask is constant. But we
don't need to perform this optimization if the passthru value is zero
which doesn't need the blend at all.

llvm-svn: 362674

On Android, pipe() is better to be replaced by pipe2() with O_CLOEXEC
flag to avoid file descriptor leakage.

Patch by Jian Cai!

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

llvm-svn: 362673

On Android, pipe2() is better to set O_CLOEXEC flag to avoid file
descriptor leakage.

Patch by Jian Cai!

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

llvm-svn: 362672

Summary:
LSan is currently being ported to Emscripten and mostly works.

Enabling the support in upstream would simplify testing.

Patch by Guanzhong Chen.

Reviewers: tlively, aheejin

Reviewed By: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, sunfish, cfe-commits

Tags: #clang

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

llvm-svn: 362667

When looking through copies, make sure to not try to find the vreg def of a physreg.
Normally getVRegDef will return nullptr in this case, but if there happens to be
multiple defs then it will assert.

This fixes PR42129.

llvm-svn: 362666

This forced the caller to be aware of this, which is an ugly ABI
feature.

Partially reverts r295877. The original reasons for doing this are
mostly fixed. Alloca is now in a non-0 address space, so it should be
OK to have 0 as a valid pointer. Since we treat the absolute address
as the pointer value, this part only really needed to apply to
kernels.

Since r357093, we avoid the need to increment/decrement the offset
register in more cases, and since r354816 the scavenger can fail
without spilling, so it's less critical that we try to avoid an offset
that fits in the MUBUF offset.

Restrict to callable functions for now to split this into 2 steps to
limit thte number of test updates and in case anything breaks.

llvm-svn: 362665

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

llvm-svn: 362664

The ISD::STRICT_ nodes used to implement the constrained floating-point
intrinsics are currently never passed to the target back-end, which makes
it impossible to handle them correctly (e.g. mark instructions are depending
on a floating-point status and control register, or mark instructions as
possibly trapping).

This patch allows the target to use setOperationAction to switch the action
on ISD::STRICT_ nodes to Legal. If this is done, the SelectionDAG common code
will stop converting the STRICT nodes to regular floating-point nodes, but
instead pass the STRICT nodes to the target using normal SelectionDAG
matching rules.

To avoid having the back-end duplicate all the floating-point instruction
patterns to handle both strict and non-strict variants, we make the MI
codegen explicitly aware of the floating-point exceptions by introducing
two new concepts:

- A new MCID flag "mayRaiseFPException" that the target should set on any
  instruction that possibly can raise FP exception according to the
  architecture definition.
- A new MI flag FPExcept that CodeGen/SelectionDAG will set on any MI
  instruction resulting from expansion of any constrained FP intrinsic.

Any MI instruction that is *both* marked as mayRaiseFPException *and*
FPExcept then needs to be considered as raising exceptions by MI-level
codegen (e.g. scheduling).

Setting those two new flags is straightforward. The mayRaiseFPException
flag is simply set via TableGen by marking all relevant instruction
patterns in the .td files.

The FPExcept flag is set in SDNodeFlags when creating the STRICT_ nodes
in the SelectionDAG, and gets inherited in the MachineSDNode nodes created
from it during instruction selection. The flag is then transfered to an
MIFlag when creating the MI from the MachineSDNode. This is handled just
like fast-math flags like no-nans are handled today.

This patch includes both common code changes required to implement the
new features, and the SystemZ implementation.

Reviewed By: andrew.w.kaylor

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

llvm-svn: 362663

This reverts commit r362435 as this triggers ICE, see PR42129 for details.

llvm-svn: 362662

Since the beginning, the offset of a frame index has been consistently
interpreted backwards. It was treating it as an offset from the
scratch wave offset register as a frame register. The correct
interpretation is the offset from the SP on entry to the function,
before the prolog. Frame index elimination then should select either
SP or another register as an FP.

Treat the scratch wave offset on kernel entry as the pre-incremented
SP. Rely more heavily on the standard hasFP and frame pointer
elimination logic, and clean up the private reservation code. This
saves a copy in most callee functions.

The kernel prolog emission code is still kind of a mess relying on
checking the uses of physical registers, which I would prefer to
eliminate.

Currently selection directly emits MUBUF instructions, which require
using a reference to some register. Use the register chosen for SP,
and then ignore this later. This should probably be cleaned up to use
pseudos that don't refer to any specific base register until frame
index elimination.

Add a workaround for shaders using large numbers of SGPRs. I'm not
sure these cases were ever working correctly, since as far as I can
tell the logic for figuring out which SGPR is the scratch wave offset
doesn't match up with the shader input initialization in the shader
programming guide.

llvm-svn: 362661

Some tests require `TEST_WORKAROUND_CONSTEXPR_IMPLIES_NOEXCEPT`, but they
did not include the header that defines that macro.

Thanks to Michael Park for the patch.

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

llvm-svn: 362660

llvm-svn: 362659

Summary:
I'm planning to update the hashing logic to recognize their equivalence
in a subsequent change (D62644).

Reviewers: spatel

Reviewed By: spatel

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 362657

Summary:
This change only unifies the API previous API pair accepting
CallInst and InvokeInst, thus making it easier to refactor
inliner pass ode to CallBase. The implementation of the unified
API still relies on the CallSite implementation.

Reviewers: eraman, chandlerc, jdoerfert

Reviewed By: jdoerfert

Subscribers: jdoerfert, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 362656

llvm-svn: 362655

The AllConstant check needs to be moved out of the if/else if chain to
avoid a test regression. The "there is no SimplifyZExt" comment
puzzles me, since there is SimplifyCastInst. Additionally, the
Simplify* calls seem to not see the operand as constant, so this needs
to be tried if the simplify failed.

llvm-svn: 362653

LLVM IR recently added a Type parameter to the byval Attribute, so that
when pointers become opaque and no longer have an element type the
information will still be present in IR.

For now the Type parameter is optional (which is why Clang didn't need
this change at the time), but it will become mandatory soon.

llvm-svn: 362652