31ea2f14bc
Triple::MinGW64 is deprecated and removed. We can use Triple::MinGW32 instead.
...
No one uses *-mingw64. mingw-w64 is represented as {i686|x86_64}-w64-mingw32.
llvm-svn: 125742
2011-02-17 08:51:38 +00:00
029d74b264
Fix whitespace.
...
llvm-svn: 125741
2011-02-17 08:50:50 +00:00
24f1d3e60a
Add NetBSD target support. Patch by Joerg Sonnenberger.
...
llvm-svn: 124736
2011-02-02 18:59:27 +00:00
e03c603624
lib/CodeGen/TargetInfo.cpp: Fix coding style and erase an obsolete comment.
...
llvm-svn: 123790
2011-01-19 00:11:33 +00:00
bd91f50190
lib/CodeGen/TargetInfo.cpp: Add Win64 calling conversion.
...
FIXME: It would be incompatible to Microsoft's in one point.
On mingw64-gcc, {i128} is expanded for args and returned as {rax, rdx}.
llvm-svn: 123692
2011-01-17 22:56:31 +00:00
b9fa00e0c2
Remove special handling for opaque Neon vector types.
...
Clang does not wrap the vectors in structs anymore so this isn't needed.
llvm-svn: 123241
2011-01-11 16:53:49 +00:00
bd4520b535
Move DefaultABIInfo::classifyReturnType where it belongs. No functional change.
...
llvm-svn: 123195
2011-01-10 23:54:17 +00:00
36a1f68fec
1. Add some ABI information for the Microblaze.
...
2. Add attibutes "interrupt_handler" and "save_volatiles" for the Microblaze target.
llvm-svn: 122184
2010-12-19 19:57:51 +00:00
8c173cc364
Use a twine.
...
llvm-svn: 118892
2010-11-12 15:42:18 +00:00
fd88a6160d
Rename getBaseClassOffset to getBaseClassOffsetInBits and introduce a getBaseClassOffset which returns the offset in CharUnits. Do the same thing for getVBaseClassOffset.
...
llvm-svn: 117881
2010-10-31 23:22:37 +00:00
f5a1fbcdf3
Fix Whitespace.
...
llvm-svn: 116798
2010-10-19 06:39:39 +00:00
9987c0ea42
We shouldn't keep track of MMX registers "needed" separately from the SSE
...
registers needed.
llvm-svn: 116772
2010-10-18 23:51:38 +00:00
5cd41c4b13
Reapply r116684 with fixes. The test cases needed to be updated.
...
llvm-svn: 116696
2010-10-18 03:41:31 +00:00
c7c9be661f
Temporarily revert r116684. It was causing failures with
...
Clang :: CodeGen/x86_32-arguments-darwin.c
Clang :: CodeGen/x86_32-arguments-linux.c
llvm-svn: 116687
2010-10-17 07:58:46 +00:00
812f4b123e
The "gcc.dg/compat/vector-1 -m32" test was broken after the MMX rewrite. The
...
function parameters weren't converted to use the correct type (x86_mmx). Add a
check, similar to the one in llvm-gcc, to see if we need the x86_mmx type for
that function parameter. If so, it coerces the type to be that.
llvm-svn: 116684
2010-10-17 07:38:01 +00:00
a09e8efd1f
Per discussion with Sanjiv, remove the PIC16 target from mainline. When/if
...
it comes back, it will be largely a rewrite, so keeping the old codebase
in tree isn't helping anyone.
llvm-svn: 116191
2010-10-11 05:44:49 +00:00
19964dbe3b
IRgen/ABI/ARM: Return large vectors in memory.
...
llvm-svn: 114619
2010-09-23 01:54:32 +00:00
b34b08098c
IRgen/ABI/ARM: Trust the backend to pass vectors correctly for the given ABI.
...
- Therefore, we can lower out the NEON wrapper structs and pass the vectors
directly. This makes a huge difference in the cleanliness of the IR after
optimization.
- I will trust, but verify, via future ABITest testing (for APCS-GNU, at
least).
llvm-svn: 114618
2010-09-23 01:54:28 +00:00
dd38fbc7fb
IRgen/ABI/x86-32: Realign indirect arguments when the ABI requires us to pass
...
them with a smaller alignment than the rest of codegen expects.
llvm-svn: 114115
2010-09-16 20:42:06 +00:00
7b7c2937ef
IRgen/ABI: Add support for realigning structures which are passed by indirect
...
reference.
llvm-svn: 114114
2010-09-16 20:42:02 +00:00
ed23de3348
IRgen/ABI/x86_32/Darwin: On Darwin, only structures with SSE vector types get passed
...
with a non-default-stack-ABI-alignment (of 16).
- This fixes the ABI convenient, but breaks codegen since we now have
underaligned arguments. Marginal improvement overall though, and will be
fixed in next commit.
llvm-svn: 114113
2010-09-16 20:42:00 +00:00
8a6c91ff76
IRgen/x86_32/Linux: Linux seems to align all stack objects to 4 bytes, unlike
...
Darwin. Checked vs the handiest Linux llvm-gcc I had around, someone on Linux is
welcome to investigate more.
llvm-svn: 114112
2010-09-16 20:41:56 +00:00
d426c8eae3
fix rdar://8360877 a really nasty miscompilation in Boost.Xpressive
...
caused by my ABI work. Passing:
struct outer {
int x;
struct epsilon_matcher {} e;
int f;
};
as {i32,i32} isn't safe, because the offset of the second element
needs to be at 8 when it is interpreted as a memory value.
llvm-svn: 112686
2010-09-01 00:50:20 +00:00
be5eb17536
same refactoring as before, this time on the argument side.
...
llvm-svn: 112684
2010-09-01 00:24:35 +00:00
52b3c13149
refactor some code to cut down on redundancy, no functionality change.
...
llvm-svn: 112683
2010-09-01 00:20:33 +00:00
04dc957260
Add support for windows x86-64 varargs, patch by Cameron Esfahani!
...
llvm-svn: 112603
2010-08-31 16:44:54 +00:00
a48fbe8c53
Fix PR8029, a x86-32 ABI regression in introduced in r112211
...
llvm-svn: 112537
2010-08-30 22:03:23 +00:00
d7e54804ee
improve comments.
...
llvm-svn: 112214
2010-08-26 20:08:43 +00:00
d774ae9ed1
fix 2xi16 to pass as i32 instead of <2 x i16>. The former passes in
...
memory (as required) the later now passes in an xmm register. This
fixes gcc.dg/compat/vector_1 on x86-32.
llvm-svn: 112211
2010-08-26 20:05:13 +00:00
69e683fb35
vector of long and ulong are also classified as INTEGER in x86-64 abi,
...
this fixes rdar://8358475 a failure of the gcc.dg/compat/vector_1 abi
test.
llvm-svn: 112205
2010-08-26 18:13:50 +00:00
46830f2fd6
1 x ulonglong needs to be classified as INTEGER, just like 1 x longlong,
...
this fixes a miscompilation on the included testcase, rdar://8359248
llvm-svn: 112201
2010-08-26 18:03:20 +00:00
51e1cc2fe2
tame an assertion, fixing rdar://8357396
...
llvm-svn: 112174
2010-08-26 06:28:35 +00:00
9f8b451876
Finally pass "two floats in a 64-bit unit" as a <2 x float> instead of
...
as a double in the x86-64 ABI. This allows us to generate much better
code for certain things, e.g.:
_Complex float f32(_Complex float A, _Complex float B) {
return A+B;
}
Used to compile into (look at the integer silliness!):
_f32: ## @f32
## BB#0: ## %entry
movd %xmm1, %rax
movd %eax, %xmm1
movd %xmm0, %rcx
movd %ecx, %xmm0
addss %xmm1, %xmm0
movd %xmm0, %edx
shrq $32, %rax
movd %eax, %xmm0
shrq $32, %rcx
movd %ecx, %xmm1
addss %xmm0, %xmm1
movd %xmm1, %eax
shlq $32, %rax
addq %rdx, %rax
movd %rax, %xmm0
ret
Now we get:
_f32: ## @f32
movdqa %xmm0, %xmm2
addss %xmm1, %xmm2
pshufd $16, %xmm2, %xmm2
pshufd $1, %xmm1, %xmm1
pshufd $1, %xmm0, %xmm0
addss %xmm1, %xmm0
pshufd $16, %xmm0, %xmm1
movdqa %xmm2, %xmm0
unpcklps %xmm1, %xmm0
ret
and compile stuff like:
extern float _Complex ccoshf( float _Complex ) ;
float _Complex ccosf ( float _Complex z ) {
float _Complex iz;
(__real__ iz) = -(__imag__ z);
(__imag__ iz) = (__real__ z);
return ccoshf(iz);
}
into:
_ccosf: ## @ccosf
## BB#0: ## %entry
pshufd $1, %xmm0, %xmm1
xorps LCPI4_0(%rip), %xmm1
unpcklps %xmm0, %xmm1
movaps %xmm1, %xmm0
jmp _ccoshf ## TAILCALL
instead of:
_ccosf: ## @ccosf
## BB#0: ## %entry
movd %xmm0, %rax
movq %rax, %rcx
shlq $32, %rcx
shrq $32, %rax
xorl $-2147483648, %eax ## imm = 0xFFFFFFFF80000000
addq %rcx, %rax
movd %rax, %xmm0
jmp _ccoshf ## TAILCALL
There is still "stuff to be done" here for the struct case,
but this resolves rdar://6379669 - [x86-64 ABI] Pass and return
_Complex float / double efficiently
llvm-svn: 112111
2010-08-25 23:39:14 +00:00
b2f376bdd0
Fix horrible white space errors.
...
llvm-svn: 112067
2010-08-25 18:17:27 +00:00
a1dee5300b
Experiment with using first-class aggregates to represent member function
...
pointers. I find the resulting code to be substantially cleaner, and it
makes it very easy to use the same APIs for data member pointers (which I have
conscientiously avoided here), and it avoids a plethora of potential
inefficiencies due to excessive memory copying, but we'll have to see if it
actually works.
llvm-svn: 111776
2010-08-22 10:59:02 +00:00
8a2f3c778e
fix PR5179 and correctly fix PR5831 to not miscompile.
...
The X86-64 ABI code didn't handle the case when a struct
would get classified and turn up as "NoClass INTEGER" for
example. This is perfectly possible when the first slot
is all padding (e.g. due to empty base classes). In this
situation, the first 8-byte doesn't take a register at all,
only the second 8-byte does.
This fixes this by enhancing the x86-64 abi stuff to allow
and handle this case, reverts the broken fix for PR5831,
and enhances the target independent stuff to be able to
handle an argument value in registers being accessed at an
offset from the memory value.
This is the last x86-64 calling convention related miscompile
that I'm aware of.
llvm-svn: 109848
2010-07-30 04:02:24 +00:00
1f3a063f00
move the last hunk of getCoerceResult into the place
...
that needs it and remove getCoerceResult.
llvm-svn: 109807
2010-07-29 21:42:50 +00:00
60fbd7744f
now that direct and coerce are merged, getCoerceResult gets simpler.
...
llvm-svn: 109805
2010-07-29 21:29:53 +00:00
09794695ef
now that GetSSETypeAtOffset handles passing SSE class values as
...
float, the special case hack in getCoerceResult can go away.
llvm-svn: 109804
2010-07-29 21:22:50 +00:00
e556a71859
Implement the clang-side of detection for when to pass as
...
<2 x float> instead of double. This works but can't be turned
on until I teach codegen to pass <2 x float> as one XMM register
instead of two.
llvm-svn: 109790
2010-07-29 18:39:32 +00:00
50a357e962
Look at me, I can count!
...
llvm-svn: 109786
2010-07-29 18:19:50 +00:00
7f4b81af7a
fix rdar://8251384, another case where we could access beyond the
...
end of a struct. This improves the case when the struct being passed
contains 3 floats, either due to a struct or array of 3 things. Before
we'd generate this IR for the testcase:
define float @bar(double %X.coerce0, double %X.coerce1) nounwind {
entry:
%X = alloca %struct.foof, align 8 ; <%struct.foof*> [#uses=2]
%0 = bitcast %struct.foof* %X to %1* ; <%1*> [#uses=2]
%1 = getelementptr %1* %0, i32 0, i32 0 ; <double*> [#uses=1]
store double %X.coerce0, double* %1
%2 = getelementptr %1* %0, i32 0, i32 1 ; <double*> [#uses=1]
store double %X.coerce1, double* %2
%tmp = getelementptr inbounds %struct.foof* %X, i32 0, i32 2 ; <float*> [#uses=1]
%tmp1 = load float* %tmp ; <float> [#uses=1]
ret float %tmp1
}
which compiled (with optimization) to:
_bar: ## @bar
## BB#0: ## %entry
movd %xmm1, %rax
movd %eax, %xmm0
ret
Now we produce:
define float @bar(double %X.coerce0, float %X.coerce1) nounwind {
entry:
%X = alloca %struct.foof, align 8 ; <%struct.foof*> [#uses=2]
%0 = bitcast %struct.foof* %X to %0* ; <%0*> [#uses=2]
%1 = getelementptr %0* %0, i32 0, i32 0 ; <double*> [#uses=1]
store double %X.coerce0, double* %1
%2 = getelementptr %0* %0, i32 0, i32 1 ; <float*> [#uses=1]
store float %X.coerce1, float* %2
%tmp = getelementptr inbounds %struct.foof* %X, i32 0, i32 2 ; <float*> [#uses=1]
%tmp1 = load float* %tmp ; <float> [#uses=1]
ret float %tmp1
}
and:
_bar: ## @bar
## BB#0: ## %entry
movaps %xmm1, %xmm0
ret
llvm-svn: 109776
2010-07-29 18:13:09 +00:00
c95a398947
start setting up infrastructure for passing multi-floats
...
as <2 x float> instead of as double. The backend isn't ready
yet, but infrastructure in the frontend can come up.
llvm-svn: 109768
2010-07-29 17:49:08 +00:00
1c56d9ab56
rename Get8ByteTypeAtOffset -> GetINTEGERTypeAtOffset to
...
make it clear that this function should only return a type
that the codegen will classify the same as an INTEGER type.
llvm-svn: 109763
2010-07-29 17:40:35 +00:00
3f76342cfc
handle a case where we could access off the end of a function
...
that Eli pointed out, rdar://8249586
llvm-svn: 109762
2010-07-29 17:34:39 +00:00
cd84084f02
fix PR7742 / rdar://8250764, a miscompilation of struct
...
return where the struct has a base but no fields. This
was because the x86-64 abi logic was checking the wrong
predicate in one place.
This was introduced in r91874, which was a fix for PR5831,
which lacked a CHECK line, so I verified and added it.
llvm-svn: 109759
2010-07-29 17:04:54 +00:00
98076a25ce
This is a little bit far, but optimize cases like:
...
struct a {
struct c {
double x;
int y;
} x[1];
};
void foo(struct a A) {
}
into:
define void @foo(double %A.coerce0, i32 %A.coerce1) nounwind {
entry:
%A = alloca %struct.a, align 8 ; <%struct.a*> [#uses=1]
%0 = bitcast %struct.a* %A to %struct.c* ; <%struct.c*> [#uses=2]
%1 = getelementptr %struct.c* %0, i32 0, i32 0 ; <double*> [#uses=1]
store double %A.coerce0, double* %1
%2 = getelementptr %struct.c* %0, i32 0, i32 1 ; <i32*> [#uses=1]
store i32 %A.coerce1, i32* %2
instead of:
define void @foo(double %A.coerce0, i64 %A.coerce1) nounwind {
entry:
%A = alloca %struct.a, align 8 ; <%struct.a*> [#uses=1]
%0 = bitcast %struct.a* %A to %0* ; <%0*> [#uses=2]
%1 = getelementptr %0* %0, i32 0, i32 0 ; <double*> [#uses=1]
store double %A.coerce0, double* %1
%2 = getelementptr %0* %0, i32 0, i32 1 ; <i64*> [#uses=1]
store i64 %A.coerce1, i64* %2
I only do this now because I never want to look at this code again :)
llvm-svn: 109738
2010-07-29 07:43:55 +00:00
c8b7b53a1e
implement a todo: pass a eight-byte that consists of a
...
small integer + padding as that small integer. On code
like:
struct c { double x; int y; };
void bar(struct c C) { }
This means that we compile to:
define void @bar(double %C.coerce0, i32 %C.coerce1) nounwind {
entry:
%C = alloca %struct.c, align 8 ; <%struct.c*> [#uses=2]
%0 = getelementptr %struct.c* %C, i32 0, i32 0 ; <double*> [#uses=1]
store double %C.coerce0, double* %0
%1 = getelementptr %struct.c* %C, i32 0, i32 1 ; <i32*> [#uses=1]
store i32 %C.coerce1, i32* %1
instead of:
define void @bar(double %C.coerce0, i64 %C.coerce1) nounwind {
entry:
%C = alloca %struct.c, align 8 ; <%struct.c*> [#uses=3]
%0 = bitcast %struct.c* %C to %0* ; <%0*> [#uses=2]
%1 = getelementptr %0* %0, i32 0, i32 0 ; <double*> [#uses=1]
store double %C.coerce0, double* %1
%2 = getelementptr %0* %0, i32 0, i32 1 ; <i64*> [#uses=1]
store i64 %C.coerce1, i64* %2
which gives SRoA heartburn.
This implements rdar://5711709, a nice low number :)
llvm-svn: 109737
2010-07-29 07:30:00 +00:00
fe34c1d53e
Kill off the 'coerce' ABI passing form. Now 'direct' and 'extend' always
...
have a "coerce to" type which often matches the default lowering of Clang
type to LLVM IR type, but the coerce case can be handled by making them
not be the same.
This simplifies things and fixes issues where X86-64 abi lowering would
return coerce after making preferred types exactly match up. This caused
us to compile:
typedef float v4f32 __attribute__((__vector_size__(16)));
v4f32 foo(v4f32 X) {
return X+X;
}
into this code at -O0:
define <4 x float> @foo(<4 x float> %X.coerce) nounwind {
entry:
%retval = alloca <4 x float>, align 16 ; <<4 x float>*> [#uses=2]
%coerce = alloca <4 x float>, align 16 ; <<4 x float>*> [#uses=2]
%X.addr = alloca <4 x float>, align 16 ; <<4 x float>*> [#uses=3]
store <4 x float> %X.coerce, <4 x float>* %coerce
%X = load <4 x float>* %coerce ; <<4 x float>> [#uses=1]
store <4 x float> %X, <4 x float>* %X.addr
%tmp = load <4 x float>* %X.addr ; <<4 x float>> [#uses=1]
%tmp1 = load <4 x float>* %X.addr ; <<4 x float>> [#uses=1]
%add = fadd <4 x float> %tmp, %tmp1 ; <<4 x float>> [#uses=1]
store <4 x float> %add, <4 x float>* %retval
%0 = load <4 x float>* %retval ; <<4 x float>> [#uses=1]
ret <4 x float> %0
}
Now we get:
define <4 x float> @foo(<4 x float> %X) nounwind {
entry:
%X.addr = alloca <4 x float>, align 16 ; <<4 x float>*> [#uses=3]
store <4 x float> %X, <4 x float>* %X.addr
%tmp = load <4 x float>* %X.addr ; <<4 x float>> [#uses=1]
%tmp1 = load <4 x float>* %X.addr ; <<4 x float>> [#uses=1]
%add = fadd <4 x float> %tmp, %tmp1 ; <<4 x float>> [#uses=1]
ret <4 x float> %add
}
This implements rdar://8248065
llvm-svn: 109733
2010-07-29 06:26:06 +00:00
9fa15c3608
ignore structs that wrap vectors in IR, the abstraction shouldn't add penalty.
...
Before we'd compile the example into something like:
%coerce.dive2 = getelementptr %struct.v4f32wrapper* %retval, i32 0, i32 0 ; <<4 x float>*> [#uses=1]
%1 = bitcast <4 x float>* %coerce.dive2 to <2 x double>* ; <<2 x double>*> [#uses=1]
%2 = load <2 x double>* %1, align 1 ; <<2 x double>> [#uses=1]
ret <2 x double> %2
Now we produce:
%coerce.dive2 = getelementptr %struct.v4f32wrapper* %retval, i32 0, i32 0 ; <<4 x float>*> [#uses=1]
%0 = load <4 x float>* %coerce.dive2, align 1 ; <<4 x float>> [#uses=1]
ret <4 x float> %0
llvm-svn: 109732
2010-07-29 05:02:29 +00:00
4200fe4e50
move the 'pretty 16-byte vector' inferring code up to be shared
...
with return values, improving stuff that returns __m128 etc.
llvm-svn: 109731
2010-07-29 04:56:46 +00:00
ce1bd754d8
simplify code by eliminating a premature optimization.
...
llvm-svn: 109730
2010-07-29 04:51:12 +00:00
3a44c7e55d
now that we have CGT around, we can start using preferred types
...
for return values too. Instead of compiling something like:
struct foo {
int *X;
float *Y;
};
struct foo test(struct foo *P) { return *P; }
to:
%1 = type { i64, i64 }
define %1 @test(%struct.foo* %P) nounwind {
entry:
%retval = alloca %struct.foo, align 8 ; <%struct.foo*> [#uses=2]
%P.addr = alloca %struct.foo*, align 8 ; <%struct.foo**> [#uses=2]
store %struct.foo* %P, %struct.foo** %P.addr
%tmp = load %struct.foo** %P.addr ; <%struct.foo*> [#uses=1]
%tmp1 = bitcast %struct.foo* %retval to i8* ; <i8*> [#uses=1]
%tmp2 = bitcast %struct.foo* %tmp to i8* ; <i8*> [#uses=1]
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp1, i8* %tmp2, i64 16, i32 8, i1 false)
%0 = bitcast %struct.foo* %retval to %1* ; <%1*> [#uses=1]
%1 = load %1* %0, align 1 ; <%1> [#uses=1]
ret %1 %1
}
We now get the result more type safe, with:
define %struct.foo @test(%struct.foo* %P) nounwind {
entry:
%retval = alloca %struct.foo, align 8 ; <%struct.foo*> [#uses=2]
%P.addr = alloca %struct.foo*, align 8 ; <%struct.foo**> [#uses=2]
store %struct.foo* %P, %struct.foo** %P.addr
%tmp = load %struct.foo** %P.addr ; <%struct.foo*> [#uses=1]
%tmp1 = bitcast %struct.foo* %retval to i8* ; <i8*> [#uses=1]
%tmp2 = bitcast %struct.foo* %tmp to i8* ; <i8*> [#uses=1]
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp1, i8* %tmp2, i64 16, i32 8, i1 false)
%0 = load %struct.foo* %retval ; <%struct.foo> [#uses=1]
ret %struct.foo %0
}
That memcpy is completely terrible, but I don't know how to fix it.
llvm-svn: 109729
2010-07-29 04:46:19 +00:00
029c0f1681
sink preferred type stuff lower. It's possible that this might
...
improve codegen for vaarg or something, because its codepath is
getting preferred types now.
llvm-svn: 109728
2010-07-29 04:41:05 +00:00
22326a10a7
dissolve some more complexity: make the x86-64 abi lowering code
...
compute its own preferred types instead of having CGT compute
them then pass them (circuituously) down into ABIInfo.
llvm-svn: 109726
2010-07-29 02:31:05 +00:00
c11301c76e
simplify Get8ByteTypeAtOffset by making it a member of X86_64ABIInfo
...
llvm-svn: 109724
2010-07-29 02:20:19 +00:00
458b2aaee0
now that ABIInfo depends on CGT, it has trivial access to such
...
things as TargetData, ASTContext, LLVMContext etc. Stop passing
them through so many APIs.
llvm-svn: 109723
2010-07-29 02:16:43 +00:00
2b03797222
cave in to reality and make ABIInfo depend on CodeGenTypes.
...
This will simplify a bunch of code, coming up next.
llvm-svn: 109722
2010-07-29 02:01:43 +00:00
f4ba08aeaf
pass argument vectors in a type that corresponds to the user type if
...
possible. This improves the example to pass <4 x float> instead of
<2 x double> but we still get awful code, and still don't get the
return value right.
llvm-svn: 109700
2010-07-28 23:47:21 +00:00
fa560fedb7
fix some break statements to be formatted more consistently,
...
remove some now-dead code.
llvm-svn: 109690
2010-07-28 23:12:33 +00:00
31faff5d58
use Get8ByteTypeAtOffset for the return value path as well so we
...
don't get errors similar to PR7714 on the return path.
llvm-svn: 109689
2010-07-28 23:06:14 +00:00
b22f1c8bf7
refactor the autosizing code, eliminating duplication
...
and making Get8ByteTypeAtOffset always succeed and documented.
llvm-svn: 109685
2010-07-28 22:44:07 +00:00
4c1e484f39
fix PR7714 by not referencing off the end of a struct when passed by value in
...
x86-64 abi. This also improves codegen as well. Some refactoring is needed of
this code.
llvm-svn: 109681
2010-07-28 22:15:08 +00:00
1d14dd1dc6
CodeGen: Tweak ABI handling for Minix, patch by Kees van Reeuwijk!
...
llvm-svn: 108423
2010-07-15 15:02:28 +00:00
3e2ee147d0
add driver support for minix, patch by Kees van Reeuwijk
...
from PR7583
llvm-svn: 107788
2010-07-07 16:01:42 +00:00
5c740f1523
Reapply:
...
r107173, "fix PR7519: after thrashing around and remembering how all this stuff"
r107216, "fix PR7523, which was caused by the ABI code calling ConvertType instead"
This includes a fix to make ConvertTypeForMem handle the "recursive" case, and call
it as such when lowering function types which have an indirect result.
llvm-svn: 107310
2010-06-30 19:14:05 +00:00
e422266926
Revert r107173, "fix PR7519: after thrashing around and remembering how all this stuff", it broke bootstrap.
...
llvm-svn: 107232
2010-06-30 00:22:35 +00:00
ab1e65e2ea
fix PR7519: after thrashing around and remembering how all this stuff
...
works, the fix is quite simple: just make sure to call ConvertTypeRecursive
when the function type being lowered is in the midst of ConvertType.
llvm-svn: 107173
2010-06-29 17:56:33 +00:00
22a931e3bb
Change X86_64ABIInfo to have ASTContext and TargetData ivars to
...
avoid passing ASTContext down through all the methods it has.
When classifying an argument, or argument piece, as INTEGER, check
to see if we have a pointer at exactly the same offset in the
preferred type. If so, use that pointer type instead of i64. This
allows us to compile A function taking a stringref into something
like this:
define i8* @foo(i64 %D.coerce0, i8* %D.coerce1) nounwind ssp {
entry:
%D = alloca %struct.DeclGroup, align 8 ; <%struct.DeclGroup*> [#uses=4]
%0 = getelementptr %struct.DeclGroup* %D, i32 0, i32 0 ; <i64*> [#uses=1]
store i64 %D.coerce0, i64* %0
%1 = getelementptr %struct.DeclGroup* %D, i32 0, i32 1 ; <i8**> [#uses=1]
store i8* %D.coerce1, i8** %1
%tmp = getelementptr inbounds %struct.DeclGroup* %D, i32 0, i32 0 ; <i64*> [#uses=1]
%tmp1 = load i64* %tmp ; <i64> [#uses=1]
%tmp2 = getelementptr inbounds %struct.DeclGroup* %D, i32 0, i32 1 ; <i8**> [#uses=1]
%tmp3 = load i8** %tmp2 ; <i8*> [#uses=1]
%add.ptr = getelementptr inbounds i8* %tmp3, i64 %tmp1 ; <i8*> [#uses=1]
ret i8* %add.ptr
}
instead of this:
define i8* @foo(i64 %D.coerce0, i64 %D.coerce1) nounwind ssp {
entry:
%D = alloca %struct.DeclGroup, align 8 ; <%struct.DeclGroup*> [#uses=3]
%0 = insertvalue %0 undef, i64 %D.coerce0, 0 ; <%0> [#uses=1]
%1 = insertvalue %0 %0, i64 %D.coerce1, 1 ; <%0> [#uses=1]
%2 = bitcast %struct.DeclGroup* %D to %0* ; <%0*> [#uses=1]
store %0 %1, %0* %2, align 1
%tmp = getelementptr inbounds %struct.DeclGroup* %D, i32 0, i32 0 ; <i64*> [#uses=1]
%tmp1 = load i64* %tmp ; <i64> [#uses=1]
%tmp2 = getelementptr inbounds %struct.DeclGroup* %D, i32 0, i32 1 ; <i8**> [#uses=1]
%tmp3 = load i8** %tmp2 ; <i8*> [#uses=1]
%add.ptr = getelementptr inbounds i8* %tmp3, i64 %tmp1 ; <i8*> [#uses=1]
ret i8* %add.ptr
}
This implements rdar://7375902 - [codegen quality] clang x86-64 ABI lowering code punishing StringRef
llvm-svn: 107123
2010-06-29 06:01:59 +00:00
399d22ac1b
plumb preferred types down into X86_64ABIInfo::classifyArgumentType,
...
no functionality change.
llvm-svn: 107115
2010-06-29 01:14:09 +00:00
1d7c9f7f4b
Pass the LLVM IR version of argument types down into computeInfo.
...
This is somewhat annoying to do this at this level, but it avoids
having ABIInfo know depend on CodeGenTypes for a hint.
Nothing is using this yet, so no functionality change.
llvm-svn: 107111
2010-06-29 01:08:48 +00:00
93af332819
pass/return structs of char and short as i8/i16 to avoid
...
aweful through-memory coersion, just like we do for i32 now.
llvm-svn: 107078
2010-06-28 21:59:07 +00:00
d776fb150e
more tidying up.
...
llvm-svn: 107076
2010-06-28 21:43:59 +00:00
0cf2419cd7
random acts of tidying.
...
llvm-svn: 107050
2010-06-28 20:05:43 +00:00
a7d81ab7f3
X86-64:
...
pass/return structs of float/int as float/i32 instead of double/i64
to make the code generated for ABI cleaner. Passing in the low part
of a double is the same as passing in a float.
For example, we now compile:
struct DeclGroup { float NumDecls; };
float foo(DeclGroup D);
void bar(DeclGroup *D) {
foo(*D);
}
into:
%struct.DeclGroup = type { float }
define void @_Z3barP9DeclGroup(%struct.DeclGroup* %D) nounwind {
entry:
%D.addr = alloca %struct.DeclGroup*, align 8 ; <%struct.DeclGroup**> [#uses=2]
%agg.tmp = alloca %struct.DeclGroup, align 4 ; <%struct.DeclGroup*> [#uses=2]
store %struct.DeclGroup* %D, %struct.DeclGroup** %D.addr
%tmp = load %struct.DeclGroup** %D.addr ; <%struct.DeclGroup*> [#uses=1]
%tmp1 = bitcast %struct.DeclGroup* %agg.tmp to i8* ; <i8*> [#uses=1]
%tmp2 = bitcast %struct.DeclGroup* %tmp to i8* ; <i8*> [#uses=1]
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp1, i8* %tmp2, i64 4, i32 4, i1 false)
%coerce.dive = getelementptr %struct.DeclGroup* %agg.tmp, i32 0, i32 0 ; <float*> [#uses=1]
%0 = load float* %coerce.dive, align 1 ; <float> [#uses=1]
%call = call float @_Z3foo9DeclGroup(float %0) ; <float> [#uses=0]
ret void
}
instead of:
%struct.DeclGroup = type { float }
define void @_Z3barP9DeclGroup(%struct.DeclGroup* %D) nounwind {
entry:
%D.addr = alloca %struct.DeclGroup*, align 8 ; <%struct.DeclGroup**> [#uses=2]
%agg.tmp = alloca %struct.DeclGroup, align 4 ; <%struct.DeclGroup*> [#uses=2]
%tmp3 = alloca double ; <double*> [#uses=2]
store %struct.DeclGroup* %D, %struct.DeclGroup** %D.addr
%tmp = load %struct.DeclGroup** %D.addr ; <%struct.DeclGroup*> [#uses=1]
%tmp1 = bitcast %struct.DeclGroup* %agg.tmp to i8* ; <i8*> [#uses=1]
%tmp2 = bitcast %struct.DeclGroup* %tmp to i8* ; <i8*> [#uses=1]
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp1, i8* %tmp2, i64 4, i32 4, i1 false)
%coerce.dive = getelementptr %struct.DeclGroup* %agg.tmp, i32 0, i32 0 ; <float*> [#uses=1]
%0 = bitcast double* %tmp3 to float* ; <float*> [#uses=1]
%1 = load float* %coerce.dive ; <float> [#uses=1]
store float %1, float* %0, align 1
%2 = load double* %tmp3 ; <double> [#uses=1]
%call = call float @_Z3foo9DeclGroup(double %2) ; <float> [#uses=0]
ret void
}
which is this machine code (at -O0):
__Z3barP9DeclGroup:
subq $24, %rsp
movq %rdi, 16(%rsp)
movq 16(%rsp), %rdi
leaq 8(%rsp), %rax
movl (%rdi), %ecx
movl %ecx, (%rax)
movss 8(%rsp), %xmm0
callq __Z3foo9DeclGroup
addq $24, %rsp
ret
vs this:
__Z3barP9DeclGroup:
subq $24, %rsp
movq %rdi, 16(%rsp)
movq 16(%rsp), %rdi
leaq 8(%rsp), %rax
movl (%rdi), %ecx
movl %ecx, (%rax)
movss 8(%rsp), %xmm0
movss %xmm0, (%rsp)
movsd (%rsp), %xmm0
callq __Z3foo9DeclGroup
addq $24, %rsp
ret
At -O3, it is the difference between this now:
__Z3barP9DeclGroup:
movss (%rdi), %xmm0
jmp __Z3foo9DeclGroup # TAILCALL
vs this before:
__Z3barP9DeclGroup:
movl (%rdi), %eax
movd %rax, %xmm0
jmp __Z3foo9DeclGroup # TAILCALL
llvm-svn: 107048
2010-06-28 19:56:59 +00:00
5e016ae983
finally get around to doing a significant cleanup to irgen:
...
have CGF create and make accessible standard int32,int64 and
intptr types. This fixes a ton of 80 column violations
introduced by LLVMContextification and cleans up stuff a lot.
llvm-svn: 106977
2010-06-27 07:15:29 +00:00
fa20e95043
use more efficient type comparison predicates.
...
llvm-svn: 106958
2010-06-26 21:52:32 +00:00
23a8a06554
Change the test for which ABI/CC to use on ARM to be base on the environment
...
(the last argument of the triple).
llvm-svn: 106131
2010-06-16 19:01:17 +00:00
a92c442437
Don't set the calling convention for ARM if it is already the default.
...
llvm-svn: 106106
2010-06-16 16:13:39 +00:00
6972a62c8f
Give Type::isIntegralType() an ASTContext parameter, so that it
...
provides C "integer type" semantics in C and C++ "integral type"
semantics in C++.
Note that I still need to update isIntegerType (and possibly other
predicates) using the same approach I've taken for
isIntegralType(). The two should have the same meaning, but currently
don't (!).
llvm-svn: 106074
2010-06-16 00:35:25 +00:00
b90df60b3b
Introduce Type::isIntegralOrEnumerationType(), to cover those places
...
in C++ that involve both integral and enumeration types. Convert all
of the callers to Type::isIntegralType() that are meant to work with
both integral and enumeration types over to
Type::isIntegralOrEnumerationType(), to prepare to eliminate
enumeration types as integral types.
llvm-svn: 106071
2010-06-16 00:17:44 +00:00
bbd44ef673
Fix passing and returning of objects with non trivial copy constructors on
...
ARM.
Fixes PR7310.
llvm-svn: 105592
2010-06-08 02:42:08 +00:00
943fae95f5
Implement __builtin_init_dwarf_reg_size_table and __builtin_dwarf_sp_column
...
for 32-bit MIPS processors. Hat-tip to rdivacky for providing gcc dumps
on this.
llvm-svn: 104816
2010-05-27 06:19:26 +00:00
f7a8825484
IRgen: Remove dead function.
...
llvm-svn: 103945
2010-05-17 16:46:02 +00:00
cd20ce1513
C++/Darwin/i386 ABI: Fix some problems with empty record handling.
...
- Check bases as part of isEmptyRecord().
- C++ record fields are never empty in the Itanium ABI.
llvm-svn: 103944
2010-05-17 16:46:00 +00:00
36d4d1541c
C++/ABI/x86_64: Member pointers should be classified as INTEGER.
...
llvm-svn: 103843
2010-05-15 00:00:37 +00:00
4bd95c65e7
C++/ABI/i386: Member function pointers should be passed by value.
...
llvm-svn: 103842
2010-05-15 00:00:30 +00:00
6b45b67b26
C++/Darwin/x86: Teach IRgen it can pass reference types in registers.
...
llvm-svn: 103761
2010-05-14 03:40:53 +00:00
12ebb47a07
IRgen/i386/C++: Fix isSingleElementStruct computation for C++ record decls.
...
- Fixes PR7098.
llvm-svn: 103514
2010-05-11 21:15:36 +00:00
53fac692fa
ABI/x86-32 & x86-64: Alignment on 'byval' must be set when when the alignment
...
exceeds the minimum ABI alignment.
llvm-svn: 102019
2010-04-21 19:49:55 +00:00
557893d2a8
IRgen/x86-32: Factor out getIndirectResult(), to match x86-64 factoring.
...
llvm-svn: 102015
2010-04-21 19:10:51 +00:00
c0e8a59ac9
fit in 80 cols
...
llvm-svn: 100534
2010-04-06 17:29:22 +00:00
9723d6c699
fix PR6433, crash on va_arg of typedef.
...
llvm-svn: 98264
2010-03-11 18:19:55 +00:00
ea8d8bb718
Support PPC-32 DWARF EH intrinisics. Thanks to rdivacky for his assistance.
...
llvm-svn: 98206
2010-03-11 00:10:12 +00:00
beec5a080f
Implement __builtin_dwarf_sp_column for i386 (Darwin and not), x86-64 (all),
...
and ARM. Implement __builtin_init_dwarf_reg_size_table for i386 (both) and
x86-64 (all).
llvm-svn: 97859
2010-03-06 00:35:14 +00:00
8ee376f08a
Canonicalize parameter and return types before computing ABI info. Eliminates
...
a common source of oddities and, in theory, removes some redundant ABI
computations. Also fixes a miscompile I introduced yesterday by refactoring
some code and causing a slightly different code path to be taken that
didn't perform *parameter* type canonicalization, just normal type
canonicalization; this in turn caused a bit of ABI code to misfire because
it was looking for 'double' or 'float' but received 'const float'.
llvm-svn: 97030
2010-02-24 07:14:12 +00:00
ba1e267a4c
implement EmitVAArg. pretty much the same way other targets do.
...
llvm-svn: 96446
2010-02-17 02:25:52 +00:00
998f9d975b
Uniformize the names of type predicates: rather than having isFloatTy and
...
isInteger, we now have isFloatTy and isIntegerTy. Requested by Chris!
llvm-svn: 96224
2010-02-15 16:14:01 +00:00
4ea31ab369
Emit the 'alignstack' LLVM function attribute when we encounter a function
...
marked 'force_align_arg_pointer'. Almost there; now all I need to do is finish
up the backend.
llvm-svn: 96100
2010-02-13 15:54:06 +00:00
a71cc15361
Implement promotion for enumeration types.
...
WHAT!?!
It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despite having properly computed the promotion type when the
enum was defined. Various operations on values of enum type just
"worked" because we could still compute the integer rank of an enum
type; the oddity, however, is that operations such as "add an enum and
an unsigned" would often have an enum result type (!). The bug
actually showed up as a spurious -Wformat diagnostic
(<rdar://problem/7595366>), but in theory it could cause miscompiles.
In this commit:
- Enum types with a promotion type of "int" or "unsigned int" are
promotable.
- Tweaked the computation of promotable types for enums
- For all of the ABIs, treat enum types the same way as their
underlying types (*not* their promotion types) for argument passing
and return values
- Extend the ABI tester with support for enumeration types
llvm-svn: 95117
2010-02-02 20:10:50 +00:00
96ebba5770
ARM/APCS: Fix classification of small complex integer types as "integer like".
...
llvm-svn: 95030
2010-02-01 23:31:26 +00:00
eedf151cb1
ARM/APCS: Pass Complex types following llvm-gcc.
...
llvm-svn: 95029
2010-02-01 23:31:19 +00:00
45c7ff1d79
ARM/APCS ABI: Fix some problems with bit-fields in structures. After rereading
...
the ABI spec, this turns out to simplify the code. We still have some annoying
code which mismatches the spec with regard to empty structures.
llvm-svn: 94796
2010-01-29 03:22:29 +00:00
40446e8a0a
Structs and classes with non-trivial destructors or copy constructors should be passed indirectly in the 32-bit ABI. Fixes PR6094.
...
llvm-svn: 94656
2010-01-27 03:25:19 +00:00
0599df16a6
Eliminate some Clang warnings
...
llvm-svn: 94177
2010-01-22 15:41:14 +00:00
55bcea1e65
Generalize target weirdness handling having proper layering in mind:
...
1. Add helper class for sema checks for target attributes
2. Add helper class for codegen of target attributes
As a proof-of-concept - implement msp430's 'interrupt' attribute.
llvm-svn: 93118
2010-01-10 12:58:08 +00:00
89b14a4309
Rename file to generalization in next commits
...
llvm-svn: 93117
2010-01-10 12:57:30 +00:00
NAKAMURA Takumi