strict weak ordering, and don't pass possibly-null pointers to dyn_cast.

llvm-svn: 162314

int64_t, Symbol64TableEntry is actually only stored with 4-byte alignment
within the file.

The usage of #pragma pack here is copied from the corresponding code in
Support/Endian.h, so shouldn't introduce any new portability problems.

llvm-svn: 162312

no cost to using memcpy here: the fixed code is optimized by LLVM to perfect
machine code.

llvm-svn: 162311

llvm-svn: 162310

llvm-svn: 162309

llvm-svn: 162306

According to http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
it's suggested that compile_commands.json in the root of the LLVM source tree
should be a symlink to the json file produced by your build system of choice.

So here's a patch so it doesn't turn up in git status, etc.

llvm-svn: 162305

Thanks to Duncan Sands for catching this random file in code review.

llvm-svn: 162304

Even looking at the revision history I couldn't quite piece together why this
cast was ever written in the first place, but I assume it was because of some
change in the inheritance, perhaps this function was reimplemented in a
derived type & this caller was meant to get the base version (& it wasn't
virtual)?

llvm-svn: 162301

llvm-svn: 162300

on a patch by Andy/PaX. I added the support for dot and dollar.

llvm-svn: 162298

this is the index of the operand that failed to match.

Note: This may cause a buildbot failure due to an API mismatch in clang.  Should
recover with my next commit to clang.

llvm-svn: 162295

llvm-svn: 162292

consistent with the other "expected identifier" errors.
Extracted from the Andy/PaX patch. I added the test.

llvm-svn: 162291

suggested by David Blaikie.

llvm-svn: 162286

PR9673

llvm-svn: 162284

llvm-svn: 162283

llvm-svn: 162282

llvm-svn: 162281

The MCJIT doesn't need or want a TargetJITInfo. That's vestigal from the old
JIT, so just remove it.

rdar://12119347

llvm-svn: 162280

number of bits was bigger than 32.  I checked every use of this function
that I could find and it looks like the maximum number of bits is 32, so I've
added an assertion checking this property, and a type cast to (hopefully) stop
PVS-Studio from warning about this in the future.

llvm-svn: 162277

llvm-svn: 162276

This optimization is really just replacing allocas wholesale with
globals, there is no scalarization.

The underlying motivation for this patch is to simplify the SROA pass
and focus it on splitting and promoting allocas.

llvm-svn: 162271

llvm-svn: 162270

[asan] add code to detect global initialization fiasco in C/C++. The sub-pass is off by default for now. Patch by Reid Watson. Note: this patch changes the interface between LLVM and compiler-rt parts of asan. The corresponding patch to compiler-rt will follow.

llvm-svn: 162268

llvm-svn: 162267

llvm-svn: 162264

llvm-svn: 162263

Replace a break with llvm_unreachable in the default case of a nested switch. Condense code a bit. No functional change.

llvm-svn: 162261

llvm-svn: 162260

llvm-svn: 162257

llvm-svn: 162256

*** Bad machine code: Explicit definition marked as use ***
- function:    test_cos
- basic block: BB#0 L.entry (0x7ff2a2024fd0)
- instruction: VSETLNi32 %D11, %D11<undef>, %R0, 0, pred:14, pred:%noreg, %Q5<imp-use,kill>, %Q5<imp-def>
- operand 0:   %D11

llvm-svn: 162247

The getSumForBlock function was quadratic in the number of successors
because getSuccWeight would perform a linear search for an already known
iterator.

This patch was originally committed as r161460, but reverted again
because of assertion failures. Now that duplicate Machine CFG edges have
been eliminated, this works properly.

llvm-svn: 162233

IR that hasn't been through SimplifyCFG can look like this:

  br i1 %b, label %r, label %r

Make sure we don't create duplicate Machine CFG edges in this case.

Fix the machine code verifier to accept conditional branches with a
single CFG edge.

llvm-svn: 162230

LLVM IR has labeled duplicate CFG edges, but since Machine CFG edges
don't have labels, it doesn't make sense to allow duplicates. There is
no way of telling what the edges mean.

Duplicate CFG edges cause confusion when dealing with edge weights. It
seems that code producing duplicate CFG edges usually does the wrong
thing with edge weights.

llvm-svn: 162227

This pass often has weird CFG hacks and hand-written MI building code
that can go wrong in many ways.

llvm-svn: 162224

Verify that the predecessor and successor lists are consistent and free
of duplicates.

llvm-svn: 162223

The test case ARM/2011-05-04-MultipleLandingPadSuccs.ll was creating
duplicate successor list entries.

llvm-svn: 162222

This patch allows us to use cmake to specify a cross compiler: target different
than host. In particular, it moves LLVM_DEFAULT_TARGET_TRIPLE and TARGET_TRIPLE
variables from cmake/config-ix.cmake to the toplevel CMakeLists.txt to make them
available at configure time.

Here is the command line that I have used to test my patches to create a Hexagon
cross compiler hosted on x86:

$ cmake -G Ninja -D LLVM_TARGETS_TO_BUILD:STRING=Hexagon -D TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_DEFAULT_TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_TARGET_ARCH:STRING=hexagon-unknown-linux-gnu ..
$ ninja check

llvm-svn: 162219