`Type` parameter was used only to check for TLS attribute mismatch,
but we can do that when we actually replace symbols, so we don't need
to type as an argument. This change should simplify the interface of
the symbol table a bit.
llvm-svn: 344394
This a resubmission of a patch which was previously reverted
due to breaking several lld tests. The issues causing those
failures have been fixed, so the patch is now resubmitted.
---Original Commit Message---
While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.
The tools need to be able to handle this, because certain types
of debugging scenarios are possible without a running process
and so don't necessarily require you to be on a Windows system.
These include post-mortem debugging and binary forensics (e.g.
using a debugger to disassemble functions and examine symbols
without running the process).
There's changes in clang, LLD, and lldb in this patch. After
this the cross-platform disassembly and source-list tests pass
on Linux.
Furthermore, the behavior of LLD can now be summarized by a much
simpler rule than before: Unless you specify /pdbsourcepath and
/pdbaltpath, the PDB ends up with paths that are valid within
the context of the machine that the link is performed on.
Differential Revision: https://reviews.llvm.org/D53149
llvm-svn: 344377
If you have the string /usr/bin, prior to this patch it would not
be quoted by our YAML serializer. But a string like C:\src would
be, due to the presence of a backslash. This makes the quoting
rules of basically every single file path different depending on
the path syntax (posix vs. Windows).
While technically not required by the YAML specification to quote
forward slashes, when the behavior of paths is inconsistent it
makes it difficult to portably write FileCheck lines that will
work with either kind of path.
Differential Revision: https://reviews.llvm.org/D53169
llvm-svn: 344359
This reverts commit b86c16ad8c97dadc1f529da72a5bb74e9eaed344.
This is being reverted because I forgot to write a useful
commit message, so I'm going to resubmit it with an actual
commit message.
llvm-svn: 344358
Android uses a compressed relocation format, which means the size of the
relocation section isn't predictable based on the number of relocations,
and can vary if the layout changes in any way. To deal with this, the
linker normally runs multiple passes until the layout converges.
The layout should converge if the size of the compressed
relocation section increases monotonically: if the size of an encoded
offset increases by one byte, the larget value which can be encoded is
multiplied by 128, so the representable offsets grow much faster than
the size of the section itself.
The problem here is that there is no code to ensure the size of the
section doesn't decrease. If the size of the relocation section
decreases, the relative offsets can increase due to alignment
restrictions, so that can force the size of the relocation section to
increase again. The end result is an infinite loop; the loop gets cut
off after 10 iterations with the message "thunk creation not
converged".
To avoid this issue, this patch adds padding to the end of the
relocation section if its size would decrease. The extra
padding is harmless because of the way the format is defined:
decoding stops after it reaches the number of relocations specified
in the section's header.
Differential Revision: https://reviews.llvm.org/D53003
llvm-svn: 344300
This was originally causing some test failures on non-Windows
platforms, which required fixes in the compiler and linker. After
those fixes, however, other tests started failing. Reverting
temporarily until I can address everything.
llvm-svn: 344279
While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.
The tools need to be able to handle this, because certain types
of debugging scenarios are possible without a running process
and so don't necessarily require you to be on a Windows system.
These include post-mortem debugging and binary forensics (e.g.
using a debugger to disassemble functions and examine symbols
without running the process).
There's changes in clang, LLD, and lldb in this patch. After
this the cross-platform disassembly and source-list tests pass
on Linux.
Furthermore, the behavior of LLD can now be summarized by a much
simpler rule than before: Unless you specify /pdbsourcepath and
/pdbaltpath, the PDB ends up with paths that are valid within
the context of the machine that the link is performed on.
Differential Revision: https://reviews.llvm.org/D53149
llvm-svn: 344269
When these are accessed with load/store instructions on ARM64,
it becomes strictly necessary to have them properly aligned.
This fixes PR39228.
Differential Revision: https://reviews.llvm.org/D53128
llvm-svn: 344264
This is https://bugs.llvm.org/show_bug.cgi?id=37538,
Currently, LLD may set both sh_link and sh_info for
.rela.plt section to zero when we have only .rela.iplt section part used.
ELF spec (https://docs.oracle.com/cd/E19683-01/816-1386/chapter6-94076/index.html)
says that for SHT_REL and SHT_RELA, sh_link references the associated symbol table
and sh_info the "section to which the relocation applies."
When we set the sh_link field, for the regular case we use the .dynsym index.
For .rela.iplt sections, it is unclear what is the associated symbol table,
because R_*_RELATIVE relocations do not use symbol names and we might have no
.dynsym section at all so this patch uses .symtab section index.
Differential revision: https://reviews.llvm.org/D52830
llvm-svn: 344226
Summary:
Add a condition UnresolvedPolicy::Ignore to elf::warnUnorderedSymbol to suppress Sym->isUndefined() warnings from both
1) --symbol-ordering-file=
2) .llvm.call-graph-profile
If --unresolved-symbols=ignore-all is used,
no "undefined symbol" error/warning is emitted. It makes sense to not warn unorderable symbols.
Otherwise,
If an executable is linked, the default policy UnresolvedPolicy::ErrorOrWarn will issue a "undefined symbol" error. The unorderable symbol warning is redundant.
If a shared object is linked, it is possible that only part of object files are used and some symbols are left undefined. The warning is not very necessary.
In particular for .llvm.call-graph-profile, when linking a shared object, a call graph profile may contain undefined symbols. This case generated a warning before but it will be suppressed by this patch.
Reviewers: ruiu, davidxl, espindola
Reviewed By: ruiu
Subscribers: grimar, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D53044
llvm-svn: 344195
This allows using #pragma comment(lib, "foo") in MinGW built code,
if built with -fms-extensions. (This works for system libraries and
static libraries only, as it doesn't try to look for .dll.a. As
ld.bfd doesn't support embedded defaultlib directives, this isn't
in widespread use among mingw users.)
Differential Revision: https://reviews.llvm.org/D53017
llvm-svn: 344124
This is necessary for handling defaultlib directives embedded in
object files, unless they use an absolute path.
Differential Revision: https://reviews.llvm.org/D53015
llvm-svn: 344123
Summary: Before, OptTable::PrintHelp append "[options] <inputs>" to its parameter `Help`. It is more flexible to change its semantic to `Usage` and let user customize the usage line.
Reviewers: rupprecht, ruiu, espindola
Reviewed By: rupprecht
Subscribers: emaste, sbc100, arichardson, aheejin, llvm-commits
Differential Revision: https://reviews.llvm.org/D53054
llvm-svn: 344099
Previously, we cast a pointer to Elf{32,64}_Chdr like this
auto *Hdr = reinterpret_cast<const ELF64_Chdr>(Ptr);
and read from its members like this
read32(&Hdr->ch_size);
I was thinking that this does not violate alignment requirement,
since &Hdr->ch_size doesn't really access memory, but seems like
it is a violation in terms of C++ spec (?)
In this patch, I use a different struct that allows unaligned access.
llvm-svn: 344083
`SymbolTable` is a singleton class and is a global variable for the
unique instance, so we can always refer the symtab by `Symtab->`.
However, we don't need to use the global varaible from member functions
of SymbolTable class.
llvm-svn: 344075
/pdbsourcepath: was added in https://reviews.llvm.org/D48882 to make it
possible to have relative paths in the debug info that clang-cl writes.
lld-link then makes the paths absolute at link time, which debuggers require.
This way, clang-cl's output is independent of the absolute path of the build
directory, which is useful for cacheability in distcc-like systems.
This patch extends /pdbsourcepath: (if passed) to also be used for:
1. The "cwd" stored in the env block in the pdb is /pdbsourcepath: if present
2. The "exe" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
3. The "pdb" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
4. For making absolute paths to .obj files referenced from the pdb
/pdbsourcepath: is now useful in three scenarios (the first one already working
before this change):
1. When building with full debug info, passing the real build dir to
/pdbsourcepath: allows having clang-cl's output to be independent
of the build directory path. This patch effectively doesn't change
behavior for this use case (assuming the cwd is the build dir).
2. When building without compile-time debug info but linking with /debug,
a fake fixed /pdbsourcepath: can be passed to get symbolized stacks
while making the pdb and exe independent of the current build dir.
For this two work, lld-link needs to be invoked with relative paths for
the lld-link invocation itself (for "exe"), for the pdb output name, the exe
output name (for "pdb"), and the obj input files, and no absolute path
must appear on the link command (for "cmd" in the pdb's env block).
Since no full debug info is present, it doesn't matter that the absolute
path doesn't exist on disk -- we only get symbols in stacks.
3. When building production builds with full debug info that don't have
local changes, and that get source indexed and their pdbs get uploaded
to a symbol server. /pdbsourcepath: again makes the build output independent
of the current directory, and the fixed path passed to /pdbsourcepath: can
be given the source indexing transform so that it gets mapped to a
repository path. This has the same requirements as 2.
This patch also makes it possible to create PDB files containing Windows-style
absolute paths when cross-compiling on a POSIX system.
Differential Revision: https://reviews.llvm.org/D53021
llvm-svn: 344061
Previously, we uncompress all compressed sections before doing anything.
That works, and that is conceptually simple, but that could results in
a waste of CPU time and memory if uncompressed sections are then
discarded or just copied to the output buffer.
In particular, if .debug_gnu_pub{names,types} are compressed and if no
-gdb-index option is given, we wasted CPU and memory because we
uncompress them into newly allocated bufers and then memcpy the buffers
to the output buffer. That temporary buffer was redundant.
This patch changes how to uncompress sections. Now, compressed sections
are uncompressed lazily. To do that, `Data` member of `InputSectionBase`
is now hidden from outside, and `data()` accessor automatically expands
an compressed buffer if necessary.
If no one calls `data()`, then `writeTo()` directly uncompresses
compressed data into the output buffer. That eliminates the redundant
memory allocation and redundant memcpy.
This patch significantly reduces memory consumption (20 GiB max RSS to
15 Gib) for an executable whose .debug_gnu_pub{names,types} are in total
5 GiB in an uncompressed form.
Differential Revision: https://reviews.llvm.org/D52917
llvm-svn: 343979
This matches the output of binutils' nm and ensures that any scripts
or tools that use nm and expect empty output in case there no symbols
don't break.
Differential Revision: https://reviews.llvm.org/D52943
llvm-svn: 343887
ld.bfd doesn't do any inference of subsystem; unless the windows
subsystem is specified, the console subsystem is used.
For the console subsystem, the entry point is called mainCRTStartup,
regardless of whether the the user code entry point is main or wmain.
The same goes for the windows subsystem, where the entry point always
is WinMainCRTStartup, for both WinMain and wWinMain in user code.
One detail that we don't emulate, is that if the inferred entry point
is undefined, ld.bfd silently just sets the entry point to the start
of the image. And if an explicit entry point is set, but it is
undefined, the link still succeeds but the linker warns about the
entry point not being found.
Differential Revision: https://reviews.llvm.org/D52931
llvm-svn: 343879
For certain cases of inline functions written to comdat sections,
GCC 5.x produces a weak symbol in addition, which would end up
undefined in some cases.
This no longer seems to happen with GCC 6.x or newer though.
Differential Revision: https://reviews.llvm.org/D52602
llvm-svn: 343877
(patch by Benoit Rousseau)
This patch fixes a bug where the global variable initializers were sometimes not invoked in the correct order when it involved a C++ template instantiation.
Differential Revision: https://reviews.llvm.org/D52749
llvm-svn: 343847
The GOT is referenced through the symbol _GLOBAL_OFFSET_TABLE_ .
The relocation added calculates the offset into the global offset table for
the entry of a symbol. In order to get the correct TargetVA I needed to
create an new relocation expression, HEXAGON_GOT. It does
Sym.getGotVA() - In.GotPlt->getVA().
Differential Revision: https://reviews.llvm.org/D52744
llvm-svn: 343784
r320770 made LLD handle invalid DSOs where local symbols were found in
the global part of the symbol table. Unfortunately, it didn't handle the
case where those local symbols were also undefined, and r326242 exposed
an assertion failure in that case. Just warn on that case instead of
crashing, by moving the local binding check before the undefined symbol
addition.
The input file for the test is crafted by hand, since I don't know of
any tool that would produce such a broken DSO. I also don't understand
what it even means for a symbol to be undefined but have STB_LOCAL
binding - I don't think that combination makes any sense - but we have
found broken DSOs of this nature that we were linking against. I've
included detailed instructions on how to produce the DSO in the test.
Differential Revision: https://reviews.llvm.org/D52815
llvm-svn: 343745
This patch splits ThunkCreator::mergeThunks into two smaller functions.
Also adds blank lines to various places so that the code doesn't look
too dense.
llvm-svn: 343732
A test verifying that toc restores are properly inserted following recursive
calls, as well as briefly describing why they are needed.
Differential Revision: https://reviews.llvm.org/D52564
llvm-svn: 343729
When GNU tools create a weak alias, they produce a strong symbol
named .weak.<weaksymbol>.<relatedstrongsymbol>.
GNU ld allows many such weak alternatives for the same weak symbol, and
the linker picks the first one encountered.
This can't be reproduced by assembling from .s files, since llvm-mc
produces symbols named .weak.<weaksymbol>.default in these cases.
Differential Revision: https://reviews.llvm.org/D52601
llvm-svn: 343704
Three related changes:
1. link.exe uses the presence of main and wmain to decide if it should call
mainCRTStartup or wmainCRTStartup, even if /nodefaultlib is passed. For
compatibility, remove FindMain logic.
2. Default to the non-wide entrypoint if main is not found. This has two effects:
2a. In normal links, lld-link now prints
lld-link: error: undefined symbol: _main
>>> referenced by f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:78
>>> libcmt.lib(exe_main.obj):("int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ))
>>> referenced by f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283
>>> libcmt.lib(exe_main.obj):("int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ))
instead of
lld-link: error: entry point must be defined
This is arguably a better error message, since it now mentions that _main is
missing. (This matches link.exe's diagnostic in this case.)
2b. With /nodefautlib, we now default to mainCRTStartup if no main() is
present, again matching link.exe. This makes r337407 obsolete.
This means if you have a cc file containing both mainCRTStartup and
wmainCRTStartup and you pass /nodefaultlib /subsystem:console, lld-link will
now call mainCRTStartup, matching link.exe
3. Print a warning if both main and wmain are present, similar to link.exe's
LNK4067.
Differential Revision: https://reviews.llvm.org/D52832
llvm-svn: 343698
This stops testing the value of .rela.plt section offset.
Also makes _start global to eliminate
'cannot find entry symbol _start' warning.
llvm-svn: 343669
This is the fix for
"Bug 39104 - LLD links incorrect ELF executable if version script contains "local: *;"
(https://bugs.llvm.org/show_bug.cgi?id=39104).
The issue happens when we have non-PIC program call to function in a shared library.
(for example, the PR above has R_X86_64_PC32 relocation against __libc_start_main)
LLD converts symbol to Defined in that case with the use of replaceWithDefined()
The issue is that after above we create a broken relocation because do not
include the symbol into .dynsym.
That happens when the version script is used because we treat the symbol as
STB_LOCAL if the following condition match:
VersionId == VER_NDX_LOCAL && isDefined() and do not include it to
.dynsym because of that. Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D52724
llvm-svn: 343668
Imagine we have the following code:
int foo();
int main() { return foo(); }
It will crash if you try to compile it with
`clang -O0 -gdwarf-5 test.cpp -o test -g -fuse-ld=lld`
The crash happens inside the LLVM DWARF parser because LLD does not provide
the .debug_line_str section. At the same time for correct parsing and reporting,
we anyways need to provide this section from our side.
The patch fixes the issue.
llvm-svn: 343667
Summary:
This patch adds a new flag, --warn-ifunc-textrel, to work around a glibc bug. When a code with ifunc symbols is used to produce an object file with text relocations, lld always succeeds. However, if that object file is linked using an old version of glibc, the resultant binary just crashes with segmentation fault when it is run (The bug is going to be corrected as of glibc 2.19).
Since there is no way to tell beforehand what library the object file will be linked against in the future, there does not seem to be a fool-proof way for lld to give an error only in cases where the binary will crash. So, with this change (dated 2018-09-25), lld starts to give a warning, contingent on a new command line flag that does not have a gnu counter part. The default value for --warn-ifunc-textrel is false, so lld behaviour will not change unless the user explicitly asks lld to give a warning. Users that link with a glibc library with version 2.19 or newer, or does not use ifunc symbols, or does not generate object files with text relocations do not need to take any action. Other users may consider to start passing warn-ifunc-textrel to lld to get early warnings.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: grimar, MaskRay, markj, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D52430
llvm-svn: 343628
llvm rL343594: [ARM] Emmit data symbol
for constant pool data fixed a bug that ommited
required data symbols.
Such change breaked a test case in lld:
test/ELF/arm-thunk-largesection.s
llvm-svn: 343604
This uses the call graph profile embedded in the object files to construct the call graph.
This is read from a SHT_LLVM_CALL_GRAPH_PROFILE (0x6fff4c02) section as (uint32_t, uint32_t, uint64_t) tuples as (from symbol index, to symbol index, weight).
Differential Revision: https://reviews.llvm.org/D45850
llvm-svn: 343552
When GCC produces a jump table as part of a comdat function, the
jump table itself is produced as plain non-comdat rdata section. When
linked with ld.bfd, all of those rdata sections are kept, with
relocations unchanged in the sections that refer to discarded comdat
sections.
This has been observed with at least GCC 5.x and 7.x.
Differential Revision: https://reviews.llvm.org/D52600
llvm-svn: 343422
With LTO when and undefined function (with a known signature)
in replaced by a defined bitcode function we were loosing the
signature information (since bitcode functions don't have
signatures).
With this change we preserve the original signature from the
undefined function and verify that the post LTO compiled
function has the correct signature.
This change improves the error handling in the case where
there is a signature mismatch with a function defined in
a bitcode file.
Differential Revision: https://reviews.llvm.org/D50721
llvm-svn: 343340
In a very recent change I introduced a --no-export-default flag
but after conferring with others it seems that this feature already
exists in gnu GNU ld and lld in the form the --export-dynamic flag
which is off by default.
This change replaces export-default with export-dynamic and also
changes the default to match the traditional linker behaviour.
Now, by default, only the entry point is exported. If other symbols
are required by the embedder then --export-dynamic or --export can
be used to export all visibility hidden symbols or individual
symbols respectively.
This change touches a lot of tests that were relying on symbols
being exported by default. I imagine it will also effect many
users but do think the change is worth it match of the traditional
behaviour and flag names.
Differential Revision: https://reviews.llvm.org/D52587
llvm-svn: 343265
Add REQUIRES: x86 to pdb-debug-f.s as this is causing the Arm and
AArch64 buildbots to fail as they do not have the x86 backend.
Differential Revision: https://reviews.llvm.org/D52606
llvm-svn: 343196
Summary: The convenience wrapper in STLExtras is available since rL342102.
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, mgrang, llvm-commits
Differential Revision: https://reviews.llvm.org/D52569
llvm-svn: 343146
Summary:
lld already gives later -z options precedence in getZFlag().
This matches the behavior of ld.bfd and ld.gold, where later options
override earlier ones. (I tested with -z max-page-size and -z stack-size.)
Reviewers: ruiu, espindola, grimar
Reviewed By: ruiu, grimar
Subscribers: grimar, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D52526
llvm-svn: 343145
Summary:
An AArch64 LE relocation is a positive ("variant 1") offset. This
relocation is used to write the upper 12 bits of a 24-bit offset into an
add instruction:
add x0, x0, :tprel_hi12:v1
The comment in the ARM docs for R_AARCH64_TLSLE_ADD_TPREL_HI12 is:
"Set an ADD immediate field to bits [23:12] of X; check 0 <= X < 2^24."
Reviewers: javed.absar, espindola, ruiu, peter.smith, zatrazz
Reviewed By: ruiu
Subscribers: emaste, arichardson, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D52525
llvm-svn: 343144
This is https://bugs.llvm.org//show_bug.cgi?id=38919.
Currently, LLD may report "unsupported relocation target while parsing debug info"
when parsing the debug information.
At the same time LLD does that for zeroed R_X86_64_NONE relocations,
which obviously has "invalid" targets.
The nature of R_*_NONE relocation assumes them should be ignored.
This patch teaches LLD to stop reporting the debug information parsing errors for them.
Differential revision: https://reviews.llvm.org/D52408
llvm-svn: 343078
This involves adding more generic list of symbol suffixes/prefixes
to ignore for autoexport; adding a few other entries to these lists
as well from the corresponding lists in binutils.
Differential Revision: https://reviews.llvm.org/D52382
llvm-svn: 343070
Don't assume that the IAT chunk will be a DefinedImportData, it can
just as well be a DefinedRegular for gnu import libraries.
Differential Revision: https://reviews.llvm.org/D52381
llvm-svn: 343069
These option control weather or not symbols marked as visibility
default are exported in the output binary.
By default this is true, but emscripten prefers to control the
exported symbol list explicitly at link time and ignore the
symbol attributes.
Differential Revision: https://reviews.llvm.org/D52003
llvm-svn: 343034
When we write a struct to a mmap'ed buffer, we usually use
write16/32/64, but we didn't for VersionDefinitionSection, so
we needed to template that class.
llvm-svn: 343024
Previously, if you invoke lld's `main` more than once in the same process,
the second invocation could fail or produce a wrong result due to a stale
pointer values of the previous run.
Differential Revision: https://reviews.llvm.org/D52506
llvm-svn: 343009
This is a feature that MS link.exe lacks; it currently errors out on
such relocations, just like lld did before.
This allows linking clang.exe for ARM - practically, any image over
16 MB will likely run into the issue.
Differential Revision: https://reviews.llvm.org/D52156
llvm-svn: 342962
Summary:
Currently we are pointing all debug information that refer removed function code
to the beginning of the code section (offset = 0). A debugger may want to
resolve code offset to the debug information, which will collide with offsets
of the live functions.
Moving offsets of dead functions outside code section range.
Reviewers: sbc100
Reviewed By: sbc100
Subscribers: dblaikie, ruiu, alexcrichton, dschuff, aprantl, jgravelle-google, aheejin, sunfish, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D49446
llvm-svn: 342930
Implement final argument precedence if multiple /debug arguments are passed on the command-line to match expected link.exe behavior.
Support /debug:none and emit warning for /debug:fastlink with automatic fallback to /debug:full.
Emit error if last /debug:option is unknown.
Emit warning if last /debugtype:option is unknown.
https://reviews.llvm.org/D50404
llvm-svn: 342894
GNU binutils import libraries aren't the same kind of short import
libraries as link.exe and LLD produce, but are a plain static library
containing .idata section chunks. MSVC link.exe can successfully link
to them.
In order for imports from GNU import libraries to mix properly with the
normal import chunks, the chunks from the existing mechanism needs to
be added into named sections like .idata$2.
These GNU import libraries consist of one header object, a number of
object files, one for each imported function/variable, and one trailer.
Within the import libraries, the object files are ordered alphabetically
in this order. The chunks stemming from these libraries have to be
grouped by what library they originate from and sorted, to make sure
the section chunks for headers and trailers for the lists are ordered
as intended. This is done on all sections named .idata$*, before adding
the synthesized chunks to them.
Differential Revision: https://reviews.llvm.org/D38513
llvm-svn: 342777
Summary:
As for x86_64, the default image base for AArch64 and i386 should be
aligned to a superpage appropriate for the architecture.
On AArch64, this is 2 MiB, on i386 it is 4 MiB.
Reviewers: emaste, grimar, javed.absar, espindola, ruiu, peter.smith, srhines, rprichard
Reviewed By: ruiu, peter.smith
Subscribers: jfb, markj, arichardson, krytarowski, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D50297
llvm-svn: 342746
Rui Ueyama