Calling operator* on a WeakVH whose Value is null hits undefined
behaviour, since we bind the value to a reference. Instead, go through
`operator Value*` so that we work with the pointer itself.

Found by ubsan.

llvm-svn: 240214

llvm-svn: 240213

It caused different emission between stage2 and stage3. Investigating.

llvm-svn: 240212

llvm-svn: 240210

Seems like MSVC doesn't like this:

  InstrProf.h(49) : error C2614: 'llvm::InstrProfRecord' : illegal member initialization: 'Hash' is not a base or member

This reverts r240206.

llvm-svn: 240208

llvm-svn: 240207

This consolidates the logic to read instrprof records into the on disk
hash table's lookup trait and makes us copy the counter data instead
of taking references to it as we read. This will simplify further
changes to the format.

Patch by Betul Buyukkurt.

llvm-svn: 240206

llvm-svn: 240205

llvm-svn: 240203

Summary: This adds FindGlobalVariableNamed to ExecutionEngine
(plus implementation in MCJIT), which is an analog of
FindFunctionNamed for GlobalVariables.

Reviewers: lhames

Reviewed By: lhames

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10421

llvm-svn: 240202

When a case of INT64_MIN was followed by a case that was greater than
zero, we were overflowing a signed integer here. Since we've sorted
the cases here anyway (and thus currentValue must be greater than
nextValue) it's simple enough to avoid this by using addition rather
than subtraction.

Found by UBSAN on existing tests.

llvm-svn: 240201

NFC.

llvm-svn: 240198

llvm-svn: 240197

llvm-svn: 240193

This was suggested as part of D10460, but it's independent of
any functional change.

llvm-svn: 240192

Summary:
Since FunctionMap has llvm::Function pointers as keys, the order in
which the traversal happens can differ from run to run, causing spurious
FileCheck failures.  Have CallGraph::print sort the CallGraphNodes by
name before printing them.

Reviewers: bogner, chandlerc

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10575

llvm-svn: 240191

If LLVMDebugInfoPDB links against the DIA SDK then the exports file
would contain an INTERFACE_LINK_LIBRARIES property that contained an
absolute path to ``diaguids.lib`` which used a native windows path (interpreted
as escape sequences when LLVMExports.cmake is imported causing
``find_package(LLVM)`` to fail) rather than the correct CMake style path.

llvm-svn: 240181

This patch changes getRelocationAddend to use ErrorOr and considers it an error
to try to get the addend of a REL section.

If, for example, a x86_64 file has a REL section, that file is corrupted and
we should reject it.

Using ErrorOr is not ideal since we check the section type once per relocation
instead of once per section.

Checking once per section would involve getRelocationAddend just asserting and
callers checking the section before iterating over the relocations.

In any case, this is an improvement and includes a test.

llvm-svn: 240176

The ADDITIONAL_HEADER_DIRS command can be used to tell UIs that a given library
owns certain headers.  The path for MCParser was missing MC/ in it.

llvm-svn: 240175

This commit reports an error when the MIR parser can't find
a basic block with the machine basic block's name.

llvm-svn: 240174

llvm-svn: 240165

This starts preparing the class to become a (more) general
LoopVersioning utility class.

llvm-svn: 240164

llvm-svn: 240160

llvm-svn: 240151

There are 3 types of relocations on MachO
* Scattered
* Section based
* Symbol based

On ELF and COFF relocations are symbol based.

We were in the strange situation that we abstracted over two of them. This makes
section based relocations MachO only.

llvm-svn: 240149

This commit implements the initial serialization of machine basic blocks in a
machine function. Only the simple, scalar MBB attributes are serialized. The 
reference to LLVM IR's basic block is preserved when that basic block has a name.

Reviewers: Duncan P. N. Exon Smith

Differential Revision: http://reviews.llvm.org/D10465

llvm-svn: 240145

Differential Revision: http://reviews.llvm.org/D10531

llvm-svn: 240144

llvm-svn: 240143

Default member initializers are permitted since r236244.

llvm-svn: 240142

llvm-svn: 240141

Use POSIX.1-2003 Technical Corrigendum 1 suggested workaround.

llvm-svn: 240140

The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
  -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
  llvm/lib/


Thanks to Eugene Kosov for the original patch!

llvm-svn: 240137

Sorry, I have no idea how grep failed to find this.

llvm-svn: 240133

This matches the current
http://www.sco.com/developers/gabi/latest/ch4.eheader.html#machine

llvm-svn: 240132

This patch adds initial support for the -fsanitize=kernel-address flag to Clang.
Right now it's quite restricted: only out-of-line instrumentation is supported, globals are not instrumented, some GCC kasan flags are not supported.
Using this patch I am able to build and boot the KASan tree with LLVMLinux patches from github.com/ramosian-glider/kasan/tree/kasan_llvmlinux.
To disable KASan instrumentation for a certain function attribute((no_sanitize("kernel-address"))) can be used.

llvm-svn: 240131

What this does is make all symbols that would otherwise start with a .L
(or L on MachO) unnamed.

Some of these symbols still show up in the symbol table, but we can just
make them unnamed.

In order to make sure we produce identical results when going thought assembly,
all .L (not just the compiler produced ones), are now unnamed.

Running llc on llvm-as.opt.bc, the peak memory usage goes from 208.24MB to
205.57MB.

llvm-svn: 240130

This was forgotten in r240113. Thanks Eric for paying attention.

llvm-svn: 240124

Summary:
Finally, delete LLVM's parse_arguments() definition.
Second part of D10531.

This is dependent on http://reviews.llvm.org/D10529

Reviewers: pcc, beanz, chapuni

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10531

llvm-svn: 240122

Summary:
Use CMake's cmake_parse_arguments() instead.
It's called in a slightly different way, but supports all our use cases.
It's in CMake 2.8.8, which is our minimum supported version.

CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc):
http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments

Reviewers: pcc, beanz, chapuni

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10531

llvm-svn: 240121

Currently, we canonicalize shuffles that produce a result larger than
their operands with:
  shuffle(concat(v1, undef), concat(v2, undef))
->
  shuffle(concat(v1, v2), undef)

because we can access quad vectors (see PerformVECTOR_SHUFFLECombine).

This is useful in the general case, but there are special cases where
native shuffles produce larger results: the two-result ops.

We can look through the concat when lowering them:
  shuffle(concat(v1, v2), undef)
->
  concat(VZIP(v1, v2):0, :1)

This lets us generate the native shuffles instead of scalarizing to
dozens of VMOVs.

Differential Revision: http://reviews.llvm.org/D10424

llvm-svn: 240118