[llvm-build] Make Py3 compatible.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188424 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Assign a register class to the $vaddr operand for MIMG instructions

The previous code declared the operand as unknown:$vaddr, which made
it possible for scalar registers to be used instead of vector registers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188425 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Choose the correct MOV instruction for copying immediates

The instruction selector will now try to infer the destination register
so it can decided whether to use V_MOV_B32 or S_MOV_B32 when copying
immediates.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188426 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Lower BUILD_VECTOR to REG_SEQUENCE v2

Using REG_SEQUENCE for BUILD_VECTOR rather than a series of INSERT_SUBREG
instructions should make it easier for the register allocator to coalasce
unnecessary copies.

v2:
  - Use an SGPR register class if all the operands of BUILD_VECTOR are
    SGPRs.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188427 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Use i8 types for resource descriptors in tests

We switched from i32 to i8 types a while ago and the tests were never
updated.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188428 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Convert v16i8 resource descriptors to i128

Now that compute support is better on SI, we can't continue using v16i8
for descriptors since this is also a legal type in OpenCL.

This patch fixes numerous hangs with the piglit OpenCL test and since
we now use a target specific DAG node for LOAD_CONSTANT with the
correct MemOperandFlags, this should also fix:

https://bugs.freedesktop.org/show_bug.cgi?id=66805

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188429 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Replace v1i32 type with i32 in imageload and sample intrinsics

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188430 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Improve legalization of vector operations

This should fix hangs in the OpenCL piglit tests.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188431 91177308-0d34-0410-b5e6-96231b3b80d8
Track new virtual registers by register number.

Track new virtual registers by register number, rather than by the live
interval created for them. This is the first step in separating the
creation of new virtual registers and new live intervals.  Eventually
live intervals will be created and populated on demand after the virtual
registers have been created and used in instructions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188434 91177308-0d34-0410-b5e6-96231b3b80d8
Notify LiveRangeEdit of new virtual registers.

Add a delegate class to MachineRegisterInfo with a single virtual
function, MRI_NoteNewVirtualRegister(). Update LiveRangeEdit to inherit
from this delegate class and override the definition of the callback
with an implementation that tracks the newly created virtual registers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188435 91177308-0d34-0410-b5e6-96231b3b80d8
Add the MachineInstrSpan class.

MachineInstrSpan is initialized with a MachineBasicBlock::iterator,
and is intended to track which instructions are inserted before/after
that instruction from the time the MachineInstrSpan is created.

It provides a begin()/end() interface to walk the range of
instructions inserted around the initial instruction (including that
initial instruction).

It also provides a getInitial() interface to return the initial
iterator.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188436 91177308-0d34-0410-b5e6-96231b3b80d8
Auto-compute live intervals on demand.

When new virtual registers are created during splitting/spilling, defer
creation of the live interval until we need to use the live interval.

Along with the recent commits to notify LiveRangeEdit when new virtual
registers are created, this makes it possible for functions like
TargetInstrInfo::loadRegFromStackSlot() and
TargetInstrInfo::storeRegToStackSlot() to create multiple virtual
registers as part of the process of generating loads/stores for
different register classes, and then have the live intervals for those
new registers computed when they are needed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188437 91177308-0d34-0410-b5e6-96231b3b80d8
Replace getValueType().getSimpleVT() with getSimpleValueType(). Also remove one weird cast from MVT->EVT just to call getSimpleVT().

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188441 91177308-0d34-0410-b5e6-96231b3b80d8
Replace getValueType().getSimpleVT() with getSimpleValueType().

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188442 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed typo in CMakeLists.txt.

We were marking both LLVMBUILDOUTPUT and LLVMBUILDERRORS as
ERROR_VARIABLES when clearly LLVMBUILDOUTPUT should be marked as
OUTPUT_VARIABLE.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188444 91177308-0d34-0410-b5e6-96231b3b80d8
Use MVT in place of EVT in more X86 operation lowering functions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188445 91177308-0d34-0410-b5e6-96231b3b80d8
Use MVT instead of EVT in X86ISelDAGToDAG since all the types should be legal.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188446 91177308-0d34-0410-b5e6-96231b3b80d8
Tentative fix for global-buffer-overflow caused by r188426. Found by AddressSanitizer

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188448 91177308-0d34-0410-b5e6-96231b3b80d8
Don't let isPermImmMask handle v16i32 since VPERMI doesn't match on that type. Remove 128-bit vector handling from isPermImmMask too, it's covered by isPSHUFDMask.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188449 91177308-0d34-0410-b5e6-96231b3b80d8
Clang and AArch64 backend patches to support shll/shl and vmovl instructions and ACLE functions

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188451 91177308-0d34-0410-b5e6-96231b3b80d8