| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
is pc relative or not, mark call and branches as pcrel.
llvm-svn: 96026
|
| |
|
|
|
|
| |
up with a reasonable test case.
llvm-svn: 96023
|
| |
|
|
| |
llvm-svn: 96020
|
| |
|
|
| |
llvm-svn: 96019
|
| |
|
|
| |
llvm-svn: 96018
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stack frame, the prolog/epilog code was using the same
register for the copy of CR and the address of the save slot. Oops.
This is fixed here for Darwin, sort of, by reserving R2 for this case.
A better way would be to do the store before the decrement of SP,
which is safe on Darwin due to the red zone.
SVR4 probably has the same problem, but I don't know how to fix it;
there is no red zone and R2 is already used for something else.
I'm going to leave it to someone interested in that target.
Better still would be to rewrite the CR-saving code completely;
spilling each CR subregister individually is horrible code.
llvm-svn: 96015
|
| |
|
|
| |
llvm-svn: 96011
|
| |
|
|
| |
llvm-svn: 96010
|
| |
|
|
| |
llvm-svn: 96008
|
| |
|
|
| |
llvm-svn: 96007
|
| |
|
|
| |
llvm-svn: 96006
|
| |
|
|
| |
llvm-svn: 96005
|
| |
|
|
|
|
| |
offset distributions it doesn't expect.
llvm-svn: 96002
|
| |
|
|
| |
llvm-svn: 95999
|
| |
|
|
|
|
|
|
|
|
|
| |
didn't handle
X =
Y<dead> = use X
DBG_VALUE(X)
I was hoping to avoid this approach as it's slower,
but I don't think it can be done.
llvm-svn: 95996
|
| |
|
|
|
|
|
|
|
| |
2. don't bother trying to merge globals in non-default sections,
doing so is quite dubious at best anyway.
3. fix a bug reported by Arnaud de Grandmaison where we'd try to
merge two globals in different address spaces.
llvm-svn: 95995
|
| |
|
|
| |
llvm-svn: 95993
|
| |
|
|
|
|
| |
is breaking llvm-gcc bootstrap.
llvm-svn: 95988
|
| |
|
|
| |
llvm-svn: 95982
|
| |
|
|
| |
llvm-svn: 95981
|
| |
|
|
|
|
| |
This should fix alot of problems we saw so far, e.g. PRs 5851 & 2936
llvm-svn: 95980
|
| |
|
|
|
|
|
| |
doesn't matter, except that ScalarEvolution tends to need less time
to fold the results this way.
llvm-svn: 95979
|
| |
|
|
|
|
|
|
|
|
| |
bug fixes, and with improved heuristics for analyzing foreign-loop
addrecs.
This change also flattens IVUsers, eliminating the stride-oriented
groupings, which makes it easier to work with.
llvm-svn: 95975
|
| |
|
|
|
|
|
|
|
|
| |
costs.
* Enabled R1/R2 application for nodes with infinite spill costs in the Briggs heuristic (made
safe by the changes to the normalization proceedure).
* Removed a redundant header.
llvm-svn: 95973
|
| |
|
|
| |
llvm-svn: 95971
|
| |
|
|
| |
llvm-svn: 95962
|
| |
|
|
|
|
|
| |
This will work better for the disassembler for modeling things
like lfence/monitor/vmcall etc.
llvm-svn: 95960
|
| |
|
|
| |
llvm-svn: 95959
|
| |
|
|
|
|
| |
great solution for the disassembler, we'll go with "plan b".
llvm-svn: 95957
|
| |
|
|
|
|
|
|
|
| |
matcher is now free of implicit operands!
- Still need to clean up the code now that we don't to worry about implicit
operands, and to make it a hard error if an instruction fails to specify all
of its operands for some reason.
llvm-svn: 95956
|
| |
|
|
|
|
| |
MRRC, MRRc2. For disassembly only.
llvm-svn: 95955
|
| |
|
|
|
|
|
|
|
|
|
| |
reduce down to a single value. InstCombine already does this transformation
but DAG legalization may introduce new opportunities. This has turned out to
be important for ARM where 64-bit values are split up during type legalization:
InstCombine is not able to remove the PHI cycles on the 64-bit values but
the separate 32-bit values can be optimized. I measured the compile time
impact of this (running llc on 176.gcc) and it was not significant.
llvm-svn: 95951
|
| |
|
|
|
|
| |
with "tied memory operands", which is wrong.
llvm-svn: 95950
|
| |
|
|
| |
llvm-svn: 95949
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
movq (%ecx,%edx,2), %xmm2
movhps (%ecx,%eax,2), %xmm2
rather than:
movq (%eax, %edx, 2), %xmm2
movq (%eax, %ebx, 2), %xmm3
movlhps %xmm3, %xmm2
Testcase forthcoming.
llvm-svn: 95948
|
| |
|
|
|
|
|
| |
busted in both encoders. I'm not bothering to fix it in the
old one at this point.
llvm-svn: 95947
|
| |
|
|
|
|
| |
Kees van Reeuwijk!
llvm-svn: 95946
|
| |
|
|
|
|
|
| |
implement support for it) that the stack should be forcibly realigned in the
prologue (and the process reversed in the epilogue).
llvm-svn: 95945
|
| |
|
|
|
|
| |
This time with fixed test cases.
llvm-svn: 95938
|
| |
|
|
|
|
|
|
|
|
| |
testb %al, %al ## <MCInst #2412 TEST8rr
## <MCOperand Reg:2>
## <MCOperand Reg:2>>
jne LBB1_7 ## <MCInst #938 JNE_1
## <MCOperand Expr:(LBB1_7)>>
llvm-svn: 95935
|
| |
|
|
|
|
|
| |
implemented, llvm-mc --show-inst now uses it to print the
instruction opcode as well as the number.
llvm-svn: 95929
|
| |
|
|
| |
llvm-svn: 95928
|
| |
|
|
|
|
|
| |
8 or 32-bit immediates, which allows the new encoder to handle
them.
llvm-svn: 95927
|
| |
|
|
| |
llvm-svn: 95926
|
| |
|
|
| |
llvm-svn: 95925
|
| |
|
|
|
|
|
| |
the tables to be const. Teach MCCodeEmitter to handle
the target-indep kinds so that we don't crash on them.
llvm-svn: 95924
|
| |
|
|
| |
llvm-svn: 95921
|
| |
|
|
| |
llvm-svn: 95920
|
| |
|
|
| |
llvm-svn: 95918
|
| |
|
|
|
|
|
|
| |
tiny interval.
Also avoid division by zero.
llvm-svn: 95917
|