llvm-svn: 183454

Breaks linux build bots (I thought the problem was something else).

llvm-svn: 183447

Seems we emit the parameter ordering number (spuriously named 'arg
number') in the debug info, so there's no need to search through the
variable list to figure out the parameter ordering. This implementation
does 'always' do the work, even in non-optimized debug info (the
previous implementation checked the existence of the 'variables' list on
the subprogram which is only present in optimized builds).

No intended functionality change.

llvm-svn: 183446

Reapply 183270.

llvm-svn: 183445

Reapply 183269.

llvm-svn: 183441

llvm-svn: 183439

Reapply 183268.

llvm-svn: 183438

Reapply 183267.

llvm-svn: 183436

Add more InstRW mappings.

Reapply 183266.

llvm-svn: 183435

Reapply 183265.

llvm-svn: 183432

Reapply 183264.

llvm-svn: 183430

Reapply 183263.

llvm-svn: 183428

Reapply 183262.

llvm-svn: 183427

Reapply 183261.

llvm-svn: 183425

from the LC_DATA_IN_CODE load command.  And when disassembling print
the data in code formatted for the kind of data it and not disassemble those
bytes.

I added the format specific functionality to the derived class MachOObjectFile
since these tables only appears in Mach-O object files. This is my first
attempt to modify the libObject stuff so if folks have better suggestions
how to fit this in or suggestions on the implementation please let me know.

rdar://11791371

llvm-svn: 183424

Reapply of 183260.

llvm-svn: 183423

This reverts commit 183328. It caused pr16244 and broke the bots.

llvm-svn: 183422

Reapply of 183259.

llvm-svn: 183421

Spotted by Benjamin Kramer.

llvm-svn: 183413

llvm-svn: 183403

llvm-svn: 183385

FIXME: Is it false alarm?
llvm-svn: 183371

llvm-svn: 183370

llvm-svn: 183369

llvm-svn: 183365

llvm-svn: 183363

Caching it as a pointer allows us to reset it if the TargetMachine object
changes.

llvm-svn: 183361

llvm-svn: 183360

The TargetLoweringInfo object is owned by the TargetMachine. In the future, the
TargetMachine object may change, which may also change the TargetLoweringInfo
object.

llvm-svn: 183356

This hides the implementation. A future commit will remove the
error-prone getHex() and getBinary() methods.

llvm-svn: 183352

llvm-svn: 183351

And add a doxygen comment.

llvm-svn: 183350

llvm-svn: 183346

Previously, yaml2coff.cpp had a writeHexData static helper function to
do this, but it is generally useful functionality.

Also, validate hex strings up-front to avoid running having to handle
errors "deep inside" the yaml2obj code (it also gives better diagnostics
than it used to).

llvm-svn: 183345

Previously commited @183279 but tests were failing, reverted @183286
It was broken because @183336 was missing, now it's there.

llvm-svn: 183343

It allows regalloc pass to remove them by trivially assigning associated reg

llvm-svn: 183336

llvm-svn: 183334

llvm-svn: 183328

Add earlyclobber constaints to prevent input register being allocated as
the output register because, according to Intel spec [1], "If any pair
of the index, mask, or destination registers are the same, this
instruction results a UD fault."

---
[1] http://software.intel.com/sites/default/files/319433-014.pdf

llvm-svn: 183327

Reapply of 183258.

llvm-svn: 183321