| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
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
|
|
|
|
|
|
| |
- This is only used by CGObjCRuntime now.
llvm-svn: 69800
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- This has pros and cons, but for now the pros seem to significantly
outway the con.
The con is that we will always need to cast in the runtime
implementation to a struct type, if we wish to access an interface
directly.
The pros are:
- Avoid the cost of generating types which are used. Most
manipulation of Objective-C objects is done through messages, and
only the implementation of a class will directly access
memory. Previously, we would convert the type even if it only
appear as a function parameter, for example.
- We don't need to worry about incomplete types, and
UpdateCompletedType for interfaces is gone.
- It becomes easier to narrow the interface to the shadow struct for
Objective-C interfaces (so it can be eliminated).
Currently the runtimes still use the CodeGenTypes machinery to
generate the LLVM structure they need via ConvertTagDecl, but this can
eventually be replaced.
llvm-svn: 69797
|
|
|
|
|
|
| |
underlying llvm::StructType for an interface.
llvm-svn: 69796
|
|
|
|
| |
llvm-svn: 69790
|
|
|
|
|
|
|
|
|
| |
- For now, this means we are always doing the address computations by
hand instead of constructing a proper GEP. Right now, however, this
is less important than having fewer entry points to dealing with
Objective-C interface layout.
llvm-svn: 69787
|
|
|
|
| |
llvm-svn: 69775
|
|
|
|
| |
llvm-svn: 69773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Superclasses are now always laid out 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
weren't packed correctly (the ASTRecordLayout was correct however,
which meant our debug info didn't coincide with ivar offsets, for
example).
- This is still very suboptimal, 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: 69771
|
|
|
|
| |
llvm-svn: 69767
|
|
|
|
|
|
| |
7 left for 64-bit ABI.
llvm-svn: 69766
|
|
|
|
| |
llvm-svn: 69765
|
|
|
|
| |
llvm-svn: 69764
|
|
|
|
|
|
| |
produces just 14 dead "declares" in llvm ir instead of 19.
llvm-svn: 69763
|
|
|
|
|
|
| |
rdar://6809612
llvm-svn: 69762
|
|
|
|
|
|
|
|
|
| |
@implementation that closes a @class delcaration.
- I don't know how to make a test case for this, but this strengthens
the invariants that hold internally. The functionality change here
is the edit to SemaDeclObjC.cpp.
llvm-svn: 69728
|
|
|
|
| |
llvm-svn: 69695
|
|
|
|
|
|
|
|
| |
when we need them -- which is exactly what some code was already
doing!
- No intended functionality change.
llvm-svn: 69648
|
|
|
|
|
|
|
| |
w.r.t. ASTContext::[gs]etFieldDecl, and the Field argument to
EmitObjCValueForIvar).
llvm-svn: 69639
|
|
|
|
| |
llvm-svn: 69629
|
|
|
|
|
|
|
|
|
|
|
|
| |
GetClassSizeInfo
Reduce nesting in GetInterfaceDeclStructLayout.
Tweak some comments.
No functionality change.
llvm-svn: 69621
|
|
|
|
|
|
| |
- No functionality change.
llvm-svn: 69582
|
|
|
|
|
|
|
|
| |
@synthesized ivars for superclasses.
- <rdar://problem/6806371> [clang] Mark code without miscompiled
@synthesized properties
llvm-svn: 69581
|
|
|
|
|
|
|
|
|
| |
Drop uses of GetFirstInvarInRecord, instead we lookup the ivars we
know are in the record.
- This is somewhat less efficient, but I need to detangle this code
first...
llvm-svn: 69579
|
|
|
|
|
|
| |
Also, added assertion that the field matches what would be looked up.
llvm-svn: 69572
|
|
|
|
| |
llvm-svn: 69563
|