Add some Windows on ARM specific library calls. These are provided by msvcrt,
and can be used to perform integer to floating-point conversions (and
vice-versa) mirroring similar functions in the RTABI.
llvm-svn: 208949
If `-shared` is specified, pull in a PIC-version of the profile runtime,
which was added to compiler-rt in r208947. I'm hoping this will get the
bots on my side.
llvm-svn: 208948
These tests were XPASS-ing on Linux bots creating Mach-O, which makes
sense, since the real difference is the object format.
I'm hoping a short-term fix to get these tests passing on ELF is to
create two copies of the runtime -- one built with -fPIC, and one
without. A follow-up patch will change clang's driver to pick between
them depending on whether `-shared` is specified.
llvm-svn: 208947
According to the buildbots, the new features for shared objects don't
work on ELF since it requires an -fPIC when building the profile
library. XFAIL these tests for now.
It's possible we'll have to build two versions of the profile library on
Linux (one with -fPIC and one without), but it's not clear to me exactly
how to resolve this.
llvm-svn: 208946
Sometimes a LLVM compilation may take more time then a client would like to
wait for. The problem is that it is not possible to safely suspend the LLVM
thread from the outside. When the timing is bad it might be possible that the
LLVM thread holds a global mutex and this would block any progress in any other
thread.
This commit adds a new yield callback function that can be registered with a
context. LLVM will try to yield by calling this callback function, but there is
no guaranteed frequency. LLVM will only do so if it can guarantee that
suspending the thread won't block any forward progress in other LLVM contexts
in the same process.
Once the client receives the call back it can suspend the thread safely and
resume it at another time.
Related to <rdar://problem/16728690>
llvm-svn: 208945
r207606 changed the __need_foo macros to behave like they do with gcc: If they
are set, _only_ the __need_foo stuff gets defined. As a consequence, cstddef
no longer defined "offsetof". It looks like the __need_foo defines aren't
needed anymore, so just remove them.
Fixes PR19723.
llvm-svn: 208942
Change the API of the instrumented profiling library to work with shared
objects.
- Most things are now declared hidden, so that each executable gets
its own copy.
- Initialization hooks up a linked list of writers.
- The raw format with shared objects that are profiled consists of a
concatenated series of profiles. llvm-profdata knows how to deal
with that since r208938.
<rdar://problem/16918688>
llvm-svn: 208940
Shared objects are fairly broken for InstrProf right now -- a follow-up
commit in compiler-rt will fix the rest of this.
The main problem here is that at link time, profile data symbols in the
shared object might get used instead of symbols from the main
executable, creating invalid profile data sections.
<rdar://problem/16918688>
llvm-svn: 208939
Allow multiple raw profiles to coexist in a single .profraw file,
given the following conditions:
- Zero padding at the end of or between profiles will be skipped.
- Each profile must start with a valid header.
- Mixing endianness or pointer sizes in concatenated profiles files is
not allowed.
This is needed to handle cases where a program's shared libraries are
profiled as well as the main executable itself, as we'll need to emit
each executable's counters. Combining the tables in the runtime would
be expensive for the instrumented program.
rdar://16918688
llvm-svn: 208938
This commit implements two command line switches -global-merge-on-external
and -global-merge-aligned, and both of them are false by default, so this
optimization is disabled by default for all targets.
For ARM64, some back-end behaviors need to be tuned to get this optimization
further enabled.
llvm-svn: 208934
Since type units in the dwo file are handled by a debug aware tool, they
don't need to leverage the ELF comdat grouping to implement
deduplication. Avoid creating all the .group sections for these as a
space optimization.
llvm-svn: 208930
This allows us to perfectly forward non-trivial arguments that use
inalloca.
We still can't forward non-trivial arguments through thunks when we have
a covariant return type with a non-trivial adjustment. This would
require emitting an extra copy, which is non-conforming anyway.
llvm-svn: 208927
All callers were passing in "a.out" or garbage so a sensible default works fine
here as a cleanup.
This also brings about the possibility of adapting the value based on the
driver's compatibility mode in future.
The setting can still be changed via Driver::DefaultImageName as needed.
llvm-svn: 208926
It is more appropriate than the current situation, when one flag
(AbsoluteFilePath) is relevant only if another flag is set.
This refactoring would also simplify fetching the short function name
(stored in DW_AT_name) instead of a linkage name returned currently.
No functionality change.
llvm-svn: 208921
The allocas going out of scope are immediately killed by the return
instruction.
This is a resend of r208912, which was committed accidentally.
Reviewers: chandlerc
Differential Revision: http://reviews.llvm.org/D3792
llvm-svn: 208920
We have to iterate over all the calls that were inlined to find out if
any were musttail.
Sink another variable down to where its used.
llvm-svn: 208913
The allocas going out of scope are immediately killed by the return
instruction.
Reviewers: chandlerc
Differential Revision: http://reviews.llvm.org/D3630
llvm-svn: 208912
The interesting case is what happens when you inline a musttail call
through a musttail call site. In this case, we can't break perfect
forwarding or allow any stack growth.
Instead of merging control flow from the inlined return instruction
after a musttail call into the body of the caller, leave the inlined
return instruction in the caller so that the musttail call stays in the
tail position.
More work is required in http://reviews.llvm.org/D3630 to handle the
case where the inlined function has dynamic allocas or byval arguments.
Reviewers: chandlerc
Differential Revision: http://reviews.llvm.org/D3491
llvm-svn: 208910
The symlink needs to point to a relative path, so we don't break
building in a chroot.
Tested-by: Laurent Carlier <lordheavym@gmail.org>
llvm-svn: 208908
When using the VFS, we want the virtual header location when searching
for a framework module, since that will be the one in the correct
directory structure for the module.
I'll add a regression test once I finish reducing the larger one I have.
llvm-svn: 208901
Saleem Abdulrasool