The major changes are:
1) LinkerOptions has been merged into TargetInfo
2) LinkerInvocation has been merged into Driver
3) Drivers no longer convert arguments into an intermediate (core) argument
list, but instead create a TargetInfo object and call setter methods on
it. This is only how in-process linking would work. That is, you can
programmatically set up a TargetInfo object which controls the linking.
4) Lots of tweaks to test suite to work with driver changes
5) Add the DarwinDriver
6) I heavily doxygen commented TargetInfo.h
Things to do after this patch is committed:
a) Consider renaming TargetInfo, given its new roll.
b) Consider pulling the list of input files out of TargetInfo. This will
enable in-process clients to create one TargetInfo the re-use it with
different input file lists.
c) Work out a way for Drivers to format the warnings and error done in
core linking.
llvm-svn: 178776
The Thumb2SizeReduction pass avoids false CPSR dependencies, except it
still aggressively creates tMOVi8 instructions because they are so
common.
Avoid creating false CPSR dependencies even for tMOVi8 instructions when
the the CPSR flags are known to have high latency. This allows integer
computation to overlap floating point computations.
Also process blocks in a reverse post-order and propagate high-latency
flags to successors.
<rdar://problem/13468102>
llvm-svn: 178773
Having these not be the same makes an easy to misuse API. We should audit the
uses and probably rename to something like
foo->hasExternalLinkage():
The c++ standard one. That is UniqueExternalLinkage or ExternalLinkage.
foo->hasUniqueExternalLinkage():
Is UniqueExternalLinkage.
foo->hasCogeGenExternalLinkage():
Is ExternalLinkage.
llvm-svn: 178768
This mostly reverts 178733, but keeps the tests.
I don't claim to understand how hidden sub modules work or when we need to see
them (is that documented?), but this has the same semantics and avoids adding
hasExternalLinkageUncached which has the same foot gun potential as the old
hasExternalLinkage.
Last but not least, not computing linkage when it is not needed is more
efficient.
llvm-svn: 178739
This requires v9 cmov instructions using the %xcc flags instead of the
%icc flags.
Still missing:
- Select floats on %xcc flags.
- Select i64 on %fcc flags.
llvm-svn: 178737
This test was exactly the opposite of what it should be. We should check if
there old decl has linkage (where it makes sense) and if the new decl has
the extern keyword.
llvm-svn: 178735
caching the linkage for a declaration before we set up its redeclaration chain,
when determining whether a declaration could be a redeclaration of something
from an unimported submodule. We actually want to look at the declaration as if
it were not a redeclaration here, so compute the linkage but don't cache it.
llvm-svn: 178733
of a property just in case the property's getter happens to be +1.
We won't synthesize a getter for such a property, but we will allow
the user to define a +1 method for it.
rdar://13115896
llvm-svn: 178731
The __NSArrayI synthetic children provider was running expressions to generate children, which is inefficient for large amounts of data
Reimplementing to use a faster algorithm
llvm-svn: 178729
Try and reap process when sending the "k" packet to avoid a race condition. We now wait for at most 1 second to reap the child process that we are killing.
llvm-svn: 178726
On freebsd this makes sure that symbols are exported on the binaries that need
them. The net result is that we should get symbols in the binaries that need
them on every platform.
On linux x86-64 this reduces the size of the bin directory from 262MB to 250MB.
Patch by Stephen Checkoway.
llvm-svn: 178725
This is a nop right now, but committing this first avoids a temporary breakage
when the llvm files change to not default to exporting symbols.
llvm-svn: 178723
the target system.
It was hard-coded to 4 bytes before. I can't get llvm to generate a
ref_addr on a reasonably sized testing case.
rdar://problem/13559431
llvm-svn: 178722
Changes to lldb made the following fail when it used to work:
% cd /tmp
% lldb ls
error: unable to find executable for '/tmp/ls'
Resolving an executable with no relative path was broken, now its fixed.
llvm-svn: 178719
Nick Kledzik