[ELF] Do not pass GOT section as an argument to handleARMTlsRelocation and handleMipsTlsRelocation functions. NFC

Both functions always use the same GOT sections In<ELFT>::Got and
In<ELFT>::MipsGot respectively, so we do not need to pass them as an
argument.

llvm-svn: 299773

Summary: [GlobalISel] implement narrowing for G_CONSTANT.

Reviewers: bogner, zvi, t.p.northover

Reviewed By: t.p.northover

Subscribers: llvm-commits, dberris, rovka, kristof.beyls

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

llvm-svn: 299772

Summary:
Fix a bug where we were inserting a spill in between the PHIs in the beginning of the block.
Consider this fragment:

```
begin:
  %phi1 = phi i32 [ 0, %entry ], [ 2, %alt ]
  %phi2 = phi i32 [ 1, %entry ], [ 3, %alt ]
  %sp1 = call i8 @llvm.coro.suspend(token none, i1 false)
  switch i8 %sp1, label %suspend [i8 0, label %resume
                                  i8 1, label %cleanup]
resume:
  call i32 @print(i32 %phi1)
```
Unless we are spilling the argument or result of the invoke, we were always inserting the spill immediately following the instruction.
The fix adds a check that if the spilled instruction is a PHI Node, select an appropriate insert point with `getFirstInsertionPt()` that
skips all the PHI Nodes and EH pads.

Reviewers: majnemer, rnk

Reviewed By: rnk

Subscribers: qcolombet, EricWF, llvm-commits

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

llvm-svn: 299771

This patch reapplies r298620. The original patch was reverted because of two
issues. First, the patch exposed a bug in InstCombine that caused the Chromium
builds to fail (PR32414). This issue was fixed in r299017. Second, the patch
introduced a bug in the vectorizer's scalars analysis that caused test suite
builds to fail on SystemZ. The scalars analysis was too aggressive and marked a
memory instruction scalar, even though it was going to be vectorized. This
issue has been fixed in the current patch and several new test cases for the
scalars analysis have been added.

llvm-svn: 299770

Fix the lld-x86_64-darwin13 buildbot by removing the declaration of a
debug only variable and instead moving the value into the debug statement.

llvm-svn: 299769

We have two cases here, the first one being the following instruction
selection from the builtin function:
bm(n)zi builtin -> vselect node -> bins[lr]i machine instruction

In case of bm(n)zi having an immediate which has either its high or low bits
set, a bins[lr] instruction can be selected through the selectVSplatMask[LR]
function. The function counts the number of bits set, and that value is
being passed to the bins[lr]i instruction as its immediate, which in turn
copies immediate modulo the size of the element in bits plus 1 as per specs,
where we get the off-by-one-error.

The other case is:
bins[lr]i -> vselect node -> bsel.v

In this case, a bsel.v instruction gets selected with a mask having one bit
less set than required.

Patch by Stefan Maksimovic.

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

llvm-svn: 299768

- corrected DS_GWS_* opcodes (see VI_Shader_Programming#16.pdf for detailed description)
  - address operand is not used
  - several opcodes have data operand
  - all opcodes have offset modifier
- DS_AND_SRC2_B32: corrected typo in mnemo
- DS_WRAP_RTN_F32 replaced with DS_WRAP_RTN_B32
- added CI/VI opcodes:
  - DS_CONDXCHG32_RTN_B64
  - DS_GWS_SEMA_RELEASE_ALL
- added VI opcodes:
  - DS_CONSUME
  - DS_APPEND
  - DS_ORDERED_COUNT

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

llvm-svn: 299767

By target hookifying getRegisterType, getNumRegisters, getVectorBreakdown,
backends can request that LLVM to scalarize vector types for calls
and returns.

The MIPS vector ABI requires that vector arguments and returns are passed in
integer registers. With SelectionDAG's new hooks, the MIPS backend can now
handle LLVM-IR with vector types in calls and returns. E.g.
'call @foo(<4 x i32> %4)'.

Previously these cases would be scalarized for the MIPS O32/N32/N64 ABI for
calls and returns if vector types were not legal. If vector types were legal,
a single 128bit vector argument would be assigned to a single 32 bit / 64 bit
integer register.

By teaching the MIPS backend to inspect the original types, it can now
implement the MIPS vector ABI which requires a particular method of
scalarizing vectors.

Previously, the MIPS backend relied on clang to scalarize types such as "call
@foo(<4 x float> %a) into "call @foo(i32 inreg %1, i32 inreg %2, i32 inreg %3,
i32 inreg %4)".

This patch enables the MIPS backend to take either form for vector types.

Reviewers: zoran.jovanovic, jaydeep, vkalintiris, slthakur

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

llvm-svn: 299766

llvm-svn: 299765

the test file.

llvm-svn: 299764

A test case was found with llvm-stress that caused DAGCombiner to crash
when compiling for an older subtarget without vector support.

SystemZTargetLowering::combineTruncateExtract() should do nothing for older
subtargets.

This check was placed in canTreatAsByteVector(), which also helps in a few
other places.

Review: Ulrich Weigand
llvm-svn: 299763

