In ELF (as in MachO), not all relocations point to symbols. Represent this
properly by using a symbol_iterator instead of a SymbolRef. Update llvm-readobj
ELF's dumper to handle relocatios without symbols.

llvm-svn: 183284

LLVM_YAML_STRONG_TYPEDEF() is the correct macro to perform this function.

llvm-svn: 183280

llvm-svn: 183279

llvm-svn: 183278

llvm-svn: 183275

llvm-svn: 183273

llvm-svn: 183271

llvm-svn: 183270

llvm-svn: 183269

llvm-svn: 183268

llvm-svn: 183267

Add more InstRW mappings.

llvm-svn: 183266

llvm-svn: 183265

llvm-svn: 183264

llvm-svn: 183263

llvm-svn: 183262

llvm-svn: 183261

llvm-svn: 183260

llvm-svn: 183259

llvm-svn: 183258

Add some generic SchedWrites and assign resources for Swift and Cortex A9.

llvm-svn: 183257

An instruction with less than 3 inputs is trivially a fast immediate shift.

llvm-svn: 183256

Don't output data if we are supposed to ignore the record.

llvm-svn: 183255

llvm-svn: 183248

llvm-svn: 183243

IndVarSimplify is willing to move divide instructions outside of their
loop bodies if they are invariant of the loop.  However, it may not be
safe to expand them if we do not know if they can trap.

Instead, check to see if it is not safe to expand the instruction and
skip the expansion.

This fixes PR16041.

Testcase by Rafael Ávila de Espíndola.

llvm-svn: 183239

The ARM backend did not expect LDRBi12 to hold a constant pool operand.
Allow for LLVM to deal with the instruction similar to how it deals with
LDRi12.

This fixes PR16215.

llvm-svn: 183238

Specifying the load address for Darwin i386 dylibs was a performance
optimization for dyld that is not relevant for x86_64 or arm. We can just
remove this now.

llvm-svn: 183230

llvm-svn: 183229

llvm-svn: 183228

The problem this time seems to be a thinko. We were assuming that in the CFG

A
| \
|  B
| /
C

speculating the basic block B would cause only the phi value for the B->C edge
to be speculated. That is not true, the phi's are semantically in the edges, so
if the A->B->C path is taken, any code needed for A->C is not executed and we
have to consider it too when deciding to speculate B.

llvm-svn: 183226

llvm-svn: 183219

GCC complains about casting away const.

llvm-svn: 183216

Test commit for user vmedic, to verify commit access. One line of comment is added to MipsAsmParser.cpp.

llvm-svn: 183215

[llvm-symbolizer] Avoid calling slow getSymbolSize for Mach-O files. Assume that symbols with zero size are in fact large enough.

llvm-svn: 183213

llvm-svn: 183210

Specifically the following work was done:

1. If the operation was not implemented, I implemented it.

2. If the operation was already implemented, I just moved its location
in the APFloat header into the IEEE-754R 5.7.2 section. If the name was
incorrect, I put in a comment giving the true IEEE-754R name.

Also unittests have been added for all of the functions which did not
already have a unittest.

llvm-svn: 183179

llvm-svn: 183176

llvm-svn: 183175

(4.58s vs 3.2s on an oldish Mac Tower). 

  The corresponding src is excerpted bellow. The lopp accounts for about 90% of execution time.
  --------------------
    cat -n test-suite/MultiSource/Benchmarks/Olden/em3d/make_graph.c
     90 
     91         for (k=0; k<j; k++)
     92           if (other_node == cur_node->to_nodes[k]) break;

  The defective layout is sketched bellow, where the two branches need to swap.
  ------------------------------------------------------------------------
      L:
         ...
      if (cond) goto out-of-loop
      goto L

  While this code sequence is defective, I don't understand why it incurs 1/3 of 
execution time. CPU-event-profiling indicates the poor laoyout dose not increase
in br-misprediction; it dosen't increase stall cycle at all, and it dosen't 
prevent the CPU detect the loop (i.e. Loop-Stream-Detector seems to be working fine
as well)... 

   The root cause of the problem is that the layout pass calls AnalyzeBranch() 
with basic-block which is not updated to reflect its current layout.

rdar://13966341

llvm-svn: 183174