| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes PR15768, where the sret parameter and the 'this' parameter
are in the wrong order.
Instance methods compiled by MSVC never return records in registers,
they always return indirectly through an sret pointer. That sret
pointer always comes after the 'this' parameter, for both __cdecl and
__thiscall methods.
Unfortunately, the same is true for other calling conventions, so we'll
have to change the overall approach here relatively soon.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2664
llvm-svn: 200587
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
|
|
|
|
| |
llvm-svn: 199258
|
|
|
|
| |
llvm-svn: 199257
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeGenABITypes is a wrapper built on top of CodeGenModule that exposes
some of the functionality of CodeGenTypes (held by CodeGenModule),
specifically methods that determine the LLVM types appropriate for
function argument and return values.
I addition to CodeGenABITypes.h, CGFunctionInfo.h is introduced, and the
definitions of ABIArgInfo, RequiredArgs, and CGFunctionInfo are moved
into this new header from the private headers ABIInfo.h and CGCall.h.
Exposing this functionality is one part of making it possible for LLDB
to determine the actual ABI locations of function arguments and return
values, making it possible for it to determine this for any supported
target without hard-coding ABI knowledge in the LLDB code.
llvm-svn: 193717
|
|
|
|
|
|
| |
class metadata for certain deployment targets. // rdar://14802916
llvm-svn: 193359
|
|
|
|
| |
llvm-svn: 190737
|
|
|
|
|
|
|
| |
This is debugging code so functionality isn't a concern, but mingw32 warns
because it doesn't understand the %llx format specifier.
llvm-svn: 180024
|
|
|
|
|
|
| |
Patch by Stephen Lin!
llvm-svn: 179638
|
|
|
|
|
|
|
|
|
|
|
|
| |
a normal cleanup when entering a @try or @synchronized to
ensure that we clean that up if an exception is triggered.
Apparently GCC did this, so it's hard to argue that we shouldn't
do at least as much.
rdar://12364847
llvm-svn: 178599
|
|
|
|
|
|
|
|
| |
the requirements on the ARC optimizer.
rdar://13407451
llvm-svn: 176924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calls and declarations.
LLVM has a default CC determined by the target triple. This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention. Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect. However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility. Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile; so it's quite
important to get this right.
Defining runtime functions locally is quite common in embedded
applications.
llvm-svn: 176286
|
|
|
|
|
|
|
|
| |
not the global visibility mode.
Noticed by inspection.
llvm-svn: 175479
|
|
|
|
| |
llvm-svn: 175448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An ivar ofset cannot be marked as invariant load in all cases. The ivar offset
is a lazily initialised constant, which is dependent on an objc_msgSend
invocation to perform a fixup of the offset. If the load is being performed on
a method implemented by the class then this load can safely be marked as an
inviarant because a message must have been passed to the class at some point,
forcing the ivar offset to be resolved.
An additional heuristic that can be used to identify an invariant load would be
if the ivar offset base is a parameter to an objc method. However, without the
parameters available at hand, this is currently not possible.
Reviewed-by: John McCall <rjmccall@apple.com>
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 175386
|
|
|
|
|
|
| |
rdar://12046763
llvm-svn: 174946
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SELECTOR_REFERENCES in both the fragile and non-fragile API.
This is to ensure that GlobalOpt in LLVM does not attempt to look through a
selector reference to a method var name at compile time.
I also added a test/updated old tests that need to recognize the new keyword.
rdar://12580965.
llvm-svn: 174461
|
|
|
|
|
|
|
|
| |
Several places were still treating the Attribute object as respresenting
multiple attributes. Those places now use the AttributeSet to represent
multiple attributes.
llvm-svn: 174004
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
|
|
|
| |
an objectiveC object, use objc_exception_throw
to raise the exception. // rdar://12605907
llvm-svn: 172091
|
|
|
|
|
|
|
|
| |
reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
llvm-svn: 171369
|
|
|
|
| |
llvm-svn: 170722
|
|
|
|
|
|
| |
which is wrong here.
llvm-svn: 170721
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170500
|
|
|
|
| |
llvm-svn: 170354
|
|
|
|
|
|
| |
This reverts commit r170344. Doesn't even compile.
llvm-svn: 170351
|
|
|
|
| |
llvm-svn: 170344
|
|
|
|
|
|
|
| |
after the fixed size block header when generating
captured block variable info. // rdar://12773256
llvm-svn: 169285
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
| |
variables captured in a block. // rdar://12184410
llvm-svn: 167931
|
|
|
|
|
|
|
| |
captured block variable layout meta-data. No intended change
in functionality.
llvm-svn: 167549
|
|
|
|
|
|
| |
coverage of this code is.
llvm-svn: 167495
|
|
|
|
| |
llvm-svn: 167487
|
|
|
|
| |
llvm-svn: 167437
|
|
|
|
|
|
| |
refactor the code.
llvm-svn: 167436
|
|
|
|
| |
llvm-svn: 167431
|
|
|
|
|
|
| |
well as couple of tests which were not being excercised because of TYPOs.
llvm-svn: 167374
|
|
|
|
|
|
| |
mrr mode.
llvm-svn: 167331
|
|
|
|
| |
llvm-svn: 167249
|
|
|
|
|
|
|
|
| |
generation for captured block variables in arc mode. This includes
inlined version of the meta-data when it can be done. It also includes
severat tests. This is wip. // rdar://12184410.
llvm-svn: 167241
|
|
|
|
|
|
| |
layout meta-data. It is currently off (so no tests). This is wip.
llvm-svn: 167047
|
|
|
|
|
|
| |
It is currently off (so no tests). This is wip.
llvm-svn: 166892
|
|
|
|
|
|
| |
layout meta-data work. wip.
llvm-svn: 166717
|
|
|
|
|
|
|
|
|
| |
has ivars that require destruction, but none that require anything
except zero-initialization. This is common in ARC and (when true
throughout a class hierarchy) permits the elimination of an
unnecessary message-send during allocation.
llvm-svn: 166088
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 166087
|
|
|
|
|
|
| |
simplify the code a bit. No functionality change.
llvm-svn: 166010
|
|
|
|
|
|
| |
own class named AttrBuilder. No functionality change.
llvm-svn: 165961
|
|
|
|
|
|
|
|
| |
Convert the uses of the Attributes class over to the new format. The
Attributes::get method call now takes an LLVM context so that the attributes
object can be uniquified and stored.
llvm-svn: 165918
|
|
|
|
|
|
|
|
|
| |
in a category class method, don't read 'isa' pointer. Instead,
save the desired OBJC_METACLASS_$_ClassName in
__DATA,__objc_superrefs and read that without reading any
isa pointers. // rdar://12459358
llvm-svn: 165674
|
|
|
|
|
|
|
| |
namespace. Use the attribute's enum value instead. No functionality change
intended.
llvm-svn: 165611
|