| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 306458
|
|
|
|
| |
llvm-svn: 306288
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).
llvm-svn: 304787
|
|
|
|
|
|
|
| |
This allows using this function to test if an instruction can be converted
to a .new form.
llvm-svn: 304549
|
|
|
|
|
|
|
| |
An incorrect check in the packetizer lead to an attempt to convert
an unconditional branch to a .new (conditional) form.
llvm-svn: 304442
|
|
|
|
|
|
|
| |
- Take reference instead of pointer to a TRI that cannot be nullptr.
- Improve documentation comments.
llvm-svn: 304038
|
|
|
|
| |
llvm-svn: 302307
|
|
|
|
|
|
| |
Patch by Jyotsna Verma.
llvm-svn: 302073
|
|
|
|
| |
llvm-svn: 302036
|
|
|
|
|
|
| |
Formatting changes + remove unused function.
llvm-svn: 302035
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allocframe and the following stores on the stack have a latency of 2 cycles
when not in the same packet. This happens because R29 is needed early by the
store instruction. Since one of such stores can be packetized along with
allocframe and use old value of R29, we can assign it 0 cycle latency
while leaving latency of other stores to the default value of 2 cycles.
Patch by Jyotsna Verma.
llvm-svn: 302034
|
|
|
|
| |
llvm-svn: 302033
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The packetizer needs to convert .cur instruction to its regular form if
the use is not in the same packet as the .cur. The code in the packetizer
handles one type of .cur, which is the vector load case. This patch
updates the packetizer so that it can undo all the .cur instructions.
In the test case, the .cur is the 128B version, but there are also the
post-increment versions.
Patch by Brendon Cahoon.
llvm-svn: 302032
|
|
|
|
| |
llvm-svn: 302030
|
|
|
|
| |
llvm-svn: 302029
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The compiler was generating code that ends up ignoring a multiple
latency dependence between two instructions by scheduling the
intructions in back-to-back packets.
The packetizer needs to end a packet if the latency of the current
current insruction and the source in the previous packet is
greater than 1 cycle. This case occurs when there is still room in
the current packet, but scheduling the instruction causes a stall.
Instead, the packetizer should start a new packet. Also, if the
current packet already contains a stall, then it is okay to add
another instruction to the packet that also causes a stall. This
occurs when there are no instructions that can be scheduled in
between the producer and consumer instructions.
This patch changes the latency for loads to 2 cycles from 3 cycles.
This change refects that a load only needs to be separated by
one extra packet to eliminate the stall.
Patch by Ikhlas Ajbar.
llvm-svn: 301954
|
|
|
|
|
|
| |
Patch by Colin LeMahieu.
llvm-svn: 301952
|
|
|
|
| |
llvm-svn: 297031
|
|
|
|
| |
llvm-svn: 296901
|
|
|
|
|
|
|
| |
Specifically, pick the opcode with the correct branch prediction, i.e.
jump:t or jump:nt.
llvm-svn: 296821
|
|
|
|
|
|
| |
Reapply r295371 with a fix for the Windows bot failures.
llvm-svn: 295504
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r295371.
It broke windows bots:
http://bb.pgr.jp/builders/ninja-clang-i686-msc19-R/builds/11402/steps/test-llvm/logs/stdio
llvm-svn: 295402
|
|
|
|
|
|
| |
All the cool targets are doing it...
llvm-svn: 295371
|
|
|
|
| |
llvm-svn: 295078
|
|
|
|
| |
llvm-svn: 294753
|
|
|
|
| |
llvm-svn: 293925
|
|
|
|
| |
llvm-svn: 293894
|
|
|
|
|
|
|
|
|
|
|
| |
Rename from addOperand to just add, to match the other method that has been
added to MachineInstrBuilder for adding more than just 1 operand.
See https://reviews.llvm.org/D28057 for the whole discussion.
Differential Revision: https://reviews.llvm.org/D28556
llvm-svn: 291891
|
|
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 290925
|
|
|
|
|
|
| |
Identified by Pedro Giffuni in PR27636.
llvm-svn: 287248
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Stack slot coloring pass removes a store that is followed by a load
that deal with the same stack slot. The function isLoadFromStackSlot
is supposed to consider the loads that have no side-effects. This
patch fixed the issue by removing the unsafe loads from this function
Eg:
%vreg0<def> = L2_loadruh_io <fi#15>, 0
S2_storeri_io <fi#15>, 0, %vreg0
In this case, we load an unsigned extended half word and store this in to
the same stack slot. The Stack slot coloring pass considers safe to remove
the store. This patch marked all the non-vector byte and half word loads as
unsafe.
llvm-svn: 286843
|
|
|
|
|
|
|
|
|
|
|
| |
For pairs of 32-bit registers: isub_lo, isub_hi.
For pairs of vector registers: vsub_lo, vsub_hi.
Add generic subreg indices: ps_sub_lo, ps_sub_hi, and a function
HexagonRegisterInfo::getHexagonSubRegIndex(RegClass, GenericSubreg)
that returns the appropriate subreg index for RegClass.
llvm-svn: 286377
|
|
|
|
| |
llvm-svn: 286368
|
|
|
|
|
|
|
|
| |
This is a function to go backwards in a block to find the first
instruction in a bundle, so iterator is a more natural choice for
parameter/return rather than a reference to a MachineInstruction.
llvm-svn: 285051
|
|
|
|
| |
llvm-svn: 283018
|
|
|
|
| |
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
|