Merging r213960:
------------------------------------------------------------------------
r213960 | hfinkel | 2014-07-25 17:47:22 +0000 (Fri, 25 Jul 2014) | 3 lines

[PowerPC] Support TLS on PPC32/ELF

Patch by Justin Hibbits!
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223734 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r215793:
------------------------------------------------------------------------
r215793 | hfinkel | 2014-08-16 00:16:29 +0000 (Sat, 16 Aug 2014) | 9 lines

[PowerPC] Darwin byval arguments are not immutable

On PPC/Darwin, byval arguments occur at fixed stack offsets in the callee's
frame, but are not immutable -- the pointer value is directly available to the
higher-level code as the address of the argument, and the value of the byval
argument can be modified at the IR level.

This is necessary, but not sufficient, to fix PR20280. When PR20280 is fixed in
a follow-up commit, its test case will cover this change.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223735 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r214517:
------------------------------------------------------------------------
r214517 | uweigand | 2014-08-01 14:35:58 +0000 (Fri, 01 Aug 2014) | 8 lines

[PowerPC] PR20280 - Slots for byval parameters are not immutable

Found by inspection while looking at PR20280: code would mark slots
in the parameter save area where a byval parameter is passed as
"immutable".  This is not correct since code is allowed to modify
byval parameters in place in the parameter save area.


------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223736 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r216917:
------------------------------------------------------------------------
r216917 | samsonov | 2014-09-02 17:38:34 +0000 (Tue, 02 Sep 2014) | 4 lines

Fix signed integer overflow in PPCInstPrinter.

This bug was reported by UBSan.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223738 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r217993:
------------------------------------------------------------------------
r217993 | sfantao | 2014-09-17 23:25:06 +0000 (Wed, 17 Sep 2014) | 5 lines

Fix FastISel bug in boolean returns for PowerPC.

For PPC targets, FastISel does not take the sign extension information into account when selecting return instructions whose operands are constants. A consequence of this is that the return of boolean values is not correct. This patch fixes the problem by evaluating the sign extension information also for constants, forwarding this information to PPCMaterializeInt which takes this information to drive the sign extension during the materialization. 


------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223739 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r219441:
------------------------------------------------------------------------
r219441 | sfantao | 2014-10-09 20:42:56 +0000 (Thu, 09 Oct 2014) | 3 lines

Fix bug in GPR to FPR moves in PPC64LE.

The current implementation of GPR->FPR register moves uses a stack slot. This mechanism writes a double word and reads a word. In big-endian the load address must be displaced by 4-bytes in order to get the right value. In little endian this is no longer required. This patch fixes the issue and adds LE regression tests to fast-isel-conversion which currently expose this problem.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223740 91177308-0d34-0410-b5e6-96231b3b80d8
Merging rr220959:
------------------------------------------------------------------------
r220959 | uweigand | 2014-10-31 10:33:14 +0000 (Fri, 31 Oct 2014) | 13 lines

[PowerPC] Load BlockAddress values from the TOC in 64-bit SVR4 code

Since block address values can be larger than 2GB in 64-bit code, they
cannot be loaded simply using an @l / @ha pair, but instead must be
loaded from the TOC, just like GlobalAddress, ConstantPool, and
JumpTable values are.

The commit also fixes a bug in PPCLinuxAsmPrinter::doFinalization where
temporary labels could not be used as TOC values, since code would
attempt (and fail) to use GetOrCreateSymbol to create a symbol of the
same name as the temporary label.


------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223741 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r221703:
------------------------------------------------------------------------
r221703 | wschmidt | 2014-11-11 20:44:09 +0000 (Tue, 11 Nov 2014) | 48 lines

[PowerPC] Replace foul hackery with real calls to __tls_get_addr

My original support for the general dynamic and local dynamic TLS
models contained some fairly obtuse hacks to generate calls to
__tls_get_addr when lowering a TargetGlobalAddress.  Rather than
generating real calls, special GET_TLS_ADDR nodes were used to wrap
the calls and only reveal them at assembly time.  I attempted to
provide correct parameter and return values by chaining CopyToReg and
CopyFromReg nodes onto the GET_TLS_ADDR nodes, but this was also not
fully correct.  Problems were seen with two back-to-back stores to TLS
variables, where the call sequences ended up overlapping with unhappy
results.  Additionally, since these weren't real calls, the proper
register side effects of a call were not recorded, so clobbered values
were kept live across the calls.

The proper thing to do is to lower these into calls in the first
place.  This is relatively straightforward; see the changes to
PPCTargetLowering::LowerGlobalTLSAddress() in PPCISelLowering.cpp.
The changes here are standard call lowering, except that we need to
track the fact that these calls will require a relocation.  This is
done by adding a machine operand flag of MO_TLSLD or MO_TLSGD to the
TargetGlobalAddress operand that appears earlier in the sequence.

The calls to LowerCallTo() eventually find their way to
LowerCall_64SVR4() or LowerCall_32SVR4(), which call FinishCall(),
which calls PrepareCall().  In PrepareCall(), we detect the calls to
__tls_get_addr and immediately snag the TargetGlobalTLSAddress with
the annotated relocation information.  This becomes an extra operand
on the call following the callee, which is expected for nodes of type
tlscall.  We change the call opcode to CALL_TLS for this case.  Back
in FinishCall(), we change it again to CALL_NOP_TLS for 64-bit only,
since we require a TOC-restore nop following the call for the 64-bit
ABIs.

