[PowerPC] Manually schedule the prologue and epilogue

This patch makes the following changes to the schedule of instructions in the
prologue and epilogue.

The stack pointer update is moved down in

[PowerPC] Manually schedule the prologue and epilogue

This patch makes the following changes to the schedule of instructions in the
prologue and epilogue.

The stack pointer update is moved down in the prologue so that the callee saves
do not have to wait for the update to happen.
Saving the lr is moved down in the prologue to hide the latency of the mflr.
The stack pointer is moved up in the epilogue so that restoring of the lr can
happen sooner.
The mtlr is moved up in the epilogue so that it is away form the blr at the end
of the epilogue. The latency of the mtlr can now be hidden by the loads of the
callee saved registers.

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

llvm-svn: 322036

show more ...

[PowerPC] Added an assert to make sure that the MBBI iterator is valid.

The function createTailCallBranchInstr assumes that the iterator MBBI is valid.
However, only one use of MBBI is guarded in th

[PowerPC] Added an assert to make sure that the MBBI iterator is valid.

The function createTailCallBranchInstr assumes that the iterator MBBI is valid.
However, only one use of MBBI is guarded in the function.
Fix this by adding an assert.

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

llvm-svn: 321205

show more ...

MachineFunction: Return reference from getFunction(); NFC

The Function can never be nullptr so we can return a reference.

llvm-svn: 320884

Add iterator range MachineRegisterInfo::liveins(), adopt users, NFC

llvm-svn: 315927

Add "Restored" flag to CalleeSavedInfo

The liveness-tracking code assumes that the registers that were saved
in the function's prolog are live outside of the function. Specifically,
that registers t

Add "Restored" flag to CalleeSavedInfo

The liveness-tracking code assumes that the registers that were saved
in the function's prolog are live outside of the function. Specifically,
that registers that were saved are also live-on-exit from the function.
This isn't always the case as illustrated by the LR register on ARM.

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

llvm-svn: 310619

show more ...

[PPC] Fix two bugs in frame lowering.

1. The available program storage region of the red zone to compilers is 288
bytes rather than 244 bytes.
2. The formula for negative number alignment calculati

[PPC] Fix two bugs in frame lowering.

1. The available program storage region of the red zone to compilers is 288
bytes rather than 244 bytes.
2. The formula for negative number alignment calculation should be
y = x & ~(n-1) rather than y = (x + (n-1)) & ~(n-1).

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

llvm-svn: 307672

show more ...

[PowerPC] fix potential verification errors

This patch fixes trivial mishandling of 32-bit/64-bit instructions that may cause verification errors with -verify-machineinstrs.

llvm-svn: 305984

[PPC] Properly update register save area offsets

The variables MinGPR/MinG8R were not updated properly when resetting the
offsets, which in the included testcase lead to saving the CR register
in th

[PPC] Properly update register save area offsets

The variables MinGPR/MinG8R were not updated properly when resetting the
offsets, which in the included testcase lead to saving the CR register
in the same location as R30.

This fixes another issue reported in PR26519.

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

llvm-svn: 303257

show more ...

[PPC] When restoring R30 (PIC base pointer), mark it as <def>

This happened on the PPC32/SVR4 path and was discovered when building
FreeBSD on PPC32. It was a typo-class error in the frame lowering

[PPC] When restoring R30 (PIC base pointer), mark it as <def>

This happened on the PPC32/SVR4 path and was discovered when building
FreeBSD on PPC32. It was a typo-class error in the frame lowering code.

This fixes PR26519.

llvm-svn: 302183

show more ...

Move size and alignment information of regclass to TargetRegisterInfo

