| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 170716
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is supposed to be a mechanical change with no functional effects.
InstrEmitter can generate all types of MachineOperands which revealed
that MachineInstrBuilder was missing a few methods, added by this patch.
Besides providing a context pointer to MI::addOperand(),
MachineInstrBuilder seems like a better fit for this code.
llvm-svn: 170712
|
| |
|
|
|
|
| |
<rdar://problem/12879313>
llvm-svn: 170630
|
| |
|
|
|
|
| |
Accordingly, add MVT::getVT.
llvm-svn: 170550
|
| |
|
|
| |
llvm-svn: 170540
|
| |
|
|
|
|
| |
instead of EVTs.
llvm-svn: 170538
|
| |
|
|
|
|
| |
MVTs, instead of EVTs.
llvm-svn: 170537
|
| |
|
|
|
|
| |
from EVT.
llvm-svn: 170536
|
| |
|
|
|
|
| |
EVTs.
llvm-svn: 170535
|
| |
|
|
|
|
| |
EVTs.
llvm-svn: 170534
|
| |
|
|
|
|
| |
of EVT.
llvm-svn: 170532
|
| |
|
|
|
|
| |
instead of EVTs.
llvm-svn: 170529
|
| |
|
|
| |
llvm-svn: 170524
|
| |
|
|
|
|
| |
EVT.
llvm-svn: 170522
|
| |
|
|
| |
llvm-svn: 170510
|
| |
|
|
| |
llvm-svn: 170506
|
| |
|
|
|
|
|
|
| |
bitwidth op back to the original size. If we reduce ANDs then this can cause
an endless loop. This patch changes the ZEXT to ANY_EXTEND if the demanded bits
are equal or smaller than the size of the reduced operation.
llvm-svn: 170505
|
| |
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170502
|
| |
|
|
| |
llvm-svn: 170497
|
| |
|
|
| |
llvm-svn: 170496
|
| |
|
|
|
|
| |
rewritten as a compare against a constant 0 with the opposite condition.
llvm-svn: 170495
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A register can be associated with several distinct register classes.
For example, on PPC, the floating point registers are each associated with
both F4RC (which holds f32) and F8RC (which holds f64). As a result, this code
would fail when provided with a floating point register and an f64 operand
because it would happen to find the register in the F4RC class first and
return that. From the F4RC class, SDAG would extract f32 as the register
type and then assert because of the invalid implied conversion between
the f64 value and the f32 register.
Instead, search all register classes. If a register class containing the
the requested register has the requested type, then return that register
class. Otherwise, as before, return the first register class found that
contains the requested register.
llvm-svn: 170436
|
| |
|
|
|
|
|
|
|
| |
TargetLowering::getRegClassFor).
Some isSimple() guards were missing, or getSimpleVT() were hoisted too
far, resulting in asserts on valid LLVM assembly input.
llvm-svn: 170336
|
| |
|
|
|
|
| |
EVT.
llvm-svn: 170183
|
| |
|
|
| |
llvm-svn: 170148
|
| |
|
|
|
|
|
|
| |
EVT.
Accordingly, change RegDefIter to contain MVTs instead of EVTs.
llvm-svn: 170140
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Accordingly, add helper funtions getSimpleValueType (in parallel to
getValueType) in SDValue, SDNode, and TargetLowering.
This is the first, in a series of patches.
This is the second attempt. In the first attempt (r169837), a few
getSimpleVT() were hoisted too far, detected by bootstrap failures.
llvm-svn: 170104
|
| |
|
|
|
|
| |
before referencing them. rdar://12868039
llvm-svn: 170078
|
| |
|
|
|
|
|
| |
load / store pair. It's not legal to use a wider load than the size of
the remaining bytes if it's the first pair of load / store.
llvm-svn: 170018
|
| |
|
|
|
|
|
|
|
|
|
|
| |
mention the inline memcpy / memset expansion code is a mess?
This patch split the ZeroOrLdSrc argument into two: IsMemset and ZeroMemset.
The first indicates whether it is expanding a memset or a memcpy / memmove.
The later is whether the memset is a memset of zero. It's totally possible
(likely even) that targets may want to do different things for memcpy and
memset of zero.
llvm-svn: 169959
|
| |
|
|
|
|
|
|
|
| |
Also added more comments to explain why it is generally ok to return true.
- Rename getOptimalMemOpType argument IsZeroVal to ZeroOrLdSrc. It's meant to
be true for loaded source (memcpy) or zero constants (memset). The poor name
choice is probably some kind of legacy issue.
llvm-svn: 169954
|
| |
|
|
|
|
| |
rdar://12838504
llvm-svn: 169951
|
| |
|
|
|
|
| |
f64 load / store on non-SSE2 x86 targets.
llvm-svn: 169944
|
| |
|
|
|
|
|
|
|
| |
ScalarTargetTransformInfo::getIntImmCost() instead. "Legal" is a poorly defined
term for something like integer immediate materialization. It is always possible
to materialize an integer immediate. Whether to use it for memcpy expansion is
more a "cost" conceern.
llvm-svn: 169929
|
| |
|
|
| |
llvm-svn: 169854
|
| |
|
|
|
|
| |
instead of EVTs.
llvm-svn: 169851
|
| |
|
|
|
|
|
|
| |
MVTs, instead of EVTs.
Accordingly, add bitsLT (and similar) to MVT.
llvm-svn: 169850
|
| |
|
|
|
|
| |
from EVT.
llvm-svn: 169849
|
| |
|
|
|
|
| |
EVTs.
llvm-svn: 169848
|
| |
|
|
|
|
| |
EVTs.
llvm-svn: 169847
|
| |
|
|
|
|
| |
of EVT.
llvm-svn: 169845
|
| |
|
|
|
|
| |
instead of EVTs.
llvm-svn: 169844
|
| |
|
|
| |
llvm-svn: 169843
|
| |
|
|
|
|
| |
EVT.
llvm-svn: 169842
|
| |
|
|
| |
llvm-svn: 169841
|
| |
|
|
| |
llvm-svn: 169840
|
| |
|
|
| |
llvm-svn: 169839
|
| |
|
|
|
|
|
|
| |
EVT.
Accordingly, change RegDefIter to contain MVTs instead of EVTs.
llvm-svn: 169838
|
| |
|
|
|
|
|
|
|
| |
Accordingly, add helper funtions getSimpleValueType (in parallel to
getValueType) in SDValue, SDNode, and TargetLowering.
This is the first, in a series of patches.
llvm-svn: 169837
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
try to reduce the width of this load, and would end up transforming:
(truncate (lshr (sextload i48 <ptr> as i64), 32) to i32)
to
(truncate (zextload i32 <ptr+4> as i64) to i32)
We lost the sext attached to the load while building the narrower i32
load, and replaced it with a zext because lshr always zext's the
results. Instead, bail out of this combine when there is a conflict
between a sextload and a zext narrowing. The rest of the DAG combiner
still optimize the code down to the proper single instruction:
movswl 6(...),%eax
Which is exactly what we wanted. Previously we read past the end *and*
missed the sign extension:
movl 6(...), %eax
llvm-svn: 169802
|