| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 27286
|
|
|
|
| |
llvm-svn: 27263
|
|
|
|
|
|
|
|
| |
value. Split them into separate enums.
Also, don't emit dynamic checks when we can compute them statically
llvm-svn: 27202
|
|
|
|
|
|
|
|
|
| |
tblgen: In STVEBX: Intrinsic 'llvm.ppc.altivec.stvebx' expects 3 operands, not 2 operands!
instead of like this:
tblgen: In STVEBX: Intrinsic 'intrinsic_void expects 3 operands, not 2 operands!
llvm-svn: 27185
|
|
|
|
| |
llvm-svn: 27126
|
|
|
|
|
|
|
|
|
|
| |
Cannot yet select: intrinsic %llvm.ppc.altivec.lvx
instead of this:
Cannot yet select: 0x9b047e0: v4i32,ch = INTRINSIC 0x9b04540:1, 0x9b04710, 0x9b04790, 0x9b04540
llvm-svn: 27110
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
intrinsics that don't take pointer arguments now work. For example, we can
compile this:
int test3( __m128d *A) {
return _mm_movemask_pd(*A);
}
int test4( __m128 *A) {
return _mm_movemask_ps(*A);
}
to this:
_test3:
movl 4(%esp), %eax
movapd (%eax), %xmm0
movmskpd %xmm0, %eax
ret
_test4:
movl 4(%esp), %eax
movaps (%eax), %xmm0
movmskps %xmm0, %eax
ret
llvm-svn: 27090
|
|
|
|
| |
llvm-svn: 27084
|
|
|
|
|
|
| |
emit the code to select intrinsics, but that is next :)
llvm-svn: 27082
|
|
|
|
|
|
|
| |
like this:
def : Pat<(v4i32 (bitconvert (v4f32 VR128:$src))), (v4i32 VR128:$src)>;
llvm-svn: 26968
|
|
|
|
|
|
| |
patterns.
llvm-svn: 26929
|
|
|
|
| |
llvm-svn: 26918
|
|
|
|
|
|
| |
one, i.e. don't select it.
llvm-svn: 26909
|
|
|
|
| |
llvm-svn: 26899
|
|
|
|
|
|
|
| |
The instruction patterns do not contain enough information to resolve the
exact type of the destination if it of a generic vector type.
llvm-svn: 26892
|
|
|
|
| |
llvm-svn: 26890
|
|
|
|
|
|
|
| |
it possible when a TokenFactor is between the load and store. But is still
missing some cases due to ordering issue.
llvm-svn: 26638
|
|
|
|
|
|
|
|
|
|
|
|
| |
if (N1.getOpcode() == ISD::ADD &&
...)
if (... &&
(N1.getNumOperands() == 1 || !isNonImmUse(N1.Val, N10.Val))) &&
...)
TableGen knows N1 must have more than one operand.
llvm-svn: 26592
|
|
|
|
| |
llvm-svn: 26349
|
|
|
|
|
|
| |
usesCustomDAGSchedInserter.
llvm-svn: 26282
|
|
|
|
|
|
| |
aggrssive inlining. This reduces Select_store frame size from 24k to 10k.
llvm-svn: 26095
|
|
|
|
| |
llvm-svn: 26084
|
|
|
|
|
|
|
|
| |
SDOperand Select(SDOperand N);
to
void Select(SDOperand &Result, SDOperand N);
llvm-svn: 26067
|
|
|
|
|
|
| |
to reduce stack memory usage. This is intended to work around the gcc bug.
llvm-svn: 26026
|
|
|
|
|
|
|
| |
have one. This can happen if a load's real uses are dead (i.e. they do not
have uses themselves).
llvm-svn: 26014
|
|
|
|
| |
llvm-svn: 26013
|
|
|
|
| |
llvm-svn: 26011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
due to ordering issue. i.e. they were selected for chain use first.
Now at load select time, check if it is being selected for a chain use and if
it has only a single real use. If so, return a HANDLENODE (with the load as
its operand) in its place and record it.
When it is folded or the load is selected for a real use, the isel records it
as the replacement for the HANDLENODE. The replacement is done when all nodes
are selected.
This scheme exposed a couple of problems where cycles can happen. (See comments
in EmitMatchCode() for descriptions of the problems and their workaround /
solutions.) These problems have been resolved with a small compile time
penality.
llvm-svn: 25995
|
|
|
|
| |
llvm-svn: 25982
|
|
|
|
|
|
| |
DO select things.
llvm-svn: 25970
|
|
|
|
|
|
| |
Select them afterwards if it returns true.
llvm-svn: 25968
|
|
|
|
|
|
|
| |
X86 backend attempts to match small-immediate versions of instructions before
the full size immediate versions.
llvm-svn: 25937
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Chain is initially set to the chain operand of store node, when it reaches
load, if it matches the load then Chain is set to the chain operand of the
load.
However, if the matching code that follows this fails, isel moves on to the
next pattern but it does not restore Chain to the chain operand of the store.
So when it tries to match the next store / op / load pattern it would fail on
the Chain == load.getOperand(0) test.
The solution is for each chain operand to get a unique name. e.g. Chain10.
llvm-svn: 25931
|
|
|
|
| |
llvm-svn: 25870
|
|
|
|
| |
llvm-svn: 25791
|
|
|
|
| |
llvm-svn: 25766
|
|
|
|
| |
llvm-svn: 25765
|
|
|
|
| |
llvm-svn: 25764
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if (N1.getOpcode() == ISD::LOAD &&
N1.hasOneUse() &&
!CodeGenMap.count(N1.getValue(0)) &&
!CodeGenMap.count(N1.getValue(1))) {
instead of this:
if (N1.getOpcode() == ISD::LOAD) {
if (N1.hasOneUse()) {
if (!CodeGenMap.count(N1.getValue(0))) {
if (!CodeGenMap.count(N1.getValue(1))) {
llvm-svn: 25763
|
|
|
|
|
|
|
| |
GCC not jump-threading across this common code, and produces far nicer
output.
llvm-svn: 25762
|
|
|
|
| |
llvm-svn: 25759
|
|
|
|
| |
llvm-svn: 25758
|
|
|
|
|
|
|
|
|
| |
"if" statements (indenting it appropriately, of course) instead of using goto's.
This inverts the logic for all of the if statements, which makes things simpler
to understand in addition to making the generated code easier to read.
llvm-svn: 25757
|
|
|
|
|
|
|
|
| |
directly to the output file. This makes things simple because the code doesn't
have to worry about indentation or the case when there is no goto. It also
allows us to indent the code better without touching everything :)
llvm-svn: 25756
|
|
|
|
| |
llvm-svn: 25752
|
|
|
|
| |
llvm-svn: 25709
|
|
|
|
|
|
|
| |
If store's chain operand is load, then use load's chain operand instead. If
it isn't (likely a TokenFactor), then do not allow the folding.
llvm-svn: 25708
|
|
|
|
|
|
| |
Aren't we happy the pattern selectors are almost all gone?
llvm-svn: 25666
|
|
|
|
|
|
|
|
|
| |
has already been selected. The number of use check is not strong enough since
a node can be replaced with newly created target node. e.g. If the original
node has two uses, when it is selected for one of the uses it is replaced with
another. Each node now has a single use but isel still should not fold it.
llvm-svn: 25651
|
|
|
|
| |
llvm-svn: 25635
|