llvm-svn: 146534

DW_FORM_flag. Use DW_FORM_data1 for one byte.

llvm-svn: 146475

llvm-svn: 146409

generator to it. For non-bundle instructions, these behave exactly the same
as the MC layer API.

For properties like mayLoad / mayStore, look into the bundle and if any of the
bundled instructions has the property it would return true.
For properties like isPredicable, only return true if *all* of the bundled
instructions have the property.
For properties like canFoldAsLoad, isCompare, conservatively return false for
bundles.

llvm-svn: 146026

llvm-svn: 146001

This was actually a bit of a mess. TLI.setPrefLoopAlignment was clearly
documented as taking log2(bytes) units, but the x86 target would still
set a preferred loop alignment of '16'.

CodePlacementOpt passed this number on to the basic block, and
AsmPrinter interpreted it as bytes.

Now both MachineFunction and MachineBasicBlock use logarithmic
alignments.

Obviously, MachineConstantPool still measures alignments in bytes, so we
can emulate the thrill of using as.

llvm-svn: 145889

not get there any other way.

llvm-svn: 145789

Maybe some targets should use this as well.

Patch by Evgeniy Stepanov!

llvm-svn: 145781

change, now you need a TargetOptions object to create a TargetMachine. Clang
patch to follow.

One small functionality change in PTX. PTX had commented out the machine
verifier parts in their copy of printAndVerify. That now calls the version in
LLVMTargetMachine. Users of PTX who need verification disabled should rely on
not passing the command-line flag to enable it.

llvm-svn: 145714

llvm-svn: 145420

DISubrange supports unsigned lower/upper array bounds, so let's not fake it in the end while emitting DWARF. If a FE needs to encode signed lower/upper array bounds then we need to extend DISubrange or ad DISignedSubrange. 

llvm-svn: 144937

failure during bootstrap with it turned on.

llvm-svn: 144731

has a reference to it. Unfortunately, that doesn't work for codegen passes
since we don't get notified of MBB's being deleted (the original BB stays).

Use that fact to our advantage and after printing a function, check if
any of the IL BBs corresponds to a symbol that was not printed. This fixes
pr11202.

llvm-svn: 144674

instance and a concrete inlined instance are the use of DW_TAG_subprogram
instead of DW_TAG_inlined_subroutine and the who owns the tree.

We were also omitting DW_AT_inline from the abstract roots. To fix this,
make sure we mark abstract instance roots with DW_AT_inline even when
we have only out-of-line instances referring to them with DW_AT_abstract_origin.

FileCheck is not a very good tool for tests like this, maybe we should add
a -verify mode to llvm-dwarfdump.

llvm-svn: 144441

llvm-svn: 144360

addr DIE when adding to the dwarf accelerator tables.

llvm-svn: 144354

it first.

This is a more general fix to pr11300.

llvm-svn: 144324

as well.

llvm-svn: 144319

forward decls and have names into the dwarf accelerator types table.

llvm-svn: 144306

multiple dies per function and support C++ basenames.

llvm-svn: 144304

llvm-svn: 144194

llvm-svn: 144184

llvm-svn: 144172

llvm-svn: 144169

and is different than the normal name.

llvm-svn: 144130

llvm-svn: 144105

llvm-svn: 144099

llvm-svn: 144095

llvm-svn: 144027

llvm-svn: 144024

llvm-svn: 144023

llvm-svn: 143982

llvm-svn: 143974

Fixes a self-host error.

llvm-svn: 143970

llvm-svn: 143925

llvm-svn: 143924

to fix the types section (all types, not just global types), and testcases.

The code to do the final emission is disabled by default.

llvm-svn: 143923

the pubnames and pubtypes tables. LLDB can currently use this format
and a full spec is forthcoming and submission for standardization is planned.

A basic summary:

The dwarf accelerator tables are an indirect hash table optimized
for null lookup rather than access to known data. They are output into
an on-disk format that looks like this:

.-------------.
|  HEADER     |
|-------------|
|  BUCKETS    |
|-------------|
|  HASHES     |
|-------------|
|  OFFSETS    |
|-------------|
|  DATA       |
`-------------'

where the header contains a magic number, version, type of hash function,
the number of buckets, total number of hashes, and room for a special
struct of data and the length of that struct.

The buckets contain an index (e.g. 6) into the hashes array. The hashes
section contains all of the 32-bit hash values in contiguous memory, and
the offsets contain the offset into the data area for the particular
hash.

For a lookup example, we could hash a function name and take it modulo the
number of buckets giving us our bucket. From there we take the bucket value
as an index into the hashes table and look at each successive hash as long
as the hash value is still the same modulo result (bucket value) as earlier.
If we have a match we look at that same entry in the offsets table and
grab the offset in the data for our final match.

llvm-svn: 143921

llvm-svn: 143920

llvm-svn: 143919