R600: Fix encoding for R600 family GPUs

Reviewed-by: Vincent Lejeune <vljn@ovi.com>
https://bugs.freedesktop.org/show_bug.cgi?id=64193
https://bugs.freedesktop.org/show_bug.cgi?id=64257
https://bugs.freedesktop.org/show_bug.cgi?id=64320

NOTE: This is a candidate for the 3.3 branch.

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

R600: Pass MCSubtargetInfo reference to R600CodeEmitter

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

[Sparc] Implements hasReservedCallFrame and hasFP.
 This is to generate correct framesetup code when the function
 has variable sized allocas.

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

X86: Make shuffle -> shift conversion more aggressive about undefs.

Shuffles that only move an element into position 0 of the vector are common in
the output of the loop vectorizer and often generate suboptimal code when SSSE3
is not available. Lower them to vector shifts if possible.

We still prefer palignr over psrldq because it has higher throughput on
sandybridge.

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

FileCheckize test.

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

LoopVectorize: Simplify code. No functionality change.

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

r182085 introduced a change that triggered an assertion on ARM. This is an immediate fix
which doesn't resolve the deeper problem.

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

[PowerPC] Fix hi/lo encoding in old-style code emitter

This patch implements the equivalent change to r182091/r182092
in the old-style code emitter.  Instead of having two separate
16-bit immediate encoding routines depending on the instruction,
this patch introduces a single encoder that checks the machine
operand flags to decide whether the low or high half of a
symbol address is required.

Since now both encoders make no further distinction between
"symbolLo" and "symbolHi", the .td operand can now use a
single getS16ImmEncoding method.

Tested by running the old-style JIT tests on 32-bit Linux.

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

[PowerPC] Merge/rename PPC fixup types

Now that fixup_ppc_ha16 and fixup_ppc_lo16 are being treated exactly
the same everywhere, it no longer makes sense to have two fixup types.

This patch merges them both into a single type fixup_ppc_half16,
and renames fixup_ppc_lo16_ds to fixup_ppc_half16ds for consistency.
(The half16 and half16ds names are taken from the description of
relocation types in the PowerPC ABI.)

No change in code generation expected.

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

[PowerPC] Fix processing of ha16/lo16 fixups

The current PowerPC MC back end distinguishes between fixup_ppc_ha16
and fixup_ppc_lo16, which are determined by the instruction the fixup
applies to, and uses this distinction to decide whether a fixup ought
to resolve to the high or the low part of a symbol address.

This isn't quite correct, however.  It is valid -if unusual- assembler
to use, e.g.
  li 1, symbol@ha
or
  lis 1, symbol@l
Whether the high or the low part of the address is used depends solely
on the @ suffix, not on the instruction.

In addition, both
  li 1, symbol
and
  lis 1, symbol
are valid, assuming the symbol address fits into 16 bits; again, both
will then refer to the actual symbol value (so li will load the value
itself, while lis will load the value shifted by 16).

To fix this, two places need to be adapted.  If the fixup cannot be
resolved at assembler time, a relocation needs to be emitted via
PPCELFObjectWriter::getRelocType.  This routine already looks at
the VK_ type to determine the relocation.  The only problem is that
will reject any _LO modifier in a ha16 fixup and vice versa.  This
is simply incorrect; any of those modifiers ought to be accepted
for either fixup type.

If the fixup *can* be resolved at assembler time, adjustFixupValue
currently selects the high bits of the symbol value if the fixup
type is ha16.  Again, this is incorrect; see the above example
  lis 1, symbol

Now, in theory we'd have to respect a VK_ modifier here.  However,
in fact common code never even attempts to resolve symbol references
using any nontrivial VK_ modifier at assembler time; it will always
fall back to emitting a reloc and letting the linker handle it.

If this ever changes, presumably there'd have to be a target callback
to resolve VK_ modifiers.  We'd then have to handle @ha etc. there.

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

Fix a typo (ouput => output)

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

Don't cast away constness.

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

