I can see with the original code was that I forgot that this runs after
type legalization and hence the result type will always be i32. (Custom
legalization of EXTRACT_VECTOR_ELT is only enabled for vector types with
8- and 16-bit elements.)
Regarding the FIXME comment: any information about sign and zero-extension
should be captured by separate extension operations. The DAG combiner should
handle those to produce either VGETLANEu or VGETLANEs, and that seems to be
working now. If there are cases that we're missing, let me know.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84218 91177308-0d34-0410-b5e6-96231b3b80d8
1. Emit external function type information for all COFF targets since it's
a feature of object format
2. Emit linker directives only for cygming (since this is ld-specific stuff)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84214 91177308-0d34-0410-b5e6-96231b3b80d8
In the case where there are no good places to put constants and we fall back
upon inserting unconditional branches to make new blocks, allow all constant
pool references in range of those blocks to put constants there, even if that
means resetting the "high water marks" for those references. This will still
terminate because you can't keep splitting blocks forever, and in the bad
cases where we have to split blocks, it is important to avoid splitting more
than necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84202 91177308-0d34-0410-b5e6-96231b3b80d8
as expressions, code for parsing a few arm specific directives (still needs
the MCStreamer calls for these). Some clean up of the operand parsing code
and adding some comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84201 91177308-0d34-0410-b5e6-96231b3b80d8
When ARMConstantIslandPass cannot find any good locations (i.e., "water") to
place constants, it falls back to inserting unconditional branches to make a
place to put them. My recent change exposed a problem in this area. We may
sometimes append to the same block more than one unconditional branch. The
symptoms of this are that the generated assembly has a branch to an undefined
label and running llc with -debug will cause a seg fault.
This happens more easily since my change to prevent CPEs from moving from
lower to higher addresses as the algorithm iterates, but it could have
happened before. The end of the block may be in range for various constant
pool references, but the insertion point for new CPEs is not right at the end
of the block -- it is at the end of the CPEs that have already been placed
at the end of the block. The insertion point could be out of range. When
that happens, the fallback code will always append another unconditional
branch if the end of the block is in range.
The fix is to only append an unconditional branch if the block does not
already end with one. I also removed a check to see if the constant pool load
instruction is at the end of the block, since that is redundant with
checking if the end of the block is in-range.
There is more to be done here, but I think this fixes the immediate problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84172 91177308-0d34-0410-b5e6-96231b3b80d8
(for uses marked kill and defs marked dead) a few instructions in
addition to forwards. Also, increase the maximum number of instructions
to scan, as it appears to help in a fair number of cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84061 91177308-0d34-0410-b5e6-96231b3b80d8
Also fixed a couple of coding style things that crept in. And added more
to the temporary hacked up ARMAsmParser::MatchInstruction() method for testing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84040 91177308-0d34-0410-b5e6-96231b3b80d8
multiple instructions, the expansion is done during selection so there is
no need to do anything special during legalization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84036 91177308-0d34-0410-b5e6-96231b3b80d8
be in a register. The previous use of ARM address mode 2 was completely
arbitrary and inappropriate for Thumb. Radar 7137468.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84022 91177308-0d34-0410-b5e6-96231b3b80d8
before its reference is only supported on ARM has not been true for a while.
In fact, until recently, that was only supported for Thumb. Besides that,
CPEs are always a multiple of 4 bytes in size, so inserting a CPE should have
no effect on Thumb alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83916 91177308-0d34-0410-b5e6-96231b3b80d8
