[ARM] CodeGen: Remove AddDefaultCC. NFC.

Replace all uses of AddDefaultCC with add(condCodeOp()).
The transformation has been done automatically with a custom tool based on Clang
AST Matchers + Refa

[ARM] CodeGen: Remove AddDefaultCC. NFC.

Replace all uses of AddDefaultCC with add(condCodeOp()).
The transformation has been done automatically with a custom tool based on Clang
AST Matchers + RefactoringTool.

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

llvm-svn: 291893

show more ...

[ARM] CodeGen: Remove AddDefaultPred. NFC.

Replace all uses of AddDefaultPred with MachineInstrBuilder::add(predOps()).
This makes the code building MachineInstrs more readable, because it allows us

[ARM] CodeGen: Remove AddDefaultPred. NFC.

Replace all uses of AddDefaultPred with MachineInstrBuilder::add(predOps()).
This makes the code building MachineInstrs more readable, because it allows us
to write code like:

MIB.addSomeOperand(blah)
.add(predOps())
.addAnotherOperand(blahblah)

instead of

AddDefaultPred(MIB.addSomeOperand(blah))
.addAnotherOperand(blahblah)

This commit also adds the predOps helper in the ARM backend, as well as the add
method taking a variable number of operands to the MachineInstrBuilder.

The transformation has been done mostly automatically with a custom tool based
on Clang AST Matchers + RefactoringTool.

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

llvm-svn: 291890

show more ...

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 ...

ARM: try to fix GCC 4.8 compilation again after r286881.

llvm-svn: 286882

Recommit: ARM: sort register lists by encoding in push/pop instructions.

For example we were producing

push {r8, r10, r11, r4, r5, r7, lr}