Minor changes to the MCJITTest unittests to use the correct API for finalizing
the JIT object (including XFAIL an ARM test that now needs fixing). Also renames
internal function for consistency.

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

R600/SI: return undef instead of null for skipped arguments

This is a candidate for the stable branch.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=64694
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182084 91177308-0d34-0410-b5e6-96231b3b80d8

[Sparc] Prevent instructions that defines or uses %o7 to be in call's delay slot.

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

Generate debug info for by-value struct args even if they are not used.
radar://problem/13865940

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

llvm-objdump: Initialize MCDisassembler once instead of for each section.

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

[mips] Improve instruction selection for pattern (store (fp_to_sint $src), $ptr).

Previously, three instructions were needed:

trunc.w.s $f0, $f2
mfc1 $4, $f0
sw $4, 0($2)

Now we need only two:

trunc.w.s $f0, $f2
swc1 $f0, 0($2)

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

Remove addFrameMove.

Now that we have good testing, remove addFrameMove and create cfi
instructions directly.

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

More test coverage for addFrameMove.

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

[mips] Factor out unaligned store lowering code.

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

Fix cpu on test CodeGen/PowerPC/ctrloop-fp64.ll

We need ppc instead of generic to override native features on ppc machines.

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

Mips assembler: Add TwoOperandConstraint definitions

This patch removes alias definition for addiu $rs,$imm
and instead uses the TwoOperandAliasConstraint field in
the ArithLogicI instruction class.

This way all instructions that inherit ArithLogicI class
have the same macro defined.

The usage examples are added to test files.

Patch by Vladimir Medic

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

Mips td file formatting: white space and long lines

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

More addFrameMove test coverage.

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

Create an new preheader in PPCCTRLoops to avoid counter register clobbers

Some IR-level instructions (such as FP <-> i64 conversions) are not chained
w.r.t. the mtctr intrinsic and yet may become function calls that clobber the
counter register. At the selection-DAG level, these might be reordered with the
mtctr intrinsic causing miscompiles. To avoid this situation, if an existing
preheader has instructions that might use the counter register, create a new
preheader for the mtctr intrinsic. This extra block will be remerged with the
old preheader at the MI level, but will prevent unwanted reordering at the
selection-DAG level.

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

[mips] Test case for r182042. Add comment.

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

[mips] Fix instruction selection pattern for sint_to_fp node to avoid emitting an
invalid instruction sequence.

Rather than emitting an int-to-FP move instruction and an int-to-FP conversion
instruction during instruction selection, we emit a pseudo instruction which gets
expanded post-RA. Without this change, register allocation can possibly insert a
floating point register move instruction between the two instructions, which is not
valid according to the ISA manual.

mtc1 $f4, $4         # int-to-fp move instruction.
mov.s $f2, $f4       # move contents of $f4 to $f2.
cvt.s.w $f0, $f2     # int-to-fp conversion.

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

More test coverage for addFrameMove.

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

Mips assembler: Add branch macro definitions

This patch adds bnez and beqz instructions which represent alias definitions for bne and beq instructions as follows:
bnez $rs,$imm => bne $rs,$zero,$imm
beqz $rs,$imm => beq $rs,$zero,$imm

The corresponding test cases are added.

Patch by Vladimir Medic

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

DAGCombine: Also shrink eq compares where the constant is exactly as large as the smaller type.

if ((x & 255) == 255)

before: movzbl  %al, %eax
        cmpl  $255, %eax

after:  cmpb  $-1, %al

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

[mips] Fix indentation.

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

[mips] Delete unused enum value.

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

Add TargetRegisterInfo::getCoveringLanes().

This lane mask provides information about which register lanes
completely cover super-registers. See the block comment before
getCoveringLanes().

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

[PowerPC] Use true offset value in "memrix" machine operands

This is the second part of the change to always return "true"
offset values from getPreIndexedAddressParts, tackling the
case of "memrix" type operands.

