| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Just treat it as if the constituent D registers where specified.
rdar://10348896
llvm-svn: 143167
|
| |
|
|
| |
llvm-svn: 143164
|
| |
|
|
|
|
| |
previously.
llvm-svn: 143162
|
| |
|
|
|
|
|
| |
Previously, we were only setting the alignment bits on over-aligned
loads and stores.
llvm-svn: 143160
|
| |
|
|
| |
llvm-svn: 143158
|
| |
|
|
|
|
| |
relocation address, and we don't find a symbol table entry, try section begin addresses as well.
llvm-svn: 143151
|
| |
|
|
| |
llvm-svn: 143145
|
| |
|
|
|
|
| |
and x86_64 TLV relocations in MachO.
llvm-svn: 143140
|
| |
|
|
| |
llvm-svn: 143135
|
| |
|
|
|
|
|
|
|
|
|
| |
using BinaryOperator (which only works for instructions) when it should have
been a cast to OverflowingBinaryOperator (which also works for constants).
While there, correct a few other dubious looking uses of BinaryOperator.
Thanks to Chad Rosier for the testcase. Original commit message:
My super-optimizer noticed that we weren't folding this expression to
true: (x *nsw x) sgt 0, where x = (y | 1). This occurs in 464.h264ref.
llvm-svn: 143125
|
| |
|
|
|
|
|
| |
not depend on In32BitMode. Use the sysexitq mnemonic for the version with the
REX.W prefix and only allow it only In64BitMode. rdar://9738584
llvm-svn: 143112
|
| |
|
|
|
|
| |
rdar://10348844
llvm-svn: 143110
|
| |
|
|
| |
llvm-svn: 143109
|
| |
|
|
|
|
| |
rdar://10348584
llvm-svn: 143108
|
| |
|
|
| |
llvm-svn: 143107
|
| |
|
|
|
|
| |
This trades one 64 bit div for one 64 bit mul and some arithmetic.
llvm-svn: 143106
|
| |
|
|
|
|
| |
behind a compile failure on 483.xalancbmk.
llvm-svn: 143102
|
| |
|
|
| |
llvm-svn: 143101
|
| |
|
|
| |
llvm-svn: 143097
|
| |
|
|
| |
llvm-svn: 143095
|
| |
|
|
|
|
| |
don't do that. <rdar://problem/10352360>
llvm-svn: 143093
|
| |
|
|
| |
llvm-svn: 143086
|
| |
|
|
| |
llvm-svn: 143080
|
| |
|
|
|
|
|
|
| |
up. Thus, improving the support for compares is goodness because it increases
the number of terminator instructions we can handle. This creates many more
opportunities for target specific fast-isel.
llvm-svn: 143079
|
| |
|
|
|
|
| |
place. No functional change intended.
llvm-svn: 143078
|
| |
|
|
| |
llvm-svn: 143076
|
| |
|
|
|
|
| |
change.
llvm-svn: 143074
|
| |
|
|
|
|
| |
SelectBranch. No functional change intended.
llvm-svn: 143072
|
| |
|
|
| |
llvm-svn: 143071
|
| |
|
|
|
|
|
|
|
| |
We were parsing label references to the i12 encoding, which isn't right.
They need to go to the pci variant instead.
More of rdar://10348687
llvm-svn: 143068
|
| |
|
|
|
|
| |
Patch by Sanjoy Das.
llvm-svn: 143064
|
| |
|
|
|
|
| |
Partial fix for rdar://10348687.
llvm-svn: 143063
|
| |
|
|
|
|
|
|
|
|
|
|
| |
MORESTACK_RET_RESTORE_R10; which are lowered to a RET and a RET
followed by a MOV respectively. Having a fake instruction prevents
the verifier from seeing a MachineBasicBlock end with a
non-terminator (MOV). It also prevents the rather eccentric case of a
MachineBasicBlock ending with RET but having successors nevertheless.
Patch by Sanjoy Das.
llvm-svn: 143062
|
| |
|
|
| |
llvm-svn: 143055
|
| |
|
|
|
|
| |
in 403.gcc and was spotted by my super-optimizer.
llvm-svn: 143054
|
| |
|
|
| |
llvm-svn: 143051
|
| |
|
|
|
|
| |
composed of one byte characters.
llvm-svn: 143044
|
| |
|
|
|
|
| |
is reversed from what seems intuitive to me.
llvm-svn: 143035
|
| |
|
|
| |
llvm-svn: 143034
|
| |
|
|
|
|
| |
relocations, so that we can recognize scattered relocations.
llvm-svn: 143033
|
| |
|
|
|
|
| |
require 33 bits of type info.
llvm-svn: 143032
|
| |
|
|
| |
llvm-svn: 143031
|
| |
|
|
|
|
| |
true: (x *nsw x) sgt 0, where x = (y | 1). This occurs in 464.h264ref.
llvm-svn: 143028
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
trying to legalize the operand types when only the result type
is required to be legalized - the type legalization machinery
will get round to the operands later if they need legalizing.
There can be a point to legalizing operands in parallel with
the result: when this saves compile time or results in better
code. There was only one case in which this was true: when
the operand is also split, so keep the logic for that bit.
As a result of this change, additional operand legalization
methods may need to be introduced to handle nodes where the
result and operand types can differ, like SIGN_EXTEND, but
the testsuite doesn't contain any tests where this is the case.
In any case, it seems better to require such methods (and die
with an assert if they doesn't exist) than to quietly produce
wrong code if we forgot to special case the node in
SplitVecRes_UnaryOp.
llvm-svn: 143026
|
| |
|
|
|
|
| |
llvm-commits regarding exactly how much optsize should optimize for size over performance.
llvm-svn: 143023
|
| |
|
|
|
|
| |
the 'removeSuccessor' call. Noticed in a Release+Asserts+Check buildbot.
llvm-svn: 143018
|
| |
|
|
| |
llvm-svn: 143011
|
| |
|
|
|
|
|
|
|
|
|
| |
This code makes different decisions when compiled into x87 instructions
because of different rounding behavior. That caused phase 2/3
miscompares on 32-bit Linux when the phase 1 compiler was built with gcc
(using x87), and the phase 2 compiler was built with clang (using SSE).
This fixes PR11200.
llvm-svn: 143006
|
| |
|
|
|
|
| |
Devang has fixed other issues.
llvm-svn: 143003
|
| |
|
|
|
|
|
| |
on Darwin platforms where -Os means optimize for size without hurting
performance.
llvm-svn: 143002
|