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.
llvm-svn: 27947
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
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
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
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
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
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
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
"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
Evan Cheng