Changes

[LLDB] [lldb-server] Use llvm::InitLLVM for doing unicode conversion of
arguments for windows
This should allow lldb-server to operate on files with non-ascii 
pathnames.
I tried looking around in lldb/tools, and this seemed like the only 
other tool (other than the main lldb driver itself) that would be used
(implicitly) by an end user (which could be working in non-ascii paths).
Differential Revision: https://reviews.llvm.org/D68864
llvm-svn: 374537

[FileCheck] Implement --ignore-case option.
The FileCheck utility is enhanced to support a `--ignore-case` option.
This is useful in cases where the output of Unix tools differs in case
(e.g. case not specified by Posix).
Reviewers: Bigcheese, jakehehrlich, rupprecht, espindola, alexshap,
jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D68146
llvm-svn: 374538

Dead Virtual Function Elimination
Currently, it is hard for the compiler to remove unused C++ virtual 
functions, because they are all referenced from vtables, which are
referenced by constructors. This means that if the constructor is called
from any live code, then we keep every virtual function in the final
link, even if there are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and 
regular compilation in limited circumstances) by using type metadata to
match virtual function call sites to the vtable slots they might load
from. This information can then be used in the global dead code
elimination pass instead of the references from vtables to virtual
functions, to more accurately determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation
to always load virtual function pointers using the
llvm.type.checked.load intrinsic, instead of regular load instructions.
I originally tried writing this using clang's existing code-generation,
which uses the llvm.type.test and llvm.assume intrinsics after doing a
normal load. However, it is possible for optimisations to obscure the
relationship between the GEP, load and llvm.type.test, causing GlobalDCE
to fail to find virtual function call sites.
The existing linkage and visibility types don't accurately describe the
scope in which a virtual call could be made which uses a given vtable.
This is wider than the visibility of the type itself, because a virtual
function call could be made using a more-visible base class. I've added
a new
!vcall_visibility metadata type to represent this, described in 
TypeMetadata.rst. The internalization pass and libLTO have been updated
to change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every
call to llvm.type.checked.load in the linkage unit. It might be possible
to extend this optimisation to be able to use the ThinLTO summary, as
was done for devirtualization, but until then that combination is
rejected in the clang driver.
To test this, I've written a fuzzer which generates random C++ programs
with complex class inheritance graphs, and virtual functions called
through object and function pointers of different types. The programs
are spread across multiple translation units and DSOs to test the
different visibility restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't 
ideal, because only classes in anonymous namespaces can be optimised
with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do
not work correctly with -fvisibility=hidden. However, there are only 12
test failures when building with -fvisibility=hidden (and an unmodified
compiler), and this change does not cause any new failures for either
value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size 
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are
reductions of ~14% in 450.soplex and 483.xalancbmk, and there are no
code size increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M,
which show a geomean size reduction of ~3%, again with no size
increases.
I had hoped that this would have no effect on performance, which would
allow it to awlays be enabled (when using -fwhole-program-vtables).
However, the changes in clang to use the llvm.type.checked.load
intrinsic are causing ~1% performance regression in the C++ parts of
SPEC2006. It should be possible to recover some of this perf loss by
teaching optimisations about the llvm.type.checked.load intrinsic, which
would make it worth turning this on by default (though it's still
dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 374539