| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
rdar://8131327
llvm-svn: 108008
|
|
|
|
|
|
|
|
|
| |
Add explicit testcases for tail calls within the same module.
Duplicate some code to humor those who think .w doesn't apply on ARM.
Leave this disabled on Thumb1, and add some comments explaining why it's hard
and won't gain much.
llvm-svn: 107851
|
|
|
|
|
|
|
| |
limit on the offset that can be materialized without using the register
scavenger.
llvm-svn: 106312
|
|
|
|
|
|
|
| |
ARM tail calls. Don't know if it works, but it
doesn't break Darwin.
llvm-svn: 106309
|
|
|
|
|
|
|
|
| |
call must not be callee-saved; following x86, add a new
regclass to represent this. Also fixes a couple of bugs.
Still disabled by default; Thumb doesn't work yet.
llvm-svn: 106053
|
|
|
|
|
|
|
|
|
| |
A temporary flag -arm-tail-calls defaults to off,
so there is no functional change by default.
Intrepid users may try this; simple cases work
but there are bugs.
llvm-svn: 105413
|
|
|
|
|
|
| |
and tidy up the comment describing it.
llvm-svn: 105339
|
|
|
|
| |
llvm-svn: 105335
|
|
|
|
| |
llvm-svn: 104573
|
|
|
|
|
|
| |
from ARMRegisterInfo.h
llvm-svn: 104508
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
too large limit.
The function would return immediately when finding an addrmode 3/5 instruction.
It needs to keep scanning in case there is an addrmode 6 instruction which drops
the limit to 0.
A test case is very difficult to produce because it will only fail when the
scavenger is used.
rdar://problem/7894847
llvm-svn: 103995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instructions.
e.g.
%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1027<def> = EXTRACT_SUBREG %reg1026, 6
%reg1028<def> = EXTRACT_SUBREG %reg1026<kill>, 5
...
%reg1029<def> = REG_SEQUENCE %reg1028<kill>, 5, %reg1027<kill>, 6, %reg1028, 7, %reg1027, 8, %reg1028, 9, %reg1027, 10, %reg1030<kill>, 11, %reg1032<kill>, 12
After REG_SEQUENCE is eliminated, we are left with:
%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1029:6<def> = EXTRACT_SUBREG %reg1026, 6
%reg1029:5<def> = EXTRACT_SUBREG %reg1026<kill>, 5
The regular coalescer will not be able to coalesce reg1026 and reg1029 because it doesn't
know how to combine sub-register indices 5 and 6. Now 2-address pass will consult the
target whether sub-registers 5 and 6 of reg1026 can be combined to into a larger
sub-register (or combined to be reg1026 itself as is the case here). If it is possible,
it will be able to replace references of reg1026 with reg1029 + the larger sub-register
index.
llvm-svn: 103835
|
|
|
|
|
|
|
|
|
| |
the variable actually tracks.
N.B., several back-ends are using "HasCalls" as being synonymous for something
that adjusts the stack. This isn't 100% correct and should be looked into.
llvm-svn: 103802
|
|
|
|
| |
llvm-svn: 103760
|
|
|
|
|
|
| |
Do not use those for Thumb1 functions.
llvm-svn: 103730
|
|
|
|
|
|
| |
coalescer bug that's fixed by 103170.
llvm-svn: 103172
|
|
|
|
|
|
|
|
|
|
|
| |
Reverse-merging r103156 into '.':
U lib/Target/ARM/ARMInstrNEON.td
U lib/Target/ARM/ARMRegisterInfo.h
U lib/Target/ARM/ARMBaseRegisterInfo.cpp
U lib/Target/ARM/ARMBaseInstrInfo.cpp
U lib/Target/ARM/ARMRegisterInfo.td
llvm-svn: 103159
|
|
|
|
|
|
| |
registers. These will be used to model VLD2 / VST2 instructions in order to get substantially better codegen for them.
llvm-svn: 103156
|
|
|
|
| |
llvm-svn: 102324
|
|
|
|
|
|
|
| |
optimization for non-leaf functions. This will be hooked up to gcc's
-momit-leaf-frame-pointer option. rdar://7886181
llvm-svn: 101984
|
|
|
|
| |
llvm-svn: 101379
|
|
|
|
| |
llvm-svn: 101376
|
|
|
|
| |
llvm-svn: 101334
|
|
|
|
| |
llvm-svn: 100214
|
|
|
|
|
|
|
|
| |
load/store optimizer would incorrectly think that registers D26 and D28
were consecutive and would generate a VLDM instruction to load them.
The assembler was not convinced.
llvm-svn: 99043
|
|
|
|
|
|
| |
400.perlbench for the nightly tests.
llvm-svn: 98183
|
|
|
|
|
|
|
|
|
|
| |
is preparatory to having PEI's scavenged frame index value reuse logic
properly distinguish types of frame values (e.g., whether the value is
stack-pointer relative or frame-pointer relative).
No functionality change.
llvm-svn: 98086
|
|
|
|
|
|
|
|
| |
register is involved for thumb1. Work around this for the moment by only
re-using SP-relative offsets. This is temporary 'til the code can distinguish
multiple base registers.
llvm-svn: 98071
|
|
|
|
|
|
| |
frame pointer.
llvm-svn: 97755
|
|
|
|
|
|
|
|
|
|
|
| |
- Function uses all scratch registers AND
- Function does not use any callee saved registers AND
- Stack size is too big to address with immediate offsets.
In this case a register must be scavenged to calculate the address of a stack
object, and the scavenger needs a spare register or emergency spill slot.
llvm-svn: 97071
|
|
|
|
| |
llvm-svn: 97022
|
|
|
|
| |
llvm-svn: 97013
|
|
|
|
| |
llvm-svn: 96954
|
|
|
|
|
|
|
|
| |
126.gcc nightly tests. These failures uncovered latent bugs that machine DCE
could remove one half of a stack adjust down/up pair, causing PEI to assert.
This update fixes that, and the tests now pass.
llvm-svn: 96822
|
|
|
|
| |
llvm-svn: 96818
|
|
|
|
|
|
|
|
|
| |
value.
Thumb2 uses the tADJCALLSTACK* instructions, and doesn't need t2 versions, so
remove the FIXME entry.
llvm-svn: 96817
|
|
|
|
|
|
| |
the armv6 nightly tests.
llvm-svn: 96691
|
|
|
|
|
|
|
|
|
| |
for ARM to just check if a function has a FP to determine if it's safe
to simplify the stack adjustment pseudo ops prior to eliminating frame
indices. Allow targets to override the default behavior and does so for ARM
and Thumb2.
llvm-svn: 96634
|
|
|
|
|
|
|
|
|
|
| |
created. This ensures it's updated at all time. It means targets which perform
dynamic stack alignment would know whether it is required and whether frame
pointer register cannot be made available register allocation.
This is a fix for rdar://7625239. Sorry, I can't create a reasonably sized test
case.
llvm-svn: 96069
|
|
|
|
|
|
| |
even when -disable-fp-elim is specified.
llvm-svn: 95161
|
|
|
|
| |
llvm-svn: 94612
|
|
|
|
|
|
|
|
|
|
|
| |
function can support dynamic stack realignment. That's a much easier question
to answer at instruction selection stage than whether the function actually
will have dynamic alignment prologue. This allows the removal of the
stack alignment heuristic pass, and improves code quality for cases where
the heuristic would result in dynamic alignment code being generated when
it was not strictly necessary.
llvm-svn: 93885
|
|
|
|
| |
llvm-svn: 92876
|
|
|
|
|
|
| |
for stack references.
llvm-svn: 92871
|
|
|
|
| |
llvm-svn: 91914
|
|
|
|
|
|
|
|
|
|
| |
in "bic sp, sp, #15" leads to unpredicatble behaviour in Thumb2 mode.
Emit the following code instead:
mov r4, sp
bic r4, r4, #15
mov sp, r4
llvm-svn: 90724
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 90336
|
|
|
|
|
|
| |
can get bogus values.
llvm-svn: 89618
|
|
|
|
| |
llvm-svn: 89576
|
|
|
|
|
|
| |
isn't necessary.
llvm-svn: 89568
|