llvm-svn: 78047

llvm-svn: 77973

llvm-svn: 77960

llvm-svn: 77950

This is not just a matter of passing in the target triple from the module;
currently backends are making decisions based on the build and host
architecture. The goal is to migrate to making these decisions based off of the
triple (in conjunction with the feature string). Thus most clients pass in the
target triple, or the host triple if that is empty.

This has one important change in the way behavior of the JIT and llc.

For the JIT, it was previously selecting the Target based on the host
(naturally), but it was setting the target machine features based on the triple
from the module. Now it is setting the target machine features based on the
triple of the host.

For LLC, -march was previously only used to select the target, the target
machine features were initialized from the module's triple (which may have been
empty). Now the target triple is taken from the module, or the host's triple is
used if that is empty. Then the triple is adjusted to match -march.

The take away is that -march for llc is now used in conjunction with the host
triple to initialize the subtarget. If users want more deterministic behavior
from llc, they should use -mtriple, or set the triple in the input module.

llvm-svn: 77946

llvm-svn: 77835

llvm-svn: 77804

llvm-svn: 77787

llvm-svn: 77761

 - Uses MCAsmToken::getIdentifier which returns the (sub)string representing the
   meaningfull contents a string or identifier token.

 - Directives aren't done yet.

llvm-svn: 77739

metadata related, which I'm waiting on to avoid conflicting with Devang.

llvm-svn: 77721

llvm-svn: 77700

llvm-svn: 77689

llvm-svn: 77635

llvm-svn: 77633

llvm-svn: 77516

llvm-svn: 77494

llvm-svn: 77389

llvm-svn: 77385

llvm-svn: 77384

generic MCAsmParser interface.

llvm-svn: 77381

llvm-svn: 77362

llvm-svn: 77347

llvm-svn: 77341

llvm-svn: 77337

llvm-svn: 77328

llvm-svn: 77323

llvm-svn: 77322

dead before we used it.

llvm-svn: 77304

llvm-svn: 77292

llvm-svn: 77287

to match llvm-ld's default behavior.

llvm-svn: 77273

llvm-svn: 77272

llvm-svn: 77266

 - My DFS traversal of LLVM is, at least for now, nearly complete! :)

llvm-svn: 77258

 * Call InitializeAllTargets on every path where we might query the
   TargetRegistry. This fixes PR4604.
 * flush the formatted_raw_ostream& or else not all of the assembly will make
   it to the .s file. (It doesn't do this in its destructor?!)
 * Due to a reversed conditional, libLTO was reporting many symbols as both
   defined and undefined, including two definitions of the same symbol name
   in its symbol list.

llvm-svn: 77170

llvm-svn: 77152

classes, and migrate existing targets over.

llvm-svn: 77126

 - This is a simplified mechanism which just looks up a target based on the
   target triple, with a few additional flags.

 - Remove getClosestStaticTargetForModule, the moral equivalent is now:
     lookupTarget(Mod->getTargetTriple, true, false, ...);

 - This no longer does the fuzzy matching with target data (based on endianness
   and pointer width) that getClosestStaticTargetForModule was doing, but this
   was deemed unnecessary.

llvm-svn: 77111

llvm-svn: 77100