During selection, patterns in PPCInstrInfo.td and PPCInstr64Bit.td
convert the CALL_TLS nodes into BL_TLS nodes, and convert the
CALL_NOP_TLS nodes into BL8_NOP_TLS nodes.  This replaces the code
removed from PPCAsmPrinter.cpp, as the BL_TLS or BL8_NOP_TLS
nodes can now be emitted normally using their patterns and the
associated printTLSCall print method.

Finally, as a result of these changes, all references to get-tls-addr
in its various guises are no longer used, so they have been removed.

There are existing TLS tests to verify the changes haven't messed
anything up).  I've added one new test that verifies that the problem
with the original code has been fixed.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223742 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r222672:
------------------------------------------------------------------------
r222672 | uweigand | 2014-11-24 18:09:47 +0000 (Mon, 24 Nov 2014) | 10 lines

[PowerPC] Fix PR 21652 - copy st_other bits on symbol assignment

When processing an assignment in the integrated assembler that sets
a symbol to the value of another symbol, we need to copy the st_other
bits that encode the local entry point offset.

Modeled after MipsTargetELFStreamer::emitAssignment handling of the
ELF::STO_MIPS_MICROMIPS flag.


------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223743 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r222996:
------------------------------------------------------------------------
r222996 | foad | 2014-12-01 09:42:32 +0000 (Mon, 01 Dec 2014) | 19 lines

[PowerPC] Fix unwind info with dynamic stack realignment

Summary:
PowerPC DWARF unwind info defined CFA as SP + offset even in a function
where the stack had been dynamically realigned. This clearly doesn't
work because the offset from SP to CFA is not a constant. Fix it by
defining CFA as BP instead.

This was causing the AddressSanitizer null_deref test to fail 50% of
the time, depending on whether SP happened to be 32-byte aligned on
entry to a particular function or not.

Reviewers: willschm, uweigand, hfinkel

Reviewed By: hfinkel

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D6410
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223744 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r223220:
------------------------------------------------------------------------
r223220 | hfinkel | 2014-12-03 09:37:50 +0000 (Wed, 03 Dec 2014) | 23 lines

[PowerPC] Print all inline-asm consts as signed numbers

Almost all immediates in PowerPC assembly (both 32-bit and 64-bit) are signed
numbers, and it is important that we print them as such. To make sure that
happens, we change PPCTargetLowering::LowerAsmOperandForConstraint so that it
does all intermediate checks on a signed-extended int64_t value, and then
creates the resulting target constant using MVT::i64. This will ensure that all
negative values are printed as negative values (mirroring what is done in other
backends to achieve the same sign-extension effect).

This came up in the context of inline assembly like this:
  "add%I2   %0,%0,%2", ..., "Ir"(-1ll)
where we used to print:
  addi   3,3,4294967295
and gcc would print:
  addi   3,3,-1
and gas accepts both forms, but our builtin assembler (correctly) does not. Now
we print -1 like gcc does.

While here, I replaced a bunch of custom integer checks with isInt<16> and
friends from MathExtras.h.

Thanks to Paul Hargrove for the bug report.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223745 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r223318:
------------------------------------------------------------------------
r223318 | hfinkel | 2014-12-03 23:40:13 +0000 (Wed, 03 Dec 2014) | 12 lines

[PowerPC] Fix inline asm memory operands not to use r0

On PowerPC, inline asm memory operands might be expanded as 0($r), where $r is
a register containing the address. As a result, this register cannot be r0, and
we need to enforce this register subclass constraint to prevent miscompiling
the code (we'd get this constraint for free with the usual instruction
definitions, but that scheme has no knowledge of how we end up printing inline
asm memory operands, and so here we need to do it 'by hand'). We can accomplish
this within the current address-mode selection framework by introducing an
explicit COPY_TO_REGCLASS node.

Fixes PR21443.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223746 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r223328:
------------------------------------------------------------------------
r223328 | hfinkel | 2014-12-04 00:46:20 +0000 (Thu, 04 Dec 2014) | 8 lines

[PowerPC] 'cc' should be an alias only to 'cr0'

We had mistakenly believed that GCC's 'cc' referred to the entire
condition-code register (cr0 through cr7) -- and implemented this in r205630 to
fix PR19326, but 'cc' is actually an alias only to 'cr0'. This is causing LLVM
to clobber too much with legacy code with inline asm using the 'cc' clobber.

Fixes PR21451.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223747 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r223708:
------------------------------------------------------------------------
r223708 | hfinkel | 2014-12-08 22:54:22 +0000 (Mon, 08 Dec 2014) | 13 lines

[PowerPC] Don't use a non-allocatable register to implement the 'cc' alias

GCC accepts 'cc' as an alias for 'cr0', and we need to do the same when
processing inline asm constraints. This had previously been implemented using a
non-allocatable register, named 'cc', that was listed as an alias of 'cr0', but
the infrastructure does not seem to support this properly (neither the register
allocator nor the scheduler properly accounts for the alias). Instead, we can
just process this as a naming alias inside of the inline asm
constraint-processing code, so we'll do that instead.

There are two regression tests, one where the post-RA scheduler did the wrong
thing with the non-allocatable alias, and one where the register allocator did
the wrong thing. Fixes PR21742.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223748 91177308-0d34-0410-b5e6-96231b3b80d8
Fixup backport of r223318

TM.getSubtargetImpl()->getRegisterInfo() needs to be TM.getRegisterInfo() in 3.5.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223749 91177308-0d34-0410-b5e6-96231b3b80d8