| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 281535
|
|
|
|
|
|
|
| |
analyzeBranch was renamed to use lowercase first, rename
the related set to match.
llvm-svn: 281506
|
|
|
|
|
|
|
|
|
| |
The main change is to return the code size from
InsertBranch/RemoveBranch.
Patch mostly by Tim Northover
llvm-svn: 281505
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that MachineBasicBlock::reverse_instr_iterator knows when it's at
the end (since r281168 and r281170), implement
MachineBasicBlock::reverse_iterator directly on top of an
ilist::reverse_iterator by adding an IsReverse template parameter to
MachineInstrBundleIterator. This replaces another hard-to-reason-about
use of std::reverse_iterator on list iterators, matching the changes for
ilist::reverse_iterator from r280032 (see the "out of scope" section at
the end of that commit message). MachineBasicBlock::reverse_iterator
now has a handle to the current node and has obvious invalidation
semantics.
r280032 has a more detailed explanation of how list-style reverse
iterators (invalidated when the pointed-at node is deleted) are
different from vector-style reverse iterators like std::reverse_iterator
(invalidated on every operation). A great motivating example is this
commit's changes to lib/CodeGen/DeadMachineInstructionElim.cpp.
Note: If your out-of-tree backend deletes instructions while iterating
on a MachineBasicBlock::reverse_iterator or converts between
MachineBasicBlock::iterator and MachineBasicBlock::reverse_iterator,
you'll need to update your code in similar ways to r280032. The
following table might help:
[Old] ==> [New]
delete &*RI, RE = end() delete &*RI++
RI->erase(), RE = end() RI++->erase()
reverse_iterator(I) std::prev(I).getReverse()
reverse_iterator(I) ++I.getReverse()
--reverse_iterator(I) I.getReverse()
reverse_iterator(std::next(I)) I.getReverse()
RI.base() std::prev(RI).getReverse()
RI.base() ++RI.getReverse()
--RI.base() RI.getReverse()
std::next(RI).base() RI.getReverse()
(For more details, have a look at r280032.)
llvm-svn: 281172
|
|
|
|
|
|
|
|
| |
Author: Krzysztof Parzyszek <kparzysz@codeaurora.org>
Differential Revision: https://reviews.llvm.org/D24209
llvm-svn: 280552
|
|
|
|
| |
llvm-svn: 279303
|
|
|
|
| |
llvm-svn: 279280
|
|
|
|
| |
llvm-svn: 279241
|
|
|
|
| |
llvm-svn: 278878
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ALIGNA PS_aligna
ALLOCA PS_alloca
TFR_FI PS_fi
TFR_FIA PS_fia
TFR_PdFalse PS_false
TFR_PdTrue PS_true
VMULW PS_vmulw
VMULW_ACC PS_vmulw_acc
llvm-svn: 278832
|
|
|
|
| |
llvm-svn: 278823
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove unused instructions: LDriq_pred_vec_V6, STriq_pred_vec_V6, and
the 128B counterparts.
- Rename:
LDriq_pred_V6 PS_vloadrq_ai
LDriq_pred_V6_128B PS_vloadrq_ai_128B
STriq_pred_V6 PS_vstorerq_ai
STriq_pred_V6_128B PS_vstorerq_ai_128B
llvm-svn: 278813
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the following single-vector load/store pseudo instructions, use real
instructions instead:
LDriv_pseudo_V6 STriv_pseudo_V6
LDriv_pseudo_V6_128B STriv_pseudo_V6_128B
LDrivv_indexed STrivv_indexed
LDrivv_indexed_128B STrivv_indexed_128B
Rename the double-vector load/store pseudo instructions, add unaligned
counterparts:
-- old -- -- new -- -- unaligned --
LDrivv_pseudo_V6 PS_vloadrw_io PS_vloadrwu_io
LDrivv_pseudo_V6_128B PS_vloadrw_io_128B PS_vloadrwu_io_128B
STrivv_pseudo_V6 PS_vstorerw_io PS_vstorerwu_io
STrivv_pseudo_V6_128B PS_vstorerw_io_128 PS_vstorerwu_io_128
llvm-svn: 278564
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- CALLv3nr PS_call_nr
- CALLRv3nr PS_callr_nr
- CALLstk PS_call_stk
- TCRETURNi PS_tailcall_i
- TCRETURNr PS_tailcall_r
- JMPret PS_jmpret
- JMPrett PS_jmprett
- JMPretf PS_jmpretf
- JMPrettnew PS_jmprettnew
- JMPretfnew PS_jmpretfnew
- JMPrettnewpt PS_jmprettnewpt
- JMPretfnewpt PS_jmpretfnewpt
llvm-svn: 278499
|
|
|
|
| |
llvm-svn: 278498
|
|
|
|
| |
llvm-svn: 278416
|
|
|
|
|
|
|
|
| |
- PS_pselect: general register pairs
- PS_vselect: vector registers (+ 128B version)
- PS_wselect: vector register pairs (+ 128B version)
llvm-svn: 278390
|
|
|
|
|
|
|
|
|
|
|
|
| |
Floating point instructions use general purpose registers, so the few
instructions that can put floating point immediates into registers are,
in fact, integer instruction. Use them explicitly instead of having
pseudo-instructions specifically for dealing with floating point values.
Simplify the constant loading instructions (from sdata) to have only two:
one for 32-bit values and one for 64-bit values: CONST32 and CONST64.
llvm-svn: 278244
|
|
|
|
|
|
| |
There were a few cases introduced with the modulo scheduler.
llvm-svn: 277358
|
|
|
|
| |
llvm-svn: 277220
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Software pipelining is an optimization for improving ILP by
overlapping loop iterations. Swing Modulo Scheduling (SMS) is
an implementation of software pipelining that attempts to
reduce register pressure and generate efficient pipelines with
a low compile-time cost.
This implementaion of SMS is a target-independent back-end pass.
When enabled, the pass should run just prior to the register
allocation pass, while the machine IR is in SSA form. If the pass
is successful, then the original loop is replaced by the optimized
loop. The optimized loop contains one or more prolog blocks, the
pipelined kernel, and one or more epilog blocks.
This pass is enabled for Hexagon only. To enable for other targets,
a couple of target specific hooks must be implemented, and the
pass needs to be called from the target's TargetMachine
implementation.
Differential Review: http://reviews.llvm.org/D16829
llvm-svn: 277169
|
|
|
|
|
|
|
|
|
|
|
| |
The post register allocator scheduler can generate poor schedules
because the scoreboard hazard recognizer is unable to identify
hazards for Hexagon precisely. Instead, Hexagon should use a DFA
based hazard recognizer.
Patch by Brendon Cahoon.
llvm-svn: 277143
|
|
|
|
|
|
|
| |
getFrameInfo() never returns nullptr so we should use a reference
instead of a pointer.
llvm-svn: 277017
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Hexagon schedulers need to handle instructions with a latency
of 0 or 2 more accurately. The problem, in v60, is that a dependence
between two instructions with a 2 cycle latency can use a .cur version
of the source to achieve a 0 cycle latency when the use is in the
same packet. Any othe use, must be at least 2 packets later, or a
stall occurs. In other words, the compiler does not want to schedule
the dependent instructions 1 cycle later.
To achieve this, the latency adjustment code allows only a single
dependence to have a zero latency. All other instructions have the
other value, which is typically 2 cycles. We use a heuristic to
determine which instruction gets the 0 latency.
The Hexagon machine scheduler was also changed to increase the cost
associated with 0 latency dependences than can be scheduled in the
same packet.
Patch by Brendon Cahoon.
llvm-svn: 275625
|
|
|
|
|
|
|
|
|
| |
- Treat bitwise OR with a frame index as an ADD wherever possible, fold it
into addressing mode.
- Extend patterns for memops to allow memops with frame indexes as address
operands.
llvm-svn: 275569
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: NFC. Rename AnalyzeBranch/AnalyzeBranchPredicate to analyzeBranch/analyzeBranchPredicate to follow LLVM coding style and be consistent with TargetInstrInfo's analyzeCompare and analyzeSelect.
Reviewers: tstellarAMD, mcrosier
Subscribers: mcrosier, jholewinski, jfb, arsenm, dschuff, jyknight, dsanders, nemanjai
Differential Revision: https://reviews.llvm.org/D22409
llvm-svn: 275564
|
|
|
|
|
|
|
|
| |
On Hexagon is it legal to packetize the instructions setting up call
arguments with the call instruction itself. This was already done,
except for tail calls. Make sure tail calls are handled as well.
llvm-svn: 275458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop using an implicit conversion from the return of
MachineBasicBlock::getFirstTerminator to MachineInstr*. In two cases,
directly dereference to a MachineInstr& since later code assumes it's
valid. In a third case, change to an iterator since later code checks
against MachineBasicBlock::end.
Although the fix for the third case avoids undefined behaviour, I expect
this doesn't cause a functionality change in practice (since the basic
block already has a terminator).
llvm-svn: 274898
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Fix for PR28138.
llvm-svn: 272836
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 272399
|
|
|
|
|
|
|
|
| |
Handle it locally instead of having the target-independent pass deal
with it. The generic pass does not preserve implicit uses, which may
be necessary.
llvm-svn: 271520
|
|
|
|
|
|
|
| |
Remove all the checks for constant extenders from isPredicable. The users
of it should be the ones checking cost/profitability.
llvm-svn: 269664
|
|
|
|
| |
llvm-svn: 269328
|
|
|
|
|
|
|
|
| |
Patch by Apelete Seketeli.
Differential Revision: http://reviews.llvm.org/D19968
llvm-svn: 268691
|
|
|
|
| |
llvm-svn: 268690
|
|
|
|
|
|
| |
Patch by Jyotsna Verma.
llvm-svn: 268051
|
|
|
|
|
|
|
|
|
|
|
|
| |
In PIC mode, the registers R14, R15 and R28 are reserved for use by
the PLT handling code. This causes all functions to clobber these
registers. While this is not new for regular function calls, it does
also apply to save/restore functions, which do not follow the standard
ABI conventions with respect to the volatile/non-volatile registers.
Patch by Jyotsna Verma.
llvm-svn: 264324
|
|
|
|
|
|
|
|
| |
Update APIs in MachineInstrBundle.h to take and return MachineInstr&
instead of MachineInstr* when the instruction cannot be null. Besides
being a nice cleanup, this is tacking toward a fix for PR26753.
llvm-svn: 262141
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change TargetInstrInfo API to take `MachineInstr&` instead of
`MachineInstr*` in the functions related to predicated instructions
(I'll try to come back later and get some of the rest). All of these
functions require non-null parameters already, so references are more
clear. As a bonus, this happens to factor away a host of implicit
iterator => pointer conversions.
No functionality change intended.
llvm-svn: 261605
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a little embarrassing.
When I reverted r261504 (getIterator() => getInstrIterator()) in
r261567, I did a `git grep` to see if there were new calls to
`getInstrIterator()` that I needed to migrate. There were 10-20 hits,
and I blindly did a `sed ...` before calling `ninja check`.
However, these were `MachineInstrBundleIterator::getInstrIterator()`,
which predated r261567. Perhaps coincidentally, these had an identical
name and return type.
This commit undoes my careless sed and restores
`MachineBasicBlock::iterator::getInstrIterator()`.
llvm-svn: 261577
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r261504, since it's not obvious the new name is
better:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160222/334298.html
I'll recommit if we get consensus that it's the right direction.
llvm-svn: 261567
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Delete MachineInstr::getIterator(), since the term "iterator" is
overloaded when talking about MachineInstr.
- Downcast to ilist_node in iplist::getNextNode() and getPrevNode() so
that ilist_node::getIterator() is still available.
- Add it back as MachineInstr::getInstrIterator(). This matches the
naming in MachineBasicBlock.
- Add MachineInstr::getBundleIterator(). This is explicitly called
"bundle" (not matching MachineBasicBlock) to disintinguish it clearly
from ilist_node::getIterator().
- Update all calls. Some of these I switched to `auto` to remove
boiler-plate, since the new name is clear about the type.
There was one call I updated that looked fishy, but it wasn't clear what
the right answer was. This was in X86FrameLowering::inlineStackProbe(),
added in r252578 in lib/Target/X86/X86FrameLowering.cpp. I opted to
leave the behaviour unchanged, but I'll reply to the original commit on
the list in a moment.
llvm-svn: 261504
|
|
|
|
| |
llvm-svn: 260748
|
|
|
|
| |
llvm-svn: 260725
|
|
|
|
| |
llvm-svn: 260698
|
|
|
|
|
|
| |
Patch by Tobias Edler Von Koch.
llvm-svn: 258527
|
|
|
|
| |
llvm-svn: 257771
|
|
|
|
| |
llvm-svn: 257768
|