This is misleading (r4, r5 and r7 are actually pushed

Recommit: ARM: sort register lists by encoding in push/pop instructions.

For example we were producing

push {r8, r10, r11, r4, r5, r7, lr}

This is misleading (r4, r5 and r7 are actually pushed before the rest), and
other components (stack folding recently) often forget to deal with the extra
complexity coming from the different order, leading to miscompiles. Finally, we
warn about our own code in -no-integrated-as mode without this, which is really
not a good idea.

Fixed usage of std::sort so that we (hopefully) use instantiations that
actually exist in GCC 4.8.

llvm-svn: 286881

show more ...

Revert "ARM: sort register lists by encoding in push/pop instructions."

This reverts commit 286866. It broke a bot, something to do with exactly which
templates std::sort accepts.

llvm-svn: 286867

ARM: sort register lists by encoding in push/pop instructions.

For example we were producing

push {r8, r10, r11, r4, r5, r7, lr}

This is misleading (r4, r5 and r7 are actually pushed before th

ARM: sort register lists by encoding in push/pop instructions.

For example we were producing

push {r8, r10, r11, r4, r5, r7, lr}

This is misleading (r4, r5 and r7 are actually pushed before the rest), and
other components (stack folding recently) often forget to deal with the extra
complexity coming from the different order, leading to miscompiles. Finally, we
warn about our own code in -no-integrated-as mode without this, which is really
not a good idea.

llvm-svn: 286866

show more ...

Re-land "[Thumb] Save/restore high registers in Thumb1 pro/epilogues"

Reverts r283938 to reinstate r283867 with a fix.

The original change had an ArrayRef referring to a destroyed temporary
initial

Re-land "[Thumb] Save/restore high registers in Thumb1 pro/epilogues"

Reverts r283938 to reinstate r283867 with a fix.

The original change had an ArrayRef referring to a destroyed temporary
initializer list. Use plain C arrays instead.

llvm-svn: 283942

show more ...

Revert "[Thumb] Save/restore high registers in Thumb1 pro/epilogues"

This reverts r283867.

This appears to be an infinite loop:

while (HiRegToSave != AllHighRegs.end() && CopyReg != AllCopyReg

Revert "[Thumb] Save/restore high registers in Thumb1 pro/epilogues"

This reverts r283867.

This appears to be an infinite loop:

while (HiRegToSave != AllHighRegs.end() && CopyReg != AllCopyRegs.end()) {
if (HiRegsToSave.count(*HiRegToSave)) {
...

CopyReg = findNextOrderedReg(++CopyReg, CopyRegs, AllCopyRegs.end());
HiRegToSave =
findNextOrderedReg(++HiRegToSave, HiRegsToSave, AllHighRegs.end());
}
}

llvm-svn: 283938

show more ...

Silence unused warning in non-assert builds.

llvm-svn: 283899

[Thumb] Save/restore high registers in Thumb1 pro/epilogues

The high registers are not allocatable in Thumb1 functions, but they
could still be used by inline assembly, so we need to save and restor

[Thumb] Save/restore high registers in Thumb1 pro/epilogues

The high registers are not allocatable in Thumb1 functions, but they
could still be used by inline assembly, so we need to save and restore
the callee-saved high registers (r8-r11) in the prologue and epilogue.

This is complicated by the fact that the Thumb1 push and pop
instructions cannot access these registers. Therefore, we have to move
them down into low registers before pushing, and move them back after
popping into low registers.

In most functions, we will have low registers that are also being
pushed/popped, which we can use as the temporary registers for
saving/restoring the high registers. However, this is not guaranteed, so
we may need to push some extra low registers to ensure that the high
registers can be saved/restored. For correctness, it would be sufficient
to use just one low register, but if we have enough low registers
available then we only need one push/pop instruction, rather than one
per high register.

We can also use the argument/return registers when they are not live,
and the link register when saving (but not restoring), reducing the
number of extra registers we need to push.

There are still a few extreme edge cases where we need two push/pop
instructions, because not enough low registers can be made live in the
prologue or epilogue.

In addition to the regression tests included here, I've also tested this
using a script to generate functions which clobber different
combinations of registers, have different numbers of argument and return
registers (including variadic arguments), allocate different fixed sized
objects on the stack, and do or don't use variable sized allocas and the
__builtin_return_address intrinsic (all of which affect the available
registers in the prologue and epilogue). I ran these functions in a test
harness which verifies that all of the callee-saved registers are
correctly preserved.

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

llvm-svn: 283867

show more ...

[ARM] Generate consistent frame records for Thumb2

There is not an official documented ABI for frame pointers in Thumb2,
but we should try to emit something which is useful.

We use r7 as the frame

[ARM] Generate consistent frame records for Thumb2

There is not an official documented ABI for frame pointers in Thumb2,
but we should try to emit something which is useful.

We use r7 as the frame pointer for Thumb code, which currently means
that if a function needs to save a high register (r8-r11), it will get
pushed to the stack between the frame pointer (r7) and link register
(r14). This means that while a stack unwinder can follow the chain of
frame pointers up the stack, it cannot know the offset to lr, so does
not know which functions correspond to the stack frames.

To fix this, we need to push the callee-saved registers in two batches,
with the first push saving the low registers, fp and lr, and the second
push saving the high registers. This is already implemented, but
previously only used for iOS. This patch turns it on for all Thumb2
targets when frame pointers are required by the ABI, and the frame
pointer is r7 (Windows uses r11, so this isn't a problem there). If
frame pointer elimination is enabled we still emit a single push/pop
even if we need a frame pointer for other reasons, to avoid increasing
code size.

We must also ensure that lr is pushed to the stack when using a frame
pointer, so that we end up with a complete frame record. Situations that
could cause this were rare, because we already push lr in most
situations so that we can return using the pop instruction.

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

llvm-svn: 279506

show more ...

ARM: Avoid dereferencing end() in ARMFrameLowering::emitEpilogue

This fixes the crash from PR29072, where the MachineBasicBlock::iterator
wasn't being properly checked against MachineBasicBlock::end

ARM: Avoid dereferencing end() in ARMFrameLowering::emitEpilogue

This fixes the crash from PR29072, where the MachineBasicBlock::iterator
wasn't being properly checked against MachineBasicBlock::end() before
iterating. This was another bug exposed by the new
ilist::iterator::operator*() assertion from r279314.

This testcase is poor quality. bugpoint couldn't reduce any further,
and I haven't had time to dig into what's going on so I can't invent a
better one. I didn't even get good CHECK lines in: this is just a
crasher.

I'm committing anyway since this is a real crash with an obvious fix,
but I'll leave PR29072 open and ask an ARM maintainer to help improve
the testcase.

llvm-svn: 279391

show more ...

Replace "fallthrough" comments with LLVM_FALLTHROUGH

This is a mechanical change of comments in switches like fallthrough,
fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead.

llvm

Replace "fallthrough" comments with LLVM_FALLTHROUGH

This is a mechanical change of comments in switches like fallthrough,
fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead.

llvm-svn: 278902

show more ...

ARM: Avoid dereferencing end() in ARMFrameLowering::emitPrologue

llvm::tryFoldSPUpdateIntoPushPop assumes its arguments are valid
MachineInstrs. Update ARMFrameLowering::emitPrologue to respect tha

ARM: Avoid dereferencing end() in ARMFrameLowering::emitPrologue

llvm::tryFoldSPUpdateIntoPushPop assumes its arguments are valid
MachineInstrs. Update ARMFrameLowering::emitPrologue to respect that;
when LastPush==end(), it can't possibly be a push instruction anyway.

llvm-svn: 278880

show more ...

Use the range variant of find_if instead of unpacking begin/end

No functionality change is intended.

llvm-svn: 278443

Use the range variant of find instead of unpacking begin/end

If the result of the find is only used to compare against end(), just
use is_contained instead.

No functionality change is intended.

ll

Use the range variant of find instead of unpacking begin/end

If the result of the find is only used to compare against end(), just
use is_contained instead.

No functionality change is intended.

llvm-svn: 278433

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

TargetInstrInfo: rename GetInstSizeInBytes to getInstSizeInBytes. NFC

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

llvm-svn: 276997

ARM: Remove implicit iterator conversions, NFC

Remove remaining implicit conversions from MachineInstrBundleIterator to
MachineInstr* from the ARM backend. In most cases, I made them less attractiv

ARM: Remove implicit iterator conversions, NFC

Remove remaining implicit conversions from MachineInstrBundleIterator to
MachineInstr* from the ARM backend. In most cases, I made them less attractive
by preferring MachineInstr& or using a ranged-based for loop.

Once all the backends are fixed I'll make the operator explicit so that this
doesn't bitrot back.

llvm-svn: 274920

show more ...

CodeGen: Use MachineInstr& in TargetInstrInfo, NFC

This is mostly a mechanical change to make TargetInstrInfo API take
MachineInstr& (instead of MachineInstr* or MachineBasicBlock::iterator)
when th

CodeGen: Use MachineInstr& in TargetInstrInfo, NFC

This is mostly a mechanical change to make TargetInstrInfo API take
MachineInstr& (instead of MachineInstr* or MachineBasicBlock::iterator)
when the argument is expected to be a valid MachineInstr. This is a
general API improvement.

Although it would be possible to do this one function at a time, that
would demand a quadratic amount of churn since many of these functions
call each other. Instead I've done everything as a block and just
updated what was necessary.

This is mostly mechanical fixes: adding and removing `*` and `&`
operators. The only non-mechanical change is to split
ARMBaseInstrInfo::getOperandLatencyImpl out from
ARMBaseInstrInfo::getOperandLatency. Previously, the latter took a
`MachineInstr*` which it updated to the instruction bundle leader; now,
the latter calls the former either with the same `MachineInstr&` or the
bundle leader.

As a side effect, this removes a bunch of MachineInstr* to
MachineBasicBlock::iterator implicit conversions, a necessary step
toward fixing PR26753.

Note: I updated WebAssembly, Lanai, and AVR (despite being
off-by-default) since it turned out to be easy. I couldn't run tests
for AVR since llc doesn't link with it turned on.

llvm-svn: 274189

show more ...

Pass DebugLoc and SDLoc by const ref.

This used to be free, copying and moving DebugLocs became expensive
after the metadata rewrite. Passing by reference eliminates a ton of
track/untrack operation

Pass DebugLoc and SDLoc by const ref.

This used to be free, copying and moving DebugLocs became expensive
after the metadata rewrite. Passing by reference eliminates a ton of
track/untrack operations. No functionality change intended.

llvm-svn: 272512

show more ...

ARM: use callee-saved list in the order they're actually saved.

When setting the frame pointer, the offset from SP is calculated based on the
stack slot it gets allocated, but this slot is in turn b

ARM: use callee-saved list in the order they're actually saved.

When setting the frame pointer, the offset from SP is calculated based on the
stack slot it gets allocated, but this slot is in turn based on the order of
the CSR list so that list should match the order we actually save the registers
in. Mostly it did, but in the edge-case of MachO AAPCS targets it was wrong.

llvm-svn: 269459

show more ...

[ARM] Fix Scavenger assert due to underestimated stack size

(re-apply r268810 as it exposed an uninitialized variable in ARM MFI.
Patch 268868 should fix that.)

Summary:
Currently, when checking i

[ARM] Fix Scavenger assert due to underestimated stack size

(re-apply r268810 as it exposed an uninitialized variable in ARM MFI.
Patch 268868 should fix that.)

Summary:
Currently, when checking if a stack is "BigStack" or not, it doesn't count into spills and arguments. Therefore, LLVM won't reserve spill slot for this actually "BigStack". This may cause scavenger failure.

Reviewers: rengolin

Subscribers: vitalybuka, aemerson, rengolin, tberghammer, danalbert, srhines, llvm-commits

Differential Revision: http://reviews.llvm.org/D19896

llvm-svn: 268869

show more ...

Revert r268810 becase it brakes msan bot.

16802==WARNING: MemorySanitizer: use-of-uninitialized-value
lib/Target/ARM/ARMFrameLowering.cpp:1632

llvm-svn: 268833