| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
convention selection (AAPCS or
AAPCS+VFP), similar to fastcall / stdcall / whatevercall seen on x86.
In particular, all library functions should always be AAPCS regardless of floating point ABI used.
llvm-svn: 129534
|
|
|
|
|
|
| |
handling.
llvm-svn: 128866
|
|
|
|
|
|
| |
PHINode::Create() giving the (known or expected) number of operands.
llvm-svn: 128538
|
|
|
|
|
|
|
|
| |
clobber with the 'y' constraint. Otherwise, we get the wrong return type and an
assert, because it created a '<1 x i64>' vector type instead of the x86_mmx
type.
llvm-svn: 127185
|
|
|
|
|
|
| |
This reverts commit 126863.
llvm-svn: 126886
|
|
|
|
| |
llvm-svn: 126863
|
|
|
|
|
|
| |
mingw-w64's i128 tweak should be done with x86_64-mingw32.
llvm-svn: 126186
|
|
|
|
| |
llvm-svn: 126060
|
|
|
|
| |
llvm-svn: 126050
|
|
|
|
| |
llvm-svn: 125819
|
|
|
|
|
|
| |
No one uses *-mingw64. mingw-w64 is represented as {i686|x86_64}-w64-mingw32.
llvm-svn: 125742
|
|
|
|
| |
llvm-svn: 125741
|
|
|
|
| |
llvm-svn: 124736
|
|
|
|
| |
llvm-svn: 123790
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Clang does not wrap the vectors in structs anymore so this isn't needed.
llvm-svn: 123241
|
|
|
|
| |
llvm-svn: 123195
|
|
|
|
|
|
| |
2. Add attibutes "interrupt_handler" and "save_volatiles" for the Microblaze target.
llvm-svn: 122184
|
|
|
|
| |
llvm-svn: 118892
|
|
|
|
|
|
| |
getBaseClassOffset which returns the offset in CharUnits. Do the same thing for getVBaseClassOffset.
llvm-svn: 117881
|
|
|
|
| |
llvm-svn: 116798
|
|
|
|
|
|
| |
registers needed.
llvm-svn: 116772
|
|
|
|
| |
llvm-svn: 116696
|
|
|
|
|
|
|
| |
Clang :: CodeGen/x86_32-arguments-darwin.c
Clang :: CodeGen/x86_32-arguments-linux.c
llvm-svn: 116687
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
it comes back, it will be largely a rewrite, so keeping the old codebase
in tree isn't helping anyone.
llvm-svn: 116191
|
|
|
|
| |
llvm-svn: 114619
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
| |
them with a smaller alignment than the rest of codegen expects.
llvm-svn: 114115
|
|
|
|
|
|
| |
reference.
llvm-svn: 114114
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Darwin. Checked vs the handiest Linux llvm-gcc I had around, someone on Linux is
welcome to investigate more.
llvm-svn: 114112
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 112684
|
|
|
|
| |
llvm-svn: 112683
|
|
|
|
| |
llvm-svn: 112603
|
|
|
|
| |
llvm-svn: 112537
|
|
|
|
| |
llvm-svn: 112214
|
|
|
|
|
|
|
| |
memory (as required) the later now passes in an xmm register. This
fixes gcc.dg/compat/vector_1 on x86-32.
llvm-svn: 112211
|
|
|
|
|
|
|
| |
this fixes rdar://8358475 a failure of the gcc.dg/compat/vector_1 abi
test.
llvm-svn: 112205
|
|
|
|
|
|
| |
this fixes a miscompilation on the included testcase, rdar://8359248
llvm-svn: 112201
|
|
|
|
| |
llvm-svn: 112174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 112067
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
that needs it and remove getCoerceResult.
llvm-svn: 109807
|
|
|
|
| |
llvm-svn: 109805
|
|
|
|
|
|
| |
float, the special case hack in getCoerceResult can go away.
llvm-svn: 109804
|
|
|
|
|
|
|
|
| |
<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
|