This is about instructions like LD/STD that only have a 14-bit
field to encode immediate offsets, which are implicitly extended
by two zero bits by the machine, so that in effect we can access
16-bit offsets as long as they are a multiple of 4.

The PowerPC back end currently handles such instructions by
carrying the 14-bit value (as it will get encoded into the
actual machine instructions) in the machine operand fields
for such instructions.  This means that those values are
in fact not the true offset, but rather the offset divided
by 4 (and then truncated to an unsigned 14-bit value).

Like in the case fixed in r182012, this makes common code
operations on such offset values not work as expected.
Furthermore, there doesn't really appear to be any strong
reason why we should encode machine operands this way.

This patch therefore changes the encoding of "memrix" type
machine operands to simply contain the "true" offset value
as a signed immediate value, while enforcing the rules that
it must fit in a 16-bit signed value and must also be a
multiple of 4.

This change must be made simultaneously in all places that
access machine operands of this type.  However, just about
all those changes make the code simpler; in many cases we
can now just share the same code for memri and memrix
operands.

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

PPC32 cannot form counter loops around i64 FP conversions

On PPC32, i64 FP conversions are implemented using runtime calls (which clobber
the counter register). These must be excluded.

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

Add a triple to the test to try to fix the windows bots.

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

More addFrameMove test coverage.

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

Use new CHECK-DAG support to stabilize CodeGen/PowerPC/recipest.ll

While testing some experimental code to add vector-scalar registers to
PowerPC, I noticed that a couple of independent instructions were
flipped by the scheduler.  The new CHECK-DAG support is perfect for
avoiding this problem.

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

Add more addFrameMove test coverage.

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

Fixing a 64-bit conversion warning in MSVC.

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

Add more test coverage for addFrameMove.

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

Remove dead calls to addFrameMove.

Without a PROLOG_LABEL present, the cfi instructions are never printed.

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

[PowerPC] Report true displacement value from getPreIndexedAddressParts

DAGCombiner::CombineToPreIndexedLoadStore calls a target routine to
decompose a memory address into a base/offset pair.  It expects the
offset (if constant) to be the true displacement value in order to
perform optional additional optimizations; in particular, to convert
other uses of the original pointer into uses of the new base pointer
after pre-increment.

The PowerPC implementation of getPreIndexedAddressParts, however,
simply calls SelectAddressRegImm, which returns a TargetConstant.
This value is appropriate for encoding into the instruction, but
it is not always usable as true displacement value:

