in the start of an array and a count of operands where applicable. In many
cases, the number of operands is known, so this static array can be allocated
on the stack, avoiding the heap. In many other cases, a SmallVector can be
used, which has the same benefit in the common cases.
I updated a lot of code calling getNode that takes a vector, but ran out of
time. The rest of the code should be updated, and these methods should be
removed.
We should also do the same thing to eliminate the methods that take a
vector of MVT::ValueTypes.
It would be extra nice to convert the dagiselemitter to avoid creating vectors
for operands when calling getTargetNode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29566 91177308-0d34-0410-b5e6-96231b3b80d8
per possible ValueType of the node. e.g. Select_add is split into Select_add_i8,
Select_add_i16, etc.
For opcodes which do not produce a non-chain result, it is split on the
ValueType of its first non-chain operand. e.g. Select_store.
On X86 / Mac OS X, Select_store used to be the largest function. It had a stack
frame size of 8.5k. Now the largest one is Store_i32 with a frame size of 3.1k.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29404 91177308-0d34-0410-b5e6-96231b3b80d8
code that emit target specific nodes into emit functions that are uniquified
and shared among selection routines.
e.g. This reduces X86ISelDAGToDAG.o (release) from ~2M to ~1.5M. Stack frame
size of Select_store from ~13k down to ~8k.
This is the first step. Further work to enable more sharing will follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29158 91177308-0d34-0410-b5e6-96231b3b80d8
RemoveInFlightSetEntry. They are used in place of direct set operators to
reduce instruction selection function stack size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28987 91177308-0d34-0410-b5e6-96231b3b80d8
because information about one can help refine the other. This allows us to
write:
def : Pat<(i32 (extload xaddr:$src, i8)),
(LBZX xaddr:$src)>;
as:
def : Pat<(extload xaddr:$src, i8),
(LBZX xaddr:$src)>;
because tblgen knows LBZX returns i32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28865 91177308-0d34-0410-b5e6-96231b3b80d8
instruction, and the result type of the instruction to refine the pattern.
This allows us to write things like this:
def : Pat<(v2i64 (bitconvert (v16i8 VR128:$src))), (v2i64 VR128:$src)>;
as:
def : Pat<(v2i64 (bitconvert (v16i8 VR128:$src))), (VR128:$src)>
and fixes a ppc64 issue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28863 91177308-0d34-0410-b5e6-96231b3b80d8
a cycle. This increase the search space and will increase compile time (in
practice it appears to be small, e.g. 176.gcc goes from 62 sec to 65 sec)
that will be addressed later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28476 91177308-0d34-0410-b5e6-96231b3b80d8
correctly. That is causing non-deterministic behavior (and possibly preventing
some load folding from happening).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28458 91177308-0d34-0410-b5e6-96231b3b80d8
patterns that look like this:
def : Pat<(i32 (X86Wrapper tconstpool :$dst)), (MOV32ri tconstpool :$dst)>;
InsertOneTypeCheck should copy the type from the resolved pattern to the
unresolved one as long as there types are different.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28389 91177308-0d34-0410-b5e6-96231b3b80d8
1. Use expects a chain output.
2. Node is expanded into multiple target ops.
3. One of the inner node produces a chain, the outer most one doesn't.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28209 91177308-0d34-0410-b5e6-96231b3b80d8
nodes should not be folded into other nodes.
This fixes the miscompilation of PR 749.
Temporarily under flag control.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28002 91177308-0d34-0410-b5e6-96231b3b80d8
x86 and ppc for 100% dense switch statements when relocations are non-PIC.
This support will be extended and enhanced in the coming days to support
PIC, and less dense forms of jump tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@27947 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@27185 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@27090 91177308-0d34-0410-b5e6-96231b3b80d8
The instruction patterns do not contain enough information to resolve the
exact type of the destination if it of a generic vector type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@26892 91177308-0d34-0410-b5e6-96231b3b80d8
it possible when a TokenFactor is between the load and store. But is still
missing some cases due to ordering issue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@26638 91177308-0d34-0410-b5e6-96231b3b80d8
if (N1.getOpcode() == ISD::ADD &&
...)
if (... &&
(N1.getNumOperands() == 1 || !isNonImmUse(N1.Val, N10.Val))) &&
...)
TableGen knows N1 must have more than one operand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@26592 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25995 91177308-0d34-0410-b5e6-96231b3b80d8
X86 backend attempts to match small-immediate versions of instructions before
the full size immediate versions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25937 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25931 91177308-0d34-0410-b5e6-96231b3b80d8
"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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25757 91177308-0d34-0410-b5e6-96231b3b80d8
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 :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25756 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25708 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25651 91177308-0d34-0410-b5e6-96231b3b80d8
