Currently we register instrumentation data at runtime to determine the
bounds of the sections where the data lives. Soon we'll implement
platform-specific linker magic to determine this at link time.
Move this logic to a separate file, so that our build system can choose
the correct platform-specific code.
No functionality change intended.
<rdar://problem/15943240>
llvm-svn: 204299
If the environment variable is defined and not empty, RoundTrip tests
are run. The reason to move the tests behind the flag is because they
are too slow to enable by default.
LLD linking time on llvm-tblgen improved from 2m7s to 2.3s. About 60x
faster now in this case.
Differential Revision: http://llvm-reviews.chandlerc.com/D3126
llvm-svn: 204296
Given
bar = foo + 4
.long bar
MC would eat the 4. GNU as includes it in the relocation. The rule seems to be
that a variable that defines a symbol is used in the relocation and one that
does not define a symbol is evaluated and the result included in the relocation.
Fixing this unfortunately required some other changes:
* Since the variable is now evaluated, it would prevent the ELF writer from
noticing the weakref marker the elf streamer uses. This patch then replaces
that with a VariantKind in MCSymbolRefExpr.
* Using VariantKind then requires us to look past other VariantKind to see
.weakref bar,foo
call bar@PLT
doing this also fixes
zed = foo +2
call zed@PLT
so that is a good thing.
* Looking past VariantKind means that the relocation selection has to use
the fixup instead of the target.
This is a reboot of the previous fixes for MC. I will watch the sanitizer
buildbot and wait for a build before adding back the previous fixes.
llvm-svn: 204294
opcode is VAX. A function call pushes the number of arguments given onto
the stack and "ret" will pop it automatically. The FDE of the caller
contains the amount of stack space used for arguments (and possibly
extra padding), so unwinding has to compensate for this when "returning"
from a function. This is exactly the case when step() is done. The
existing handling in unw_set_reg no longer makes sense.
llvm-svn: 204290
InputElement::parse() may recursively call WinLinkDriver::parse() to handle
.drectve section contents, and if /defaultlib option exists in the section,
the driver will mutate the input graph to add a new input file to the graph.
So the access to input graph needs to be protected with mutext.
llvm-svn: 204285
This commit moves us from a single range per subprogram to extending
ranges if we are:
a) In the same section, and
b) In the same enclosing CU.
This means we have more fine grained ranges for compile units, and fewer
ranges overall when we have multiple functions in the same CU
adjacent to each other in the object file.
Also remove all of the earlier hacks around this functionality for
function sections etc. Also update all of the testcases to take into
account the merging functionality.
llvm-svn: 204277
It isn't actually used now, and probably never will be, plus it makes
tests less annoying. I also think SC prints GDS instructions as a
separate instruction name.
llvm-svn: 204270
Split implementation files along a uses-libc/shouldn't-use-libc
boundary.
- InstrProfiling.h is a shared header.
- InstrProfiling.c provides an API to extract profiling data from the
runtime, but avoids the use of libc. Currently this is a lie:
__llvm_pgo_write_buffer() uses `FILE*` and related functions. It
will be updated soon to write to a `char*` buffer instead.
- InstrProfilingExtras.c provides a more convenient API for
interfacing with the profiling runtime, but has logic that does (and
will continue to) use libc.
<rdar://problem/15943240>
llvm-svn: 204268
This name, while more verbose, plays more nicely with tools that use
file extensions to determine file types. The existing spelling
'module.map' will continue to work, but the new spelling will take
precedence.
In frameworks, this new filename will only go in a new 'Modules'
sub-directory.
Similarly, add a module.private.modulemap corresponding to
module_private.map.
llvm-svn: 204261
This patch enables vectorization of loops containing backward array
traversal (array stride is -1).
Contributed-by: Chris Jenneisch <chrisj@codeaurora.org>
llvm-svn: 204257
This ensures that the polly passes get properly registered both, when using
polly as a loadable module and when directly linking it into clang/opt/bugpoint.
llvm-svn: 204255
Duncan P. N. Exon Smith