- Its type is always MVT::i32, even on 64-bit, where addresses
  ought to be i64 ... this causes the optimization to simply
  always fail on 64-bit due to this line in DAGCombiner:

      // FIXME: In some cases, we can be smarter about this.
      if (Op1.getValueType() != Offset.getValueType()) {

- Its value is truncated to an unsigned 16-bit value if negative.
  This causes the above opimization to generate wrong code.

This patch fixes both problems by simply returning the true
displacement value (in its original type).  This doesn't
affect any other user of the displacement.

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

Add more addFrameMove test coverage.

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

Extend test to check the .cfi instructions.

I am about to refactor the calls to addFrameMove and some of the ppc
ones were not being tested.

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

[SystemZ] Tweak register array comment

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

Relax CHECK-NEXTs a bit to cope with atom's return nop padding.

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

[msan] Switch TLS globals to initial-exec model.

They are always defined in the main executable.

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

Removed unused variable, detected by gcc
-Wunused-but-set-variable. Leftover from r181979.

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

Delete dead code.

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

Don't call addFrameMove on XCore.

getExceptionHandlingType is not ExceptionHandling::DwarfCFI on xcore, so
etFrameInstructions is never called. There is no point creating cfi
instructions if they are never used.

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

Respect the 'nobuiltin' attribute when determining if a call is to a memory builtin.

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

Extend test for better coverage.

Without this change nothing was covering this addFrameMove:

// For 64-bit SVR4 when we have spilled CRs, the spill location
// is SP+8, not a frame-relative slot.
if (Subtarget.isSVR4ABI()
    && Subtarget.isPPC64()
    && (PPC::CR2 <= Reg && Reg <= PPC::CR4)) {
  MachineLocation CSDst(PPC::X1, 8);
  MachineLocation CSSrc(PPC::CR2);
  MMI.addFrameMove(Label, CSDst, CSSrc);
  continue;
}

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

Removed dead code.

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

Fix PBQP graph iterator typedefs.

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

Patch number 2 for mips16/32 floating point interoperability stubs.
This creates stubs that help Mips32 functions call Mips16
functions which have floating point parameters that are normally passed
in floating point registers.

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

Revert "Support unaligned load/store on more ARM targets"

This reverts r181898.

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

Remove dead code.

This method is not being used/tested anywhere.

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

LoopVectorize: Move call of canHoistAllLoads to canVectorizeWithIfConvert

We only want to check this once, not for every conditional block in the loop.

No functionality change (except that we don't perform a check redudantly
anymore).

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

Delete dead code.

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

Set an explicit triple for this test.

This allows the test to correctly check symbol names.

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

undef setjmp in PPCCTRLoops

Trying to unbreak the VS build by copying some undef code from
Utils/LowerInvoke.cpp.

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

X86: Remove redundant test instructions

Increase the number of instructions LLVM recognizes as setting the ZF
flag. This allows us to remove test instructions that redundantly
recalculate the flag.

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

Use proper syntax.

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

Implement PPC counter loops as a late IR-level pass

The old PPCCTRLoops pass, like the Hexagon pass version from which it was
derived, could only handle some simple loops in canonical form. We cannot
directly adapt the new Hexagon hardware loops pass, however, because the
Hexagon pass contains a fundamental assumption that non-constant-trip-count
loops will contain a guard, and this is not always true (the result being that
incorrect negative counts can be generated). With this commit, we replace the
pass with a late IR-level pass which makes use of SE to calculate the
backedge-taken counts and safely generate the loop-count expressions (including
any necessary max() parts). This IR level pass inserts custom intrinsics that
are lowered into the desired decrement-and-branch instructions.

The most fragile part of this new implementation is that interfering uses of
the counter register must be detected on the IR level (and, on PPC, this also
includes any indirect branches in addition to function calls). Also, to make
all of this work, we need a variant of the mtctr instruction that is marked
as having side effects. Without this, machine-code level CSE, DCE, etc.
illegally transform the resulting code. Hopefully, this can be improved
in the future.

This new pass is smaller than the original (and much smaller than the new
Hexagon hardware loops pass), and can handle many additional cases correctly.
In addition, the preheader-creation code has been copied from LoopSimplify, and
after we decide on where it belongs, this code will be refactored so that it
can be explicitly shared (making this implementation even smaller).

The new test-case files ctrloop-{le,lt,ne}.ll have been adapted from tests for
the new Hexagon pass. There are a few classes of loops that this pass does not
transform (noted by FIXMEs in the files), but these deficiencies can be
addressed within the SE infrastructure (thus helping many other passes as well).

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

Fix legalization of SETCC with promoted integer intrinsics

If the input operands to SETCC are promoted, we need to make sure that we
either use the promoted form of both operands (or neither); a mixture is not
allowed. This can happen, for example, if a target has a custom promoted
i1-returning intrinsic (where i1 is not a legal type). In this case, we need to
use the promoted form of both operands.

This change only augments the behavior of the existing logic in the case where
the input types (which may or may not have already been legalized) disagree,
and should not affect existing target code because this case would otherwise
cause an assert in the SETCC operand promotion code.

This will be covered by (essentially all of the) tests for the new PPCCTRLoops
infrastructure.

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

Add lldb and polly to the projects to tag.

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

Fix miscompile due to StackColoring incorrectly merging stack slots (PR15707)

IR optimisation passes can result in a basic block that contains:

  llvm.lifetime.start(%buf)
  ...
  llvm.lifetime.end(%buf)
  ...
  llvm.lifetime.start(%buf)

Before this change, calculateLiveIntervals() was ignoring the second
lifetime.start() and was regarding %buf as being dead from the
lifetime.end() through to the end of the basic block.  This can cause
StackColoring to incorrectly merge %buf with another stack slot.

Fix by removing the incorrect Starts[pos].isValid() and
Finishes[pos].isValid() checks.

Just doing:
      Starts[pos] = Indexes->getMBBStartIdx(MBB);
      Finishes[pos] = Indexes->getMBBEndIdx(MBB);
unconditionally would be enough to fix the bug, but it causes some
test failures due to stack slots not being merged when they were
before.  So, in order to keep the existing tests passing, treat LiveIn
and LiveOut separately rather than approximating the live ranges by
merging LiveIn and LiveOut.

This fixes PR15707.
Patch by Mark Seaborn.

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

Cleanup relocation sorting for ELF.

We want the order to be deterministic on all platforms. NAKAMURA Takumi
fixed that in r181864. This patch is just two small cleanups:

* Move the function to the cpp file. It is only passed to array_pod_sort.
* Remove the ppc implementation which is now redundant

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

PPCISelLowering.h: Escape \@ in comments. [-Wdocumentation]

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

Whitespace.

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

[objc-arc] Fixed a spelling error and made the statistic descriptions be consistent about their usage of periods.

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

Add missing #include

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

Support unaligned load/store on more ARM targets

This patch matches GCC behavior: the code used to only allow unaligned
load/store on ARM for v6+ Darwin, it will now allow unaligned load/store for
v6+ Darwin as well as for v7+ on other targets.

The distinction is made because v6 doesn't guarantee support (but LLVM assumes
that Apple controls hardware+kernel and therefore have conformant v6 CPUs),
whereas v7 does provide this guarantee (and Linux behaves sanely).

