same as a normal i80 {low64, high16} rather
than its own {high64, low16}.  A depressing number
of places know about this; I think I got them all.
Bitcode readers and writers convert back to the old
form to avoid breaking compatibility.

llvm-svn: 67562

For inline asm output operand that matches an input. Encode the input operand index in the high bits.

llvm-svn: 67387

Fix some significant problems with constant pools that resulted in unnecessary paddings between constant pool entries, larger than necessary alignments (e.g. 8 byte alignment for .literal4 sections), and potentially other issues.

1. ConstantPoolSDNode alignment field is log2 value of the alignment requirement. This is not consistent with other SDNode variants.
2. MachineConstantPool alignment field is also a log2 value.
3. However, some places are creating ConstantPoolSDNode with alignment value rather than log2 values. This creates entries with artificially large alignments, e.g. 256 for SSE vector values.
4. Constant pool entry offsets are computed when they are created. However, asm printer group them by sections. That means the offsets are no longer valid. However, asm printer uses them to determine size of padding between entries.
5. Asm printer uses expensive data structure multimap to track constant pool entries by sections.
6. Asm printer iterate over SmallPtrSet when it's emitting constant pool entries. This is non-deterministic.


Solutions:
1. ConstantPoolSDNode alignment field is changed to keep non-log2 value.
2. MachineConstantPool alignment field is also changed to keep non-log2 value.
3. Functions that create ConstantPool nodes are passing in non-log2 alignments.
4. MachineConstantPoolEntry no longer keeps an offset field. It's replaced with an alignment field. Offsets are not computed when constant pool entries are created. They are computed on the fly in asm printer and JIT.
5. Asm printer uses cheaper data structure to group constant pool entries.
6. Asm printer compute entry offsets after grouping is done.
7. Change JIT code to compute entry offsets on the fly.

llvm-svn: 66875

llvm-svn: 66867

llvm-svn: 66866

llvm-svn: 66611

llvm-svn: 66607

llvm-svn: 66591

llvm-svn: 66589

llvm-svn: 66586

- Remove unused method.

llvm-svn: 66585

  the untimed version of getOrCreateSourceID. getOrCreateSourceID calls
  GetOrCreateSourceID, of course.

- Move some methods into the "private" section. Constify at least one method.

- General clean-ups.

llvm-svn: 66582

writing individually.

llvm-svn: 66577

emit exception and debug Dwarf info.

llvm-svn: 66571

format strings with the standard ${:foo} syntax.

llvm-svn: 66527

existed was for llvm-gcc 3.4 (which used the __main hack) which 
is really really long dead.

llvm-svn: 66417

whether a global is dead or not.  This should fix PR3749 - linker adds 
spurious use to appending globals.  I can't reasonably add a testcase
for this, because the bc writer/reader strip dead constant users.

llvm-svn: 66404

on the number of times a std::string is created and copied.

llvm-svn: 66396

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

It is possible that subprgoram definition is only encoding return value directly, instsad of an DIArray of all argument types. 

llvm-svn: 65643

Print variable's display name in dwarf DIE.

llvm-svn: 65468

Clean up dwarf writer, part 1. This eliminated the horrible recursive getGlobalVariablesUsing and replaced it something readable. It eliminated use of slow UniqueVector and replaced it with StringMap, SmallVector, and DenseMap, etc. It also fixed some non-deterministic behavior.

This is a very minor compile time win.

llvm-svn: 65438

them are generic changes.

- Use the "fast" flag that's already being passed into the asm printers instead
  of shoving it into the DwarfWriter.

- Instead of calling "MI->getParent()->getParent()" for every MI, set the
  machine function when calling "runOnMachineFunction" in the asm printers.

llvm-svn: 65379

This fixes objc.dg/dwarf-prototypes.m scan-assembler DW_AT_prototyped from llvmgcc42 test suite.

llvm-svn: 65357

If there is not any debug info available for any global variables and any subprograms then there is not any debug info to emit.

llvm-svn: 65352

Now we're using one gross, but quite robust hack :) (previous ones
did not work, for example, when ext_weak symbol was used deep inside
constant expression in the initializer).

The proper fix of this problem will require some quite huge asmprinter
changes and that's why was postponed. This fixes PR3629 by the way :)

llvm-svn: 65230

- Correct comment.
- Whitespace changes.

llvm-svn: 65149

llvm-svn: 65092

llvm-svn: 64920

The debugger sometimes lookup dynamically in the runtime to find ivar info of any Objective-C classes. It would be very helpful to debugger if the compiler encodes runtime version number in DWARF.

Add support for two additional DWARF attributes to encode Objective-C runtime version number.

llvm-svn: 64834

llvm-svn: 64815

llvm-svn: 64204

sure to print the value properly sext'd to the right pointer size.
This fixes PR3481.

llvm-svn: 63843

llvm-svn: 63663

llvm-svn: 63660

llvm-svn: 63527

 Each input file is encoded as a separate compile unit in LLVM debugging
information output. However, many target specific tool chains prefer to encode
only one compile unit in an object file. In this situation, the LLVM code
generator will include  debugging information entities in the compile unit 
that is marked as main compile unit. The code generator accepts maximum one main
compile unit per module. If a module does not contain any main compile unit 
then the code generator will emit multiple compile units in the output object 
file.

[Part 1]

Update DebugInfo APIs to accept optional boolean value while creating DICompileUnit  to mark the unit as "main" unit. By defaults all units are considered  non-main.  Update SourceLevelDebugging.html to document "main" compile unit.

Update DebugInfo APIs to not accept and encode separate source file/directory entries while creating various llvm.dbg.* entities. There was a recent, yet to be documented, change to include this additional information so no documentation changes are required here.

Update DwarfDebug to handle "main" compile unit. If "main" compile unit is seen then all DIEs are inserted into "main" compile unit. All other compile units are used to find source location for llvm.dbg.* values. If there is not any "main" compile unit then create unique compile unit DIEs for each llvm.dbg.compile_unit.

[Part 2]

Create separate llvm.dbg.compile_unit for each input file. Mark compile unit create for main_input_filename as "main" compile unit. Use appropriate compile unit, based on source location information collected from the tree node, while creating llvm.dbg.* values using DebugInfo APIs.

---

This is Part 1.

llvm-svn: 63400

Enable emitting of constant values in non-default address space as well. The APIs emitting constants now take an additional parameter signifying the address space in which to emit. The APIs like getData8BitsDirective() etc are made virtual enabling targets to be able to define appropirate directivers for various sizes and address spaces.

llvm-svn: 63377

llvm-svn: 63358

llvm-svn: 63357