| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
All loads of form V6_vL32b_{,cur,nt,tmp,nt_cur,nt_tmp}_{ai,pi,ppu} are
predicable on v62 (but not on v60). Mark them all as predicable in the
instruction definitions, and handle the v60 case in HII::isPredicable.
llvm-svn: 316098
|
|
|
|
| |
llvm-svn: 315472
|
|
|
|
|
|
|
|
|
|
|
|
| |
The software pipeliner and the packetizer try to break dependence
between the post-increment instruction and the dependent memory
instructions by changing the base register and the offset value.
However, in some cases, the existing logic didn't work properly
and created incorrect offset value.
Patch by Jyotsna Verma.
llvm-svn: 315468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pipeliner is generating a serial sequence that causes poor
register allocation when a post-increment instruction appears
prior to the use of the post-increment register. This occurs when
there is a circular set of dependences involved with a sequence
of instructions in the same cycle. In this case, there is no
serialization of the parallel semantics that will not cause an
additional register to be allocated.
This patch fixes the problem by changing the instructions so that
the post-increment instruction is used by the subsequent
instruction, which enables the register allocator to make a
better decision and not require another register.
Patch by Brendon Cahoon.
llvm-svn: 315466
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new format is changeAddrMode_xx_yy, where xx is the current mode,
and yy is the new one.
Old name: New name:
getBaseWithImmOffset changeAddrMode_abs_io
getAbsoluteForm changeAddrMode_io_abs
getBaseWithRegOffset changeAddrMode_io_rr
xformRegToImmOffset changeAddrMode_rr_io
getBaseWithLongOffset changeAddrMode_rr_ur
getRegShlForm changeAddrMode_ur_rr
llvm-svn: 315013
|
|
|
|
| |
llvm-svn: 314920
|
|
|
|
|
|
| |
other minor fixes (NFC).
llvm-svn: 314467
|
|
|
|
|
|
|
| |
This removes the duplicate HVX instruction set for the 128-byte mode.
Single instruction set now works for both modes (64- and 128-byte).
llvm-svn: 313362
|
|
|
|
|
|
|
|
| |
It used to return the actual field value from the instruction descriptor.
There is no reason for that, that value is not interesting in any way and
the specifics of its encoding in the descriptor should not be exposed.
llvm-svn: 313257
|
|
|
|
| |
llvm-svn: 308510
|
|
|
|
| |
llvm-svn: 308502
|
|
|
|
| |
llvm-svn: 308485
|
|
|
|
|
|
|
|
| |
Patch by Michael Wu.
Differential Revision: https://reviews.llvm.org/D35104
llvm-svn: 307671
|
|
|
|
|
|
| |
This fixes https://llvm.org/PR33718.
llvm-svn: 307566
|
|
|
|
| |
llvm-svn: 307564
|
|
|
|
| |
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
|