1. RegisterClass::getSize() is split into two functions:
- TargetRegisterInfo::getRegSizeInBits(const TargetRegisterClass &RC

Move size and alignment information of regclass to TargetRegisterInfo

1. RegisterClass::getSize() is split into two functions:
- TargetRegisterInfo::getRegSizeInBits(const TargetRegisterClass &RC) const;
- TargetRegisterInfo::getSpillSize(const TargetRegisterClass &RC) const;
2. RegisterClass::getAlignment() is replaced by:
- TargetRegisterInfo::getSpillAlignment(const TargetRegisterClass &RC) const;

This will allow making those values depend on subtarget features in the
future.

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

llvm-svn: 301221

show more ...

Remove a bunch of unnecessary casts to a target specific version of TII and TRI as we're working from a target specific STI.

llvm-svn: 294081

Move FrameInstructions from MachineModuleInfo to MachineFunction

This is per function data so it is better kept at the function instead
of the module.

This is a necessary step to have machine modul

Move FrameInstructions from MachineModuleInfo to MachineFunction

This is per function data so it is better kept at the function instead
of the module.

This is a necessary step to have machine module passes work properly.

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

llvm-svn: 288291

show more ...

Fix comment typos. NFC.

Identified by Pedro Giffuni in PR27636.

llvm-svn: 287486

[PPC] Set SP after loading data from stack frame, if no red zone is present

Follow-up to r280705: Make sure that the SP is only restored after all data
is loaded from the stack frame, if there is no

[PPC] Set SP after loading data from stack frame, if no red zone is present

Follow-up to r280705: Make sure that the SP is only restored after all data
is loaded from the stack frame, if there is no red zone.

This completes the fix for https://llvm.org/bugs/show_bug.cgi?id=26519.

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

llvm-svn: 282174

show more ...

[PPC] Claim stack frame before storing into it, if no red zone is present

Unlike PPC64, PPC32/SVRV4 does not have red zone. In the absence of it
there is no guarantee that this part of the stack wi

[PPC] Claim stack frame before storing into it, if no red zone is present

Unlike PPC64, PPC32/SVRV4 does not have red zone. In the absence of it
there is no guarantee that this part of the stack will not be modified
by any interrupt. To avoid this, make sure to claim the stack frame first
before storing into it.

This fixes https://llvm.org/bugs/show_bug.cgi?id=26519.

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

llvm-svn: 280705

show more ...

[PowerPC] Don't spill the frame pointer twice

When a function contains something, such as inline asm, which explicitly
clobbers the register used as the frame pointer, don't spill it twice. If we
ne

[PowerPC] Don't spill the frame pointer twice

When a function contains something, such as inline asm, which explicitly
clobbers the register used as the frame pointer, don't spill it twice. If we
need a frame pointer, it will be saved/restored in the prologue/epilogue code.
Explicitly spilling it again will reuse the same spill slot used by the
prologue/epilogue code, thus clobbering the saved value. The same applies
to the base-pointer or PIC-base register.

Partially fixes PR26856. Thanks to Ulrich for his analysis and the small
inline-asm reproducer.

llvm-svn: 280188

show more ...

MachineFunction: Return reference for getFrameInfo(); NFC

getFrameInfo() never returns nullptr so we should use a reference
instead of a pointer.

llvm-svn: 277017

PowerPC: Avoid implicit iterator conversions, NFC

Avoid implicit conversions from MachineInstrBundleIterator to
MachineInstr* in the PowerPC backend, mainly by preferring MachineInstr&
over MachineI

PowerPC: Avoid implicit iterator conversions, NFC

Avoid implicit conversions from MachineInstrBundleIterator to
MachineInstr* in the PowerPC backend, mainly by preferring MachineInstr&
over MachineInstr* when a pointer isn't nullable and using range-based
for loops.

There was one piece of questionable code in PPCInstrInfo::AnalyzeBranch,
where a condition checked a pointer converted from an iterator for
nullptr. Since this case is impossible (moreover, the code above
guarantees that the iterator is valid), I removed the check when I
changed the pointer to a reference.

Despite that case, there should be no functionality change here.

llvm-svn: 276864

show more ...

[PowerPC] Set kill flag for scratch register when spilling the link register

This fixes PR 28526.

llvm-svn: 275603

Convert 2 more uses to shouldAssumeDSOLocal(). NFC.

llvm-svn: 274009

Run clang-tidy's performance-unnecessary-copy-initialization over LLVM.

No functionality change intended.

llvm-svn: 272516

[ppc64] fix bug in prologue that mfocrf's cr operand should be explict state instead of implicit

This fixes PR27414

Reviewers: kbarton mgrang tjablin

http://reviews.llvm.org/D19255

llvm-svn: 2676

[ppc64] fix bug in prologue that mfocrf's cr operand should be explict state instead of implicit

This fixes PR27414

Reviewers: kbarton mgrang tjablin

http://reviews.llvm.org/D19255

llvm-svn: 267660

show more ...

[PPC64] Use mfocrf in prologue when we only need to save 1 nonvolatile CR field

In the ELFv2 ABI, we are not required to save all CR fields. If only one
nonvolatile CR field is clobbered, use mfocrf

[PPC64] Use mfocrf in prologue when we only need to save 1 nonvolatile CR field

In the ELFv2 ABI, we are not required to save all CR fields. If only one
nonvolatile CR field is clobbered, use mfocrf instead of mfcr to
selectively save the field, because mfocrf has short latency compares to
mfcr.

Thanks Nemanja's invaluable hint!
Reviewers: nemanjai tjablin hfinkel kbarton

http://reviews.llvm.org/D17749

llvm-svn: 266038

show more ...

RegisterScavenger: Take a reference as enterBasicBlock() argument.

Make it obvious that the argument cannot be nullptr.
Remove an unnecessary nullptr check in initRegState.

llvm-svn: 265511

[PPC64] Bug fix: when enabling sibling-call-opt and shrink-wrapping, the tail call branch instruction might disappear

Bug Pattern:
# BB#0: # %entry
cmpldi 3

[PPC64] Bug fix: when enabling sibling-call-opt and shrink-wrapping, the tail call branch instruction might disappear

Bug Pattern:
# BB#0: # %entry
cmpldi 3, 0
beq- 0, .LBB0_2
# BB#1: # %exit
lwz 4, 0(3)
#TC_RETURNd8 LVComputationKind 0
.LBB0_2: # %cond.false
mflr 0
std 0, 16(1)
stdu 1, -96(1)
.Ltmp0:
.cfi_def_cfa_offset 96
.Ltmp1:
.cfi_offset lr, 16
bl __assert_fail
nop

The branch instruction for tail call return is not generated, because the
shrink-wrapping pass choosing a new Restore Point: %cond.false, so %exit
block is not sent to emitEpilogue, that's why the branch is not generated.

Thanks Kit's opinions!
Reviewers: nemanjai hfinkel tjablin kbarton

http://reviews.llvm.org/D17606

llvm-svn: 265112

show more ...