compatible with VC++ and GCC. The codegen/mangling angle hasn't
been fully ironed out yet. Note that we accept int128_t even in
32-bit mode, unlike gcc.
llvm-svn: 70464
- Small structures are returned in a register if:
1. They fit nicely in a register.
2. All fields fit nicely in a register.
(more or less)
- We now pass the first 5000 ABITests if unions are disabled.
- <rdar://problem/6497882> [irgen] x86-32 ABI compatibility with
small structs
llvm-svn: 68197
element structures", which have different ABI rules.
- Current return-arguments-32 status is: 1 out of 1000 failures (-7)
- Also, vectors inside "single element structs" require special
handling.
llvm-svn: 68196
really intending to take ownership of this; I wrote this mostly because
I was curious about how the ARM ABI works. It should be a decent start,
though.
llvm-svn: 67969
- This is an ABI incompatiblity, but this is not likely to be a huge
deal in practice. For now we at least generate self consistent code
instead of crashing.
- <rdar://problem/6657601> x86-32 ABI: Bitfields in small structures
are not passed correctly
llvm-svn: 66713
giving them rough classifications (normal types, never-canonical
types, always-dependent types, abstract type representations) and
making it far easier to make sure that we've hit all of the cases when
decoding types.
Switched some switch() statements on the type class over to using this
mechanism, and filtering out those things we don't care about. For
example, CodeGen should never see always-dependent or non-canonical
types, while debug info generation should never see always-dependent
types. More switch() statements on the type class need to be moved
over to using this approach, so that we'll get warnings when we add a
new type then fail to account for it somewhere in the compiler.
As part of this, some types have been renamed:
TypeOfExpr -> TypeOfExprType
FunctionTypeProto -> FunctionProtoType
FunctionTypeNoProto -> FunctionNoProtoType
There shouldn't be any functionality change...
llvm-svn: 65591
- For types whose native representation is a pointer.
- Use to replace ExprConstant.cpp:HasPointerEvalType,
CodeGenFunction::isObjCPointerType.
llvm-svn: 65569
1. Return of _Complex long double used wrong type.
2. va_arg of types passed in two SSE registers didn't account for
extra space in register save area.
Down to 18 failures on gcc/compat/x86_64. Combined 32/64 results are:
--
=== gcc Summary ===
# of expected passes 1292
# of unexpected failures 34
# of unsupported tests 2
--
llvm-svn: 64880
memory representation (e.g., bool).
- This upgrades (downgrades) MultiSource/Applications/ClamAV/clamscan
to a miscompile and fixes
SingleSource/UnitTests/2003-05-31-CastToBool.
llvm-svn: 64194
- Currently, this is producing poor code, but we prefer correctness
to performance for now. Eventually we should be able to generally
avoid having to set the alignment when we control the alignment of
the alloca.
- This knocks out 33/1000 failures on my single argument ABI tests,
down to 22/1000 and 18 of these appear to be gcc bugs. Woot.
llvm-svn: 64001
- No intended functionality change, this is essentially enabling
direct passing of complex and aggregate values, which no ABI is
using.
llvm-svn: 63863
- No intended functionality change, all current ABI implementations
were only using indirect for complex/aggregate types, which were
being passed indirectly with the Direct ABIInfo kind.
llvm-svn: 63858
- Now only 27/500 failures on ABITest single argument tests; from
350/500. :)
- As with return types, a large percentage of these are likely to be
gcc bugs, not yet reviewed.
Also, fix bug in handling of Ignore ABI type in argument lists.
llvm-svn: 63654
- Lift CGFunctionInfo creation up to callers of EmitCall.
- Move isVariadic bit out of CGFunctionInfo, take as argument to
GetFunctionType instead.
No functionality change.
llvm-svn: 63550
in terms of where the type resides in the containing object. This is a
more clear embodiement of the spec & fixes a merging issue with
unions. Down to 3/1000 failures.
llvm-svn: 63455
eightbyte boundaries.
- Getting harder to test now that we handle cases gcc & llvm-gcc get
wrong ( { _Complex char; _Complex int; } is a good example). :)
llvm-svn: 63305
- This is my best initial guess at what the "spec" means, although it is not
particularly clear on a number of points. Will refine through testing.
llvm-svn: 63292
filters the decls seen by decl_iterator with two criteria: the dynamic
type of the declaration and a run-time predicate described by a member
function. This simplifies EnumDecl, RecordDecl, and ObjCContainerDecl
considerably. It has no measurable performance impact.
llvm-svn: 61994
- Update comment to reflect fact that StructRet is now supported for
any type (modulo LLVM support).
- No functionality change, no scalar types currently use this
feature.
llvm-svn: 61192
- Currently still lives in CGCall.cpp but is intended to be the
target specific place for hooking ABI information.
- Select ABIInfo to use based on Target's prefix and pointer width.
llvm-svn: 57445
- return attributes - inreg, zext and sext
- parameter attributes
- function attributes - nounwind, readonly, readnone, noreturn
Return attributes use 0 as the index.
Function attributes use ~0U as the index.
llvm-svn: 56705
s/ParamAttr/Attribute/g
s/PAList/AttrList/g
s/FnAttributeWithIndex/AttributeWithIndex/g
s/FnAttr/Attribute/g
This sets the stage
- to implement function notes as function attributes and
- to distinguish between function attributes and return value attributes.
llvm-svn: 56623
- Enables use of ABIArgInfo::Expand when needed. This greatly
improves our x86 ABI compatibility.
- As the infrastructure for target specific ABI handling isn't built
yet, this change means ABI compatibility on other platforms is once
again broken in a different way than before.
- Upcoming: Figure out how to refactor ABI handling into
targets. More documentation.
llvm-svn: 56293
Ensure that ABIArgInfo::Default implementation for aggregrate types
is sensible (StructRet on return and ByVal on arguments).
No functionality change.
llvm-svn: 56289
value).
- Added ABIArgInfo::ByVal (mostly supported) and ABIArgInfo::Expand
(asserted out).
- Added classifyArgumentType which currently just uses
ABIArgInfo::Default or ByVal. This nearly matches old behavior, but
we now set ByVal in a few situations we may have left it off before
(on complex, for example).
llvm-svn: 56086
no method declaration was found.
- This was allowing arrays to pass "by value" among other things.
Add assert in CodeGen that arguments cannot have array type.
llvm-svn: 56080
- As a test, enable basic usage for some common x86-32 cases. This
increases our x86-32 compliance (on other targets our compliance
will just be broken in a different way).
llvm-svn: 56051
type of a call.
Change NeXT runtime to use this instead of trying to bitcasting
internally (which doesn't respect the ABI).
Fix subtle bug, use of ConvertTypeRecursive instead of ConvertType is
bad inside GetFunctionType.
llvm-svn: 56050
- Added CodeGenTypes::GetFunctionType, taking a CGFunctionInfo.
- Updated Obj-C runtimes to use this instead of rolling the
llvm::FunctionType by hand.
- Killed CodeGenTypes::{ConvertReturnType, DecodeArgumentTypes}.
Add ABIArgInfo class to encapsulate ABI decision of how to lower types
to LLVM.
- Will move to target sometime soon.
llvm-svn: 56047
- Realized these functions will eventually need access to more data,
moved to CodeGenModule. Eventually they should probably live
together in some other helper class.
llvm-svn: 56039
- Add CodeGenFunction::EmitAnyExprToTemp
o Like EmitAnyExpr, but emits aggregates to a temporary location if
none is available. Seems like this should be simpler (even aside
from using first class aggregates).
- Killed CodeGenFunction::EmitCallArg (just append the pair)
- Conversion of RValues to actual call arguments is now isolated in
CodeGenFunction::EmitCall.
llvm-svn: 55970
- Add CGCall.h for dealing with ABI issues related to calls.
- Add CGFunctionInfo and CGCallInfo for capturing ABI relevant
information about functions and calls.
- Isolate LLVM parameter attribute handling inside CGCall.cpp
llvm-svn: 55963
Daniel Dunbar