| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
This reverts commit r203059.
Revert while we discuss what does it mean to be private and weak.
llvm-svn: 203141
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the remaining GlobalVariables using "\01L" and
"\01l" prefixes to use private linkage. What is strange about them is
that they currently use WeakAnyLinkage. There is no comment stating
why and that is really odd since the symbols are completely hidden, so
it doesn't make sense for them to be weak.
Clang revisions like r63329, r63408, r63770, r65761 set the linkage to
weak, but don't say why. I suspect they were just copying llvm-gcc.
In llvm-gcc I found r58599 and r56322 that set DECL_WEAK, but they
were just syncing from the apple gcc. I am not exactly sure what that
means, since the last commit to
svn://gcc.gnu.org/svn/gcc/branches/apple was in 2006, 2 years earlier.
In summary, I have no idea why weak linkage was being used :-(
To quote John McCall, "Let’s try without it and see" :-)
llvm-svn: 203059
|
|
|
|
| |
llvm-svn: 203052
|
|
|
|
|
|
|
| |
This simplifies my last patch a bit. No change in
functionality.
llvm-svn: 202906
|
|
|
|
|
|
|
|
| |
if an ivar offset load is invariant iff inside an instance method
and ivar belongs to instance method's class and one of its super class.
// rdar://16095748
llvm-svn: 202872
|
|
|
|
|
|
| |
LLVM r202816.
llvm-svn: 202817
|
|
|
|
|
|
|
| |
for metadata symbols for forward referenced protocols which
are never defined. // rdar://16203115
llvm-svn: 202761
|
|
|
|
| |
llvm-svn: 202625
|
|
|
|
| |
llvm-svn: 202429
|
|
|
|
|
|
|
|
|
|
|
|
| |
In llvm the only semantic difference between internal and private is that llvm
tries to hide private globals my mangling them with a private prefix. Since
the globals changed by this patch already had the magic don't mangle marker,
there should be no change in the generated assembly.
A followup patch should then be able to drop the \01L and \01l prefixes and let
llvm mangle as appropriate.
llvm-svn: 202419
|
|
|
|
|
|
|
| |
No functionality change. This is just an intermediate patch for changing those
global variables to use private linkage.
llvm-svn: 202409
|
|
|
|
| |
llvm-svn: 202330
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch the globals were created with the wrong linkage and patched
afterwards. From the comments it looks like something would complain about
having an internal GV with no initializer. At least in clang the verifier will
only run way after we set the initializer, so that is not a problem.
This patch should be a nop. It just figures out the linkage earlier and
converts the old calls to setLinkage to asserts. The only case where that is
not possible is when we first see a weak import that is then implemented. In
that case we have to change the linkage, but that is the only setLinkage left.
llvm-svn: 202305
|
|
|
|
|
|
|
| |
on correctly handled block layout IRGen.
// rdar://16111839
llvm-svn: 202063
|
|
|
|
| |
llvm-svn: 201791
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|