as well as attached a new priority description as to why and when you would
want to implement each packet.
Also documented the additions we have made to the stop reply packet and why
the extra information is necessary.
llvm-svn: 145357
non_lazy_symbol_pointers section (__IMPORT,__pointers). Ignore the 'hidden' part
since that will place it in the wrong section.
<rdar://problem/10443720>
llvm-svn: 145356
- I verified locally that the current dependency lists are identical.
- This makes add_llvm_library_dependencies() a no-op. I'll remove it once this
change passes the bots.
llvm-svn: 145355
management of what allocations remain after an
expression finishes executing. This saves around
2.5KiB per expression for simple expressions.
llvm-svn: 145342
I suspect we could profitably remove/move some of the bullet points
under Clang here to the Clang notes in order to keep things clean on
both sides. Unless I hear objections I'll start doing that once folks
have read over the Clang notes a bit.
llvm-svn: 145340
the release notes despite their awesomeness. If we had a thorough
discussion of the performance of Clang in 2.9 vs. 3.0, the first would
be more relevant, but we don't. The serialization stuff hopefully isn't
terribly visible to end users.
Objections to these omissions are of course welcome. =]
llvm-svn: 145336
attribute. This prevents the stack slot allocator from coming along and using a
stack which it thinks is available but isn't.
<rdar://problem/10492556>
llvm-svn: 145332
- Currently just tries to build a full library for i386/x86_64.
- This is made substantially more complicated by the lack of a generalized way
to check for/invoke cross compilers. For now, we just try and make it work
for the matched arch, and rely on the host CC being Clang.
llvm-svn: 145322
return the module itself (in the module map) rather than returning the
umbrella header used to build the module. While doing this, make sure
that we're inferring modules for frameworks to build that module.
llvm-svn: 145310
accurate than my original notes were based on IRC conversations. Windows
folks, please edit as needed to make this closer to the truth if I've
still got it wrong.
llvm-svn: 145309
add a bit to that section about the many bug-finding warnings that Clang
has grown since 2.9 as this is one of the more visible new additions.
llvm-svn: 145307
Conservatively returns zero when the GV does not specify an alignment nor is it
initialized. Previously it returns ABI alignment for type of the GV. However, if
the type is a "packed" type, then the under-specified alignments is attached to
the load / store instructions. In that case, the alignment of the type cannot be
trusted.
rdar://10464621
llvm-svn: 145300
Peter Collingbourne