| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the i8 versions of instructions in some cases. In test6, we started
generating:
cmpq $0, -8(%rsp) ## encoding: [0x48,0x81,0x7c,0x24,0xf8,0x00,0x00,0x00,0x00]
## <MCInst #478 CMP64mi32
## <MCOperand Reg:114>
## <MCOperand Imm:1>
## <MCOperand Reg:0>
## <MCOperand Imm:-8>
## <MCOperand Reg:0>
## <MCOperand Imm:0>>
instead of:
cmpq $0, -8(%rsp) ## encoding: [0x48,0x83,0x7c,0x24,0xf8,0x00]
## <MCInst #479 CMP64mi8
## <MCOperand Reg:114>
## <MCOperand Imm:1>
## <MCOperand Reg:0>
## <MCOperand Imm:-8>
## <MCOperand Reg:0>
## <MCOperand Imm:0>>
Fix this and add some comments.
llvm-svn: 116053
|
| |
|
|
|
|
|
|
|
| |
reapply: reimplement the second half of the or/add optimization. We should now
with no changes. Turns out that one missing "Defs = [EFLAGS]" can upset things
a bit.
llvm-svn: 116040
|
| |
|
|
|
|
|
|
| |
"Reimplement (part of) the or -> add optimization. Matching 'or' into 'add'"
With a critical fix: the add pseudos clobber EFLAGS.
llvm-svn: 116039
|
| |
|
|
| |
llvm-svn: 116034
|
| |
|
|
|
|
| |
'add'", which seems to have broken just about everything.
llvm-svn: 116033
|
| |
|
|
|
|
| |
on r116007, which I am about to revert.
llvm-svn: 116032
|
| |
|
|
|
|
| |
which depends on r116007, which I am about to revert.
llvm-svn: 116031
|
| |
|
|
|
|
|
|
| |
as thumb1.
Fixes lencod.
llvm-svn: 116027
|
| |
|
|
|
|
|
|
|
|
| |
only end up emitting LEA instead of OR. If we aren't able to promote
something into an LEA, we should never be emitting it as an ADD.
Add some testcases that we emit "or" in cases where we used to produce
an "add".
llvm-svn: 116026
|
| |
|
|
| |
llvm-svn: 116022
|
| |
|
|
| |
llvm-svn: 116018
|
| |
|
|
|
|
| |
casing FsMOVAPDrr/FsMOVAPSrr.
llvm-svn: 116016
|
| |
|
|
| |
llvm-svn: 116014
|
| |
|
|
| |
llvm-svn: 116013
|
| |
|
|
|
|
|
| |
one user. This code will be restructured soon and FormulaSorter
is getting in the way.
llvm-svn: 116012
|
| |
|
|
| |
llvm-svn: 116011
|
| |
|
|
|
|
| |
not just base registers.
llvm-svn: 116010
|
| |
|
|
| |
llvm-svn: 116009
|
| |
|
|
|
|
| |
the old use to the new one.
llvm-svn: 116008
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is general goodness because it allows ORs to be converted to LEA to avoid
inserting copies. However, this is bad because it makes the generated .s
file less obvious and gives valgrind heartburn (tons of false positives in
bitfield code).
While the general fix should be in valgrind, we can at least try to avoid
emitting ADD instructions that *don't* get promoted to LEA. This is more
work because it requires introducing pseudo instructions to represents
"add that knows the bits are disjoint", but hey, people really love valgrind.
This fixes this testcase:
https://bugs.kde.org/show_bug.cgi?id=242137#c20
the add r/i cases are coming next.
llvm-svn: 116007
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
connected components. These components should be allocated different virtual
registers because there is no reason for them to be allocated together.
Add the ConnectedVNInfoEqClasses class to calculate the connected components,
and move values to new LiveIntervals.
Use it from SplitKit::rewrite by creating new virtual registers for the
components.
llvm-svn: 116006
|
| |
|
|
|
|
|
|
| |
This doesn't usually matter, because the other heuristics usually
succeed regardless, but it's good to keep the register use
bookkeeping consistent.
llvm-svn: 116005
|
| |
|
|
| |
llvm-svn: 116004
|
| |
|
|
| |
llvm-svn: 116003
|
| |
|
|
| |
llvm-svn: 116002
|
| |
|
|
|
|
| |
with the right types.
llvm-svn: 116001
|
| |
|
|
| |
llvm-svn: 115997
|
| |
|
|
| |
llvm-svn: 115996
|
| |
|
|
| |
llvm-svn: 115993
|
| |
|
|
| |
llvm-svn: 115991
|
| |
|
|
|
|
| |
prototype or not.
llvm-svn: 115988
|
| |
|
|
| |
llvm-svn: 115987
|
| |
|
|
| |
llvm-svn: 115984
|
| |
|
|
|
|
|
|
|
| |
use. Since TEST is completely different than all other binops,
don't define a multipattern for it.
This completes factorization of binops.
llvm-svn: 115982
|
| |
|
|
| |
llvm-svn: 115978
|
| |
|
|
|
|
| |
Also eliminate unneeded isel patterns. rdar://8520311
llvm-svn: 115977
|
| |
|
|
|
|
| |
for them from the MCCodeEmitter.
llvm-svn: 115975
|
| |
|
|
| |
llvm-svn: 115973
|
| |
|
|
| |
llvm-svn: 115971
|
| |
|
|
| |
llvm-svn: 115968
|
| |
|
|
| |
llvm-svn: 115967
|
| |
|
|
| |
llvm-svn: 115966
|
| |
|
|
| |
llvm-svn: 115965
|
| |
|
|
|
|
|
|
|
|
|
| |
are not defined as returning EFLAGS (like add_flag and friends),
the entire multipattern and several of the subclasses need to be
cloned.
This could be handled through better instantiation support in tblgen,
but it isn't meta enough.
llvm-svn: 115964
|
| |
|
|
| |
llvm-svn: 115963
|
| |
|
|
| |
llvm-svn: 115957
|
| |
|
|
| |
llvm-svn: 115952
|
| |
|
|
| |
llvm-svn: 115951
|
| |
|
|
| |
llvm-svn: 115950
|
| |
|
|
| |
llvm-svn: 115949
|