| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
variables in ObjC's Next runtime mode. Next runtime also implicitly applies
'used' attribute on some of its meta-data. This results in two
'llvm.used' arrays to be generated, and one of them is renamed to
'llvm.used1'.
llvm-svn: 74008
|
| |
|
|
| |
llvm-svn: 73702
|
| |
|
|
| |
llvm-svn: 73158
|
| |
|
|
| |
llvm-svn: 72827
|
| |
|
|
| |
llvm-svn: 72203
|
| |
|
|
| |
llvm-svn: 71937
|
| |
|
|
|
|
| |
else the method will not be found by the runtime at class load time).
llvm-svn: 71904
|
| |
|
|
|
|
| |
- No functionality change.
llvm-svn: 71898
|
| |
|
|
|
|
| |
Used simple array for Selector build.
llvm-svn: 71674
|
| |
|
|
|
|
|
| |
selectors which need use Nonfrgile API for
message dispatch.
llvm-svn: 71578
|
| |
|
|
|
|
| |
only and used in class imllementations (objc2 Nonfragile ABI specific).
llvm-svn: 71571
|
| |
|
|
|
|
|
|
| |
message dispage API for all but a few messages. This is
a runtime performance improvement and there is not meant
to be a functional change.
llvm-svn: 71467
|
| |
|
|
|
|
| |
LLVM.
llvm-svn: 71350
|
| |
|
|
|
|
| |
Patch by David Chisnall.
llvm-svn: 71023
|
| |
|
|
| |
llvm-svn: 70951
|
| |
|
|
|
|
|
|
|
|
|
|
| |
compensating for super classes). This was making the reported class
sizes for empty classes very, very wrong.
- Also, we now report the size info for an empty class like gcc (as
the offset of the start, not as 0, 0).
- Add a few more test cases we were mishandling before (padding bit
field at end of struct, for example).
llvm-svn: 70938
|
| |
|
|
|
|
|
|
|
| |
layout.
- This is much simpler / more efficient.
- This also properly computes the size in the presence of bit-fields.
llvm-svn: 70916
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
via CollectObjCIvars.
- In places where we need them, we should have the implementation and
access the properties through it.
This is a fairly substantial functionality change:
1. @encode no longer encodes synthesized ivars, ever.
2. The ivar layout bitmap no longer encodes information for
synthesized ivars in superclasses. Well, actually I had already
broken that, but it is intentional now.
We are now differing substantially from llvm-gcc and gcc
here. However, in my opinion this fundamentally *must* work if
non-fragile classes are to work. Without this change, the result of
@encode and the ivar layout depend on the order that the
implementation is seen in a file (if it is in the same file with its
superclass). Since both scenarios should work the same, our behavior
is now consistent with gcc behavior as if an implementation is never
seen following an implementation of its superclass.
Note that #2 is only a functionality change when (A) an
implementation appears in the same translation unit with the
implementation of its superclass, and (B) the superclass has
synthesized ivars. My belief is that this situation does not occur in
practice.
I am not yet sure of the role/semantics of @encode when synthesized
ivars are present... it's use is fairly unsound in a non-fragile world.
llvm-svn: 70822
|
| |
|
|
| |
llvm-svn: 70813
|
| |
|
|
| |
llvm-svn: 70812
|
| |
|
|
| |
llvm-svn: 70810
|
| |
|
|
|
|
|
| |
ivar layout.
- The layout needs access to synthesized ivars.
llvm-svn: 70798
|
| |
|
|
|
|
| |
just computing it!
llvm-svn: 70779
|
| |
|
|
| |
llvm-svn: 70778
|
| |
|
|
| |
llvm-svn: 70777
|
| |
|
|
| |
llvm-svn: 70776
|
| |
|
|
|
|
| |
Lift up a size calculation and note some asymmetries.
llvm-svn: 70775
|
| |
|
|
| |
llvm-svn: 70771
|
| |
|
|
|
|
|
|
|
|
|
| |
struct.
- We still need to do more lookup than necessary because ivars don't
live in a reasonable DeclContext.
- The only remaining client of the interface shadow struct is the
ivar layout bitmap.
llvm-svn: 70756
|
| |
|
|
|
|
|
|
| |
decl. Only this routine will be suitable for computing the offset of a
synthesized ivar.
- No functionality change.
llvm-svn: 70696
|
| |
|
|
|
|
| |
not the shadow structure.
llvm-svn: 70691
|
| |
|
|
| |
llvm-svn: 70684
|
| |
|
|
| |
llvm-svn: 70683
|
| |
|
|
|
|
| |
- No functionality change.
llvm-svn: 70674
|
| |
|
|
| |
llvm-svn: 70518
|
| |
|
|
|
|
| |
to match gcc's closely.
llvm-svn: 70493
|
| |
|
|
|
|
| |
It seems to effect code gen. Add a FIXME instead.
llvm-svn: 70423
|
| |
|
|
|
|
|
| |
referenced in a category implementation meta-data
(Next objc 32bit abi).
llvm-svn: 70407
|
| |
|
|
| |
llvm-svn: 70404
|
| |
|
|
| |
llvm-svn: 70145
|
| |
|
|
| |
llvm-svn: 70105
|
| |
|
|
| |
llvm-svn: 69988
|
| |
|
|
| |
llvm-svn: 69979
|
| |
|
|
| |
llvm-svn: 69970
|
| |
|
|
| |
llvm-svn: 69896
|
| |
|
|
|
|
|
| |
- This shouldn't change anything, we never actually access it, but
this is consistent with llvm-gcc (and 32-bit)
llvm-svn: 69880
|
| |
|
|
|
|
|
|
|
| |
- Notably, there was a memory error here, SkipIvars does not have to
be the same size as IvarsInfo.
- Fariborz, please check.
llvm-svn: 69850
|
| |
|
|
|
|
|
|
|
|
|
| |
methods, class methods, and property implementations) and instead
place all of these entities into the DeclContext.
This eliminates more linear walks when looking for class or instance
methods and should make PCH (de-)serialization of ObjCDecls trivial
(and lazy).
llvm-svn: 69849
|
| |
|
|
| |
llvm-svn: 69838
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rework the shadow struct that is layed out for Objective-C classes.
- Superclasses are now always laid out in their shadow structure at
the first field.
- Prior to this, the entire class heirarchy was flattened into a
single structure which meant that alignment, padding, and bitfields
were incorrect (the ASTRecordLayout was correct however, which
meant our debug info didn't coincide with ivar offsets, for
example).
- This is still very suboptimal (for example, ivar are looked up
recursively, but I believe the ivar layout itself is now at least
close to correct.
- <rdar://problem/6773388> error: objc[29823]: layout bitmap sliding
backwards
llvm-svn: 69811
|