It isn't just one-element vectors that can appear here.

llvm-svn: 299762

It turns out -float-abi=hard doesn't set the hard float calling
convention for libcalls. We need to use a hard float triple instead
(e.g. gnueabihf).

llvm-svn: 299761

llvm-svn: 299760

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

llvm-svn: 299759

Patch contributed by stanionascu!

rfc8089#appendix-E.2 specifies that paths can begin with a drive letter e.g. as file:///c:/.
In this case just consuming front file:// is not enough and the 3rd slash must be consumed to produce a valid path on windows.

The patch introduce a generic way of converting an uri to a filesystem path and back.

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

llvm-svn: 299758

Summary:
Difference beetween PreRegAlloc() and MachineSSAOptimization() are that the former is run despite of -O0 optimization level. In my undestanding SiShrinkInstructions and SDWAPeephole shouldn't run when optimizations are disabled.
With this change order of passes will not change.

Reviewers: arsenm, vpykhtin, rampitec

Subscribers: qcolombet, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye

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

llvm-svn: 299757

Legalize to a libcall.

llvm-svn: 299756

This follows r299748 which fixed a latent bug the original commit exposed.

llvm-svn: 299755

Summary: When using the C preprocessor with assembly files, either with a
capital `S` file extension, or with `-xassembler-with-cpp`, the Unicode escape
sequence `\u` is ignored. The `\u` pattern can be used for expanding a macro
argument that starts with `u`.

Author: Salman Arif <salman.arif@arm.com>

Reviewers: rengolin, olista01

Reviewed By: olista01

Subscribers: cfe-commits

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

llvm-svn: 299754

Legalize to a libcall.
On this occasion, also start allowing soft float subtargets. For the
moment G_FREM is the only legal floating point operation for them.

llvm-svn: 299753

llvm-svn: 299752

    
When the target of the TlsOffsetRel is non-preemptible we can write the
offset directly into the GOT without needing a dynamic relocation. This
is optional for dynamically linked executables but is required for static
linking.
    
This change adds the relocation to the GOT entry and a test case for
non-0 offsets so that if we miss out the offset the test won't spuriously
pass by virtue of the default value being 0.

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

llvm-svn: 299751

    
The handleNoRelaxTlsRelocation handled both ARM and Mips as at a
high-level the actions of what to do when encountering a local dynamic or
global dynamic TLS relocation are the same. However due to Mips using a
custom GOT the differences of the implementation are enough that the
function became difficult to understand.
    
This change replaces handleNotRelaxTlsRelocation into
handleARMTlsRelocation() and handleMipsTlsRelocation() so that the ARM and
Mips specific code is isolated.

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

llvm-svn: 299750

lld-x86_64-darwin13.

llvm-svn: 299749

r299635 exposed a latent bug in the Linux implementation of parallel_for, which
resulted in it calling the function outside of the range requested, resulting
later in a segmentation fault. This change fixes this issue and adds a unit test.

llvm-svn: 299748

llvm-svn: 299747

llvm-svn: 299746

[InstSimplify] Use Instruction::BinaryOps instead of unsigned for a few function operands to remove some casts. NFC

llvm-svn: 299745

Revert "Allow a standard library to implement conditional noexcept for optional and unique_ptr hash functions."

This reverts commit r299734.

llvm-svn: 299744

LLVM dropped support for Visual Studio versions older than 2015 quite
some time ago, so I consider it safe to drop libc++'s support for older
CRTs. The CRT in Visual Studio 2015 provides a lot of previously missing
functions, so targeting it requires less special casing.

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

llvm-svn: 299743

The argument was always casted, so cast it in the caller.

llvm-svn: 299742

Summary:
getModRefInfo is meant to answer the question "what impact does this
instruction have on a given memory location" (not even another
instruction).

Long debate on this on IRC comes to the conclusion the answer should be "nothing special".

That is, a noalias volatile store does not affect a memory location
just by being volatile.  Note: DSE and GVN and memdep currently
believe this, because memdep just goes behind AA's back after it says
"modref" right now.

see line 635 of memdep. Prior to this patch we would get modref there, then check aliasing,
and if it said noalias, we would continue.

getModRefInfo *already* has this same AA check, it just wasn't being used because volatile was
lumped in with ordering.

(I am separately testing whether this code in memdep is now dead except for the invariant load case)

Reviewers: jyknight, chandlerc

Subscribers: llvm-commits

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

llvm-svn: 299741

llvm-svn: 299740

llvm-svn: 299739

For a function to be pickle-able, it has to be in the top-level of a
real Python module. So, I made one for this code snippet.

llvm-svn: 299738

llvm-svn: 299737

llvm-svn: 299736

llvm-svn: 299735

Allow a standard library to implement conditional noexcept for optional and unique_ptr hash functions.

These tests were unconditionally asserting that optional and unique_ptr declare throwing hashes, but MSVC++ implements conditional noexcept forwarding that of the underlying hash function. As a result we were failing these tests but there's nothing forbidding strengthening noexcept in that way.

Changed the ASSERT_NOT_NOEXCEPT asserts to use types which themselves have non-noexcept hash functions.

llvm-svn: 299734