Overall this should slightly improve performance in most cases because of
reduced I$ pressure.

Patch by JF Bastien

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

Remove MCELFObjectTargetWriter::adjustFixupOffset hack

Now that PowerPC no longer uses adjustFixupOffset, and no other
back-end (ever?) did, we can remove the infrastructure itself
(incidentally addressing a FIXME to that effect).

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

[PowerPC] Remove need for adjustFixupOffst hack

Now that applyFixup understands differently-sized fixups, we can define
fixup_ppc_lo16/fixup_ppc_lo16_ds/fixup_ppc_ha16 to properly be 2-byte
fixups, applied at an offset of 2 relative to the start of the
instruction text.

This has the benefit that if we actually need to generate a real
relocation record, its address will come out correctly automatically,
without having to fiddle with the offset in adjustFixupOffset.

Tested on both 64-bit and 32-bit PowerPC, using external and
integrated assembler.

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

[SystemZ] Make use of SUBTRACT HALFWORD

Thanks to Ulrich Weigand for noticing that this instruction was missing.

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

[PowerPC] Add test case for r181891

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

[PowerPC] Correctly handle fixups of other than 4 byte size

The PPCAsmBackend::applyFixup routine handles the case where a
fixup can be resolved within the same object file.  However,
this routine is currently hard-coded to assume the size of
any fixup is always exactly 4 bytes.

This is sort-of correct for fixups on instruction text; even
though it only works because several of what really would be
2-byte fixups are presented as 4-byte fixups instead (requiring
another hack in PPCELFObjectWriter::adjustFixupOffset to clean
it up).

However, this assumption breaks down completely for fixups
on data, which legitimately can be of any size (1, 2, 4, or 8).

This patch makes applyFixup aware of fixups of varying sizes,
introducing a new helper routine getFixupKindNumBytes (along
the lines of what the ARM back end does).  Note that in order
to handle fixups of size 8, we also need to fix the return type
of adjustFixupValue to uint64_t to avoid truncation.

Tested on both 64-bit and 32-bit PowerPC, using external and
integrated assembler.

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

Add Jade to the list of external projects using LLVM in the release notes.

