from the assembler:

Error: unknown pseudo-op: `.debug_inlined'
llvm-svn: 68863

Keep track of inlined functions and their locations. This information is collected when nested llvm.dbg.func.start intrinsics are seen. (Right now, inliner removes nested llvm.dbg.func.start intrinisics during inlining.) 

Create debug_inlined dwarf section using these information. This info is used by gdb, at least on Darwin, to enable better experience debugging inlined functions. See DwarfWriter.cpp for more information on structure of debug_inlined section.

llvm-svn: 68847

Do not propagate ELF-specific stuff (data.rel) into other targets. This simplifies code and also ensures correctness.

llvm-svn: 68032

llvm-svn: 68031

llvm-svn: 68005

and extern_weak_odr.  These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global.  In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time.   This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function.  If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body.  The
code generators on the other hand map weak and weak_odr linkage
to the same thing.

llvm-svn: 66339

mergeable string section. I don't see any bad impact of such decision
(rather then placing it into mergeable const section, as it was before),
but at least Darwin linker won't complain anymore.

The problem in LLVM is that we don't have special type for string constants
(like gcc does). Even more, we have two separate types: ConstatArray for non-null
strings and ConstantAggregateZero for null stuff.... It's a bit weird :)

llvm-svn: 63142

doesn't support it. The default is set to 'true', so this should not
impact any other target backends.

llvm-svn: 63058

llvm-svn: 61765

squash warnings.

llvm-svn: 61707

Darwin doesn't. Make this optional for platforms.

llvm-svn: 61484

llvm-svn: 61420

about other platforms.

llvm-svn: 61415

Print a single parameter .file directive if we have an ELF target.

llvm-svn: 60480

adding a TargetMachine member to the base TargetAsmInfo class instead.

llvm-svn: 58624

instead of hasWeakLinkage in a bunch of optimization
passes.

llvm-svn: 56782

llvm-svn: 56621

llvm-svn: 56607

llvm-svn: 56585

llvm-svn: 56582

llvm-svn: 56580

llvm-svn: 56577

llvm-svn: 56575

llvm-svn: 56574

llvm-svn: 56573

objects in llvm.used (thanks Anton).  Makes visible
the magic 'l' prefix for symbols on Darwin which are
to be passed through the assembler, then removed at
linktime (previously all references to this had been
hidden in the ObjC FE code, oh well).

llvm-svn: 55973

llvm-svn: 54844

Move SLEB/ULEB size calculation routines from AsmPrinter to TargetAsmInfo. This makes JIT asmprinter-free.

llvm-svn: 54843

Reduce heap trashing due to std::string construction / concatenation via caching of section flags string representations

llvm-svn: 54842

llvm-svn: 54534

It's not legal to output a GV in a coalesced section if it's used in an ARM PIC relative constantpool.

llvm-svn: 54519

llvm-svn: 54451

llvm-svn: 54448

llvm-svn: 53920

llvm-svn: 53907

llvm-svn: 53639

llvm-svn: 53323

llvm-svn: 53320

llvm-svn: 53318

llvm-svn: 53312