to MCRegisterInfo. Also initialize the mapping at construction time.

This patch eliminate TargetRegisterInfo from TargetAsmInfo. It's another step
towards fixing the layering violation.

llvm-svn: 135424

Rename createAsmInfo to createMCAsmInfo and move registration code to MCTargetDesc to prepare for next round of changes.

llvm-svn: 135219

TargetAsmInfo, which in turn pulls in TargetRegisterInfo, etc. :-( There are
other cases of violations, but this is probably the worst.

This patch is but one small step towards fixing this. 500 more steps to go. :-(

llvm-svn: 135131

llvm-svn: 134930

CPU, and feature string. Parsing some asm directives can change
subtarget state (e.g. .code 16) and it must be reflected in other
modules (e.g. MCCodeEmitter). That is, the MCSubtargetInfo instance
must be shared.

llvm-svn: 134795

- Each target asm parser now creates its own MCSubtatgetInfo (if needed).
- Changed AssemblerPredicate to take subtarget features which tablegen uses
  to generate asm matcher subtarget feature queries. e.g.
  "ModeThumb,FeatureThumb2" is translated to
  "(Bits & ModeThumb) != 0 && (Bits & FeatureThumb2) != 0".

llvm-svn: 134678

be the first encoded as the first feature. It then uses the CPU name to look up
features / scheduling itineray even though clients know full well the CPU name
being used to query these properties.

The fix is to just have the clients explictly pass the CPU name!

llvm-svn: 134127

llvm-svn: 134049

character in std::string was causing failures for a few ObjC and Obj-C++ tests
when -flto was enabled.  Revision 133999 resolved this issue. Thanks Jay!
rdar://9685235
PR10210

llvm-svn: 134017

avoid getting embedded trailing null bytes in std::strings.

llvm-svn: 133999

This was causing compile-time failures for some of the Objc and Obj-C++
benchmarks.  The specific errors were of the form: "ld: duplicate symbol …"
rdar://9660124

llvm-svn: 133955

llvm-svn: 133516

for all symbol differences and can drop the old EmitPCRelSymbolValue
method.

This also make getExprForFDESymbol on ELF equal to the one on MachO, and it
can be made non-virtual.

llvm-svn: 130634

llvm-svn: 129955

llvm-svn: 129902

'ar'. Have to figure out how to make libLTO even lazier.

llvm-svn: 127901

functions and initializers, just report the declarations present in
the module.

The motivation is to open the way for using the lazy module parsing,
which should speed up clients that just want a symbol list (nm, ar).

This is slightly less precise, but since both -strip-dead-prototypes
and -globaldce are part of the standard pipeline, this shouldn't
change the result for clang/dragonegg produced binaries.

Any decl in an IL file was also put there because a FE expected it
to be necessary, so this should not be a problem for "-O0 -emit-llvm".

As a sanity check, I have bootstrapped clang on linux and built
firefox on both linux and darwin. A clang bootstrap on darwin
with LTO fails with or without this patch because, ironically,
the linker doesn't like the combination of dead_strip and LTO
when building libLTO.so :-)

llvm-svn: 127870

llvm-svn: 127859

instead of copying.

llvm-svn: 127835

of an file.

llvm-svn: 127781

uses.

The result produced by the streamer is used to give the linker more accurate
information and to add to llvm.compiler.used. The second improvement removes
the need for the user to add __attribute__((used)) to functions only used in
inline asm. The first one lets us build firefox with LTO on Darwin :-)

llvm-svn: 126830

libxul links in 7m0.403s.

llvm-svn: 126085

llvm-svn: 125363

MemoryBuffer::getOpenFile to not close the file descriptor.

llvm-svn: 125128

complain about duplicated definitions.

llvm-svn: 124634

llvm-svn: 121958

llvm-svn: 121471

llvm-svn: 121461

f:
        .cfi_startproc
        nop
        .cfi_endproc

assembled (on ELF).

llvm-svn: 121434

llvm-svn: 121387

llvm-svn: 120304

llvm-svn: 116910

drastically reduce the linking time during LTO.

Patch by Shantonu Sen!

llvm-svn: 115728

"linker_private_weak_auto_def" linkage type for LTO.

llvm-svn: 114868

during LTO.

llvm-svn: 114850

from inline assembly, except in cases where they had already been seen (in which
case they would get added twice).
 - I can't see how this ever worked...

llvm-svn: 110757

llvm-svn: 110756

llvm-svn: 110752

llvm-svn: 110751

gold plugin.

llvm-svn: 110604