Patch by: Antoine Lorence <Antoine.Lorence@insa-rennes.fr>

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

[SystemZ] Add more future work items to the README

Based on an analysis by Ulrich Weigand.

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

[SystemZ] Consolidate disassembler tests for valid input into 2 big tests

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

[SystemZ] Consolidate assembler tests into 4 big tests

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

Fix build on Windows

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

Use only explicit bool conversion operators

BitVector/SmallBitVector::reference::operator bool remain implicit since
they model more exactly a bool, rather than something else that can be
boolean tested.

The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.

One behavior change (YAMLParser) was made, though no test case is
included as I'm not sure how to reach that code path. Essentially any
comparison of llvm::yaml::document_iterators would be invalid if neither
iterator was at the end.

This helped uncover a couple of bugs in Clang - test cases provided for
those in a separate commit along with similar changes to `operator bool`
instances in Clang.

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

ELFRelocationEntry::operator<(): Try to stabilize the order. r_offset was insufficient to sort Relocs.

It should fix llvm/test/CodeGen/ARM/ehabi-mc-compact-pr*.ll on some hosts.

  RELOCATION RECORDS FOR [.ARM.exidx]:
  0 R_ARM_PREL31 .text
  0 R_ARM_NONE __aeabi_unwind_cpp_pr0

FIXME: I am not sure of the directions of extra comparators, in Type and Index.
For now, they are different from the direction in r_offset.

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

LoopVectorize: Fix comments

No functionality change.

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

LoopVectorize: Hoist conditional loads if possible

InstCombine can be uncooperative to vectorization and sink loads into
conditional blocks. This prevents vectorization.

Undo this optimization if there are unconditional memory accesses to the same
addresses in the loop.

radar://13815763

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

Speed up Value::isUsedInBasicBlock() for long use lists.

This is expanding Ben's original heuristic for short basic blocks to
also work for longer basic blocks and huge use lists.

Scan the basic block and the use list in parallel, terminating the
search when the shorter list ends. In almost all cases, either the basic
block or the use list is short, and the function returns quickly.

In one crazy test case with very long use chains, CodeGenPrepare runs
400x faster. When compiling ARMDisassembler.cpp it is 5x faster.

<rdar://problem/13840497>

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

Fix two typo

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

ExceptionDemo: Corresponding to r181820, SectionMemoryManager should belong to RTDyldMemoryManager.

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

Object: Fix Mach-O relocation printing.

There were two problems that made llvm-objdump -r crash:
- for non-scattered relocations, the symbol/section index is actually in the
  (aptly named) symbolnum field.
- sections are 1-indexed.

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

ARM ISel: Don't create illegal types during LowerMUL

The transformation happening here is that we want to turn a
"mul(ext(X), ext(X))" into a "vmull(X, X)", stripping off the extension. We have
to make sure that X still has a valid vector type - possibly recreate an
extension to a smaller type. In case of a extload of a memory type smaller than
64 bit we used create a ext(load()). The problem with doing this - instead of
recreating an extload - is that an illegal type is exposed.

This patch fixes this by creating extloads instead of ext(load()) sequences.

Fixes PR15970.

radar://13871383

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

GlobalOpt: fix an issue where CXAAtExitFn points to a deleted function.

CXAAtExitFn was set outside a loop and before optimizations where functions
can be deleted. This patch will set CXAAtExitFn inside the loop and after
optimizations.

Seg fault when running LTO because of accesses to a deleted function.
rdar://problem/13838828

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

Revert previous patch, it's actually on under Wall.

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

Add -Wreorder to the list of C++ warnings.

This built clean with clang, but if we see false positives on the bots
then we'll revert and turn it into a compiler specific check.

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

Make getCompileUnit non-const and return the current DIE if it
happens to be a compile unit. Noticed on inspection and tested
via calling on a newly created compile unit. No functional change.

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

Add 'CHECK-DAG' support

Refer to 'FileCheck.rst'f for details of 'CHECK-DAG'.

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

Refactor string checking. No functionality change.

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