Age | Commit message (Collapse) | Author |
|
This will be used to truncate live range of DBG_VALUE instruction by register allocator and friends.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121061 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
message instead of creating DBG_VALUE for undefined value in reg0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121059 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121050 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
patch contributed by Jack Whitham!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121049 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Use BRAD instead of BRD for indirect branches in MBlaze backend.
patch contributed by Jack Whitham!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121044 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
+ ARM/X86/MBlaze now share a common RecordRelocation
+ ARM/X86/MBlaze arch specific routines are limited to GetRelocType()
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121043 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121042 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121041 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121040 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121038 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Address more hazards in the MBlaze delay slot filler.
patch contributed by Jack Whitham!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121037 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121034 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
freed data to be read. I will open a bug to track it being reenabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121028 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121026 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121024 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
friends) to Pseudos.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121021 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the instruction is predicated, reg0 otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121020 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
not an immediate. It stores either ARM::CPSR or reg0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121018 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
builds it may not work.
This time for .s file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121016 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
as llc + llvm-mc. This time ELF is not changed and I tested that llvm-gcc
bootstrap on darwin10 using darwin9's assembler and linker.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121006 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
linux and darwin assemblers happy :-(
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121004 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121001 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that no relocations are used (on MochO).
Fixes llc producing different output from llc + llvm-mc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121000 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120998 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
optimization.
Consider:
static void foo() {
A = alloca
...
}
static void bar() {
B = alloca
...
call foo();
}
void main() {
bar()
}
The inliner proceeds bottom up, but lets pretend it decides not to inline foo
into bar. When it gets to main, it inlines bar into main(), and says "hey, I
just inlined an alloca "B" into main, lets remember that. Then it keeps going
and finds that it now contains a call to foo. It decides to inline foo into
main, and says "hey, foo has an alloca A, and I have an alloca B from another
inlined call site, lets reuse it". The problem with this of course, is that
the lifetime of A and B are nested, not disjoint.
Unfortunately I can't create a reasonable testcase for this: the one in the
PR is both huge and extremely sensitive, because you minor tweaks end up
causing foo to get inlined into bar too early. We already have tests for the
basic alloca merging optimization and this does not break them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120995 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120994 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120993 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120991 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120989 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120988 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120987 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120986 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120985 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
PathV2
implementation needs it for wchar_t and SmallVectorImpl in general.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120984 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120982 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that on the ELF writer to detect a section we created.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120981 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120980 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120979 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120978 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120977 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
memcpy's like:
memcpy(A, B)
memcpy(A, C)
we cannot delete the first memcpy as dead if A and C might be aliases.
If so, we actually get:
memcpy(A, B)
memcpy(A, A)
which is not correct to transform into:
memcpy(A, A)
This patch was heavily influenced by Jakub Staszak's patch in PR8728, thanks
Jakub!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120974 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120973 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120971 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120966 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120965 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120964 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
StrongPHIElimination.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120961 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
difficult on current ARM implementations for a few reasons.
1. Even though a single vmla has latency that is one cycle shorter than a pair
of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause
additional pipeline stall. So it's frequently better to single codegen
vmul + vadd.
2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to
stall for 4 cycles. We need to schedule them apart.
3. A vmla followed vmla is a special case. Obvious issuing back to back RAW
vmla + vmla is very bad. But this isn't ideal either:
vmul
vadd
vmla
Instead, we want to expand the second vmla:
vmla
vmul
vadd
Even with the 4 cycle vmul stall, the second sequence is still 2 cycles
faster.
Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough
but it isn't the optimial solution. This patch attempts to make it possible to
use vmla / vmls in cases where it is profitable.
A. Add missing isel predicates which cause vmla to be codegen'ed.
B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to
compute a fmul and a fmla.
C. Add additional isel checks for vmla, avoid cases where vmla is feeding into
fp instructions (except for the #3 exceptional case).
D. Add ARM hazard recognizer to model the vmla / vmls hazards.
E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the
vmla / vmls will trigger one of the special hazards.
Work in progress, only A+B are enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120960 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120959 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
indexing with insertvalue/extractvalue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120957 91177308-0d34-0410-b5e6-96231b3b80d8
|