| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D34640
llvm-svn: 306466
|
|
|
|
| |
llvm-svn: 306458
|
|
|
|
|
|
|
| |
Account for the fact that both, the feeder and the compare can be moved
over instructions that kill registers.
llvm-svn: 306443
|
|
|
|
| |
llvm-svn: 306288
|
|
|
|
|
|
| |
This breaks passing of aligned function arguments.
llvm-svn: 306145
|
|
|
|
| |
llvm-svn: 306124
|
|
|
|
|
|
|
| |
The feeder instruction will be moved to right before the compare, so
the updating code should not be looking for kills past the compare.
llvm-svn: 306059
|
|
|
|
|
|
| |
Remove the previous, manual shuffling of the kill flags.
llvm-svn: 306054
|
|
|
|
| |
llvm-svn: 306030
|
|
|
|
| |
llvm-svn: 306012
|
|
|
|
|
|
|
| |
Reserve an extra scavenging stack slot if the offset field in store-
-immediate instructions may overflow.
llvm-svn: 306004
|
|
|
|
| |
llvm-svn: 305943
|
|
|
|
|
|
|
|
|
| |
The second part of r305300: when placing the mux at the later location,
make sure that it won't use any register that was killed between the
two original instructions. Remove any such kills and transfer them to
the mux.
llvm-svn: 305553
|
|
|
|
|
|
|
|
|
| |
Store-immediate instructions have a non-extendable offset. Since the
actual offset for a stack object is not known until much later, only
generate these stores when the stack size (at the time of instruction
selection) is small.
llvm-svn: 305305
|
|
|
|
| |
llvm-svn: 305302
|
|
|
|
|
|
|
|
|
|
|
| |
When a mux instruction is created from a pair of complementary conditional
transfers, it can be placed at the location of either the earlier or the
later of the transfers. Since it will use the operands of the original
transfers, putting it in the earlier location may hoist a kill of a source
register that was originally further down. Make sure the kill flag is
removed if the register is still used afterwards.
llvm-svn: 305300
|
|
|
|
|
|
|
| |
The conversion of shifts from right shifts to left shifts may fail.
In such case, the pmpy recognition cannot proceed.
llvm-svn: 305289
|
|
|
|
| |
llvm-svn: 305014
|
|
|
|
| |
llvm-svn: 304937
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The initial assumption was that the simplification would converge to a
fixed point relatvely quickly. Turns out that there are legitimate situa-
tions where the complexity of the code causes it to take a large number
of iterations.
Two main changes:
- Instead of aborting upon hitting the limit, simply return nullptr.
- Reduce the limit to 10,000 from 100,000.
llvm-svn: 304441
|
|
|
|
|
|
|
|
|
| |
For multiplications of 64-bit values (giving 64-bit result), detect
cases where the arguments are sign-extended 32-bit values, on a per-
operand basis. This will allow few patterns to match a wider variety
of combinations in which extensions can occur.
llvm-svn: 304223
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rewrite fixupKills() to use the LivePhysRegs class. Simplifies the code
and fixes a bug where the CSR registers in return blocks where missed
leading to invalid kill flags. Also remove the unnecessary rule that we
wouldn't set kill flags on tied operands.
No tests as I have an upcoming commit improving MachineVerifier checks
to catch these cases in multiple existing lit tests.
llvm-svn: 304055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using arguments with attribute inalloca creates problems for verification
of machine representation. This attribute instructs the backend that the
argument is prepared in stack prior to CALLSEQ_START..CALLSEQ_END
sequence (see http://llvm.org/docs/InAlloca.htm for details). Frame size
stored in CALLSEQ_START in this case does not count the size of this
argument. However CALLSEQ_END still keeps total frame size, as caller can
be responsible for cleanup of entire frame. So CALLSEQ_START and
CALLSEQ_END keep different frame size and the difference is treated by
MachineVerifier as stack error. Currently there is no way to distinguish
this case from actual errors.
This patch adds additional argument to CALLSEQ_START and its
target-specific counterparts to keep size of stack that is set up prior to
the call frame sequence. This argument allows MachineVerifier to calculate
actual frame size associated with frame setup instruction and correctly
process the case of inalloca arguments.
The changes made by the patch are:
- Frame setup instructions get the second mandatory argument. It
affects all targets that use frame pseudo instructions and touched many
files although the changes are uniform.
- Access to frame properties are implemented using special instructions
rather than calls getOperand(N).getImm(). For X86 and ARM such
replacement was made previously.
- Changes that reflect appearance of additional argument of frame setup
instruction. These involve proper instruction initialization and
methods that access instruction arguments.
- MachineVerifier retrieves frame size using method, which reports sum of
frame parts initialized inside frame instruction pair and outside it.
The patch implements approach proposed by Quentin Colombet in
https://bugs.llvm.org/show_bug.cgi?id=27481#c1.
It fixes 9 tests failed with machine verifier enabled and listed
in PR27481.
Differential Revision: https://reviews.llvm.org/D32394
llvm-svn: 302527
|
|
|
|
| |
llvm-svn: 302305
|
|
|
|
|
|
|
|
|
|
|
| |
Hoisting common code can cause registers that live-in in the successor
blocks to no longer be live-in. The live-in information needs to be
updated to reflect this, or otherwise incorrect code can be generated
later on.
Differential Revision: https://reviews.llvm.org/D32661
llvm-svn: 302228
|
|
|
|
|
|
| |
Patch by Jyotsna Verma.
llvm-svn: 302073
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Patch by Sid Manning.
llvm-svn: 301955
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 301700
|
|
|
|
|
|
|
|
|
| |
When a PHI operand has a subregister, create a COPY instead of simply
replacing the PHI output with the input it.
Differential Revision: https://reviews.llvm.org/D32650
llvm-svn: 301699
|
|
|
|
| |
llvm-svn: 301698
|
|
|
|
|
|
|
|
|
| |
Also, make a few changes to allow using the pass in .mir testcases.
Among other things, change the abbreviation from opt-amode to amode-opt,
because otherwise lit would expand the "opt" part to the full path to
the opt binary.
llvm-svn: 300707
|
|
|
|
|
|
| |
In preparation for allowing allocas to have non-0 addrspace.
llvm-svn: 299876
|
|
|
|
| |
llvm-svn: 299582
|
|
|
|
|
|
| |
Found by PVS-Studio. Fixes llvm.org/PR32480.
llvm-svn: 299258
|
|
|
|
|
|
|
|
|
| |
- Avoid explosive growth of the simplification queue by not queuing
expressions that are alredy in it.
- Add an iteration counter and abort after a sufficiently large number
of iterations (assuming that it's a symptom of an infinite loop).
llvm-svn: 298655
|
|
|
|
|
|
|
|
|
|
|
| |
[Hexagon] Recognize polynomial-modulo loop idiom again
Regain the ability to recognize loops calculating polynomial modulo
operation. This ability has been lost due to some changes in the
preceding optimizations. Add code to preprocess the IR to a form
that the pattern matching code can recognize.
llvm-svn: 298400
|
|
|
|
| |
llvm-svn: 298395
|
|
|
|
|
|
|
|
| |
Fix memory leaks on check-llvm tests detected by Asan.
This reverts commit r298282.
llvm-svn: 298329
|
|
|
|
|
|
|
|
|
| |
Regain the ability to recognize loops calculating polynomial modulo
operation. This ability has been lost due to some changes in the
preceding optimizations. Add code to preprocess the IR to a form
that the pattern matching code can recognize.
llvm-svn: 298282
|
|
|
|
|
|
| |
Use Liveness::getNearestAliasedRef to find the reaching def instead.
llvm-svn: 297526
|
|
|
|
|
|
|
|
| |
- Fix the insertion point, which occasionally could have been incorrect.
- Avoid creating multiple bitsplits with the same operands, if an old one
could be reused.
llvm-svn: 297414
|
|
|
|
|
|
|
| |
(op ... (zext i1 c) ...) -> (select c (op ... 1 ...),
(op ... 0 ...))
llvm-svn: 297391
|
|
|
|
|
|
|
|
| |
When extracting a bitfield from the high register in a register pair,
the final offset should be relative to the high register (for 32-bit
extracts).
llvm-svn: 297288
|
|
|
|
| |
llvm-svn: 297240
|
|
|
|
| |
llvm-svn: 297239
|
|
|
|
| |
llvm-svn: 297141
|