of a VST instruction.

llvm-svn: 154544

llvm-svn: 154543

As per Jordy's review. Creating a symbol here is more flexible; however
I could not come up with an example where it was needed. (What
constrains can be added on of the symbol constrained to 0?)

llvm-svn: 154542

symbolic regions would help.

Thanks to Richard Smith.

llvm-svn: 154541

- FCOPYSIGN nodes that have operands of different types were not handled.
- Different code was generated depending on the endianness of the target.

Additionally, code is added that emits INS and EXT instructions, if they are
supported by target (they are R2 instructions).

llvm-svn: 154540

Objective-C class doesn't have a definition but
Clang tries to read through its protocols anyway.

llvm-svn: 154538

llvm-svn: 154535

first ivar in the list is a bitfield.
// rdar://11229770

llvm-svn: 154534

llvm-svn: 154533

llvm-svn: 154532

llvm-svn: 154531

right place to pick up parsing. In C++, this had a tendency to skip everything
declared within headers if the TU starts with garbage.

llvm-svn: 154530

llvm-svn: 154527

llvm-svn: 154526

llvm-svn: 154525

to get at the parameters (and their types) of a function or objc method cursor.

int clang_Cursor_getNumArguments(CXCursor C);
CXCursor clang_Cursor_getArgument(CXCursor C, unsigned i);

rdar://11201527

llvm-svn: 154523

llvm-svn: 154522

Per discussion with Howard, we are not interested in maintaining
compatibility with older versions of clang.

All tests pass with ToT clang, except for two which assert due to
a pre-existing, unrelated bug.

llvm-svn: 154521

Cleaned up the code and we now also dump the dynamic object for the malloc block. Using this on the lldb/test/lang/objc/foundation test we can see this in action:

First we can load the module:

(lldb) command script import /Volumes/work/gclayton/Documents/src/lldb/examples/darwin/heap_find/heap.py
Loading "/Volumes/work/gclayton/Documents/src/lldb/examples/darwin/heap_find/libheap.dylib"...ok
Image 0 loaded.
"heap_ptr_refs" and "heap_cstr_refs" commands have been installed, use the "--help" options on these commands for detailed help.


Lets take a look at the variable "my":

(lldb) fr var *my
(MyString) *my = {
  MyBase = {
    NSObject = {
      isa = MyString
    }
    propertyMovesThings = 0
  }
  str = 0x0000000100301a60
  date = 0x0000000100301e60
  _desc_pauses = NO
}


We can see that this contains an ivar "str" which has a pointer value of "0x0000000100301a60". Lets search the heap for this pointer and see what we find:

(lldb) heap_ptr_refs 0x0000000100301a60
found pointer 0x0000000100301a60: block = 0x103800270, size = 384, offset = 168, type = 'void *'
found pointer 0x0000000100301a60: block = 0x100301cf0, size = 48, offset = 16, type = 'MyString *', ivar = 'str' 
(MyString) *addr = {
  MyBase = {
    NSObject = {
      isa = MyString
    }
    propertyMovesThings = 0
  }
  str = 0x0000000100301a60
  date = 0x0000000100301e60
  _desc_pauses = NO
}
found pointer 0x0000000100301a60: block = 0x100820000, size = 4096, offset = 96, type = (autorelease object pool)
found pointer 0x0000000100301a60: block = 0x100820000, size = 4096, offset = 104, type = (autorelease object pool)


Note that it used dynamic type info to find that it was in "MyString" at offset 16 and it also found the ivar "str"!

We can also look for C string values on the heap. Lets look for "a.out":

(lldb) heap_cstr_refs "a.out"
found cstr a.out: block = 0x10010ce00, size = 96, offset = 85, type = '__NSCFString *'
found cstr a.out: block = 0x100112d90, size = 80, offset = 68, type = 'void *'
found cstr a.out: block = 0x100114490, size = 96, offset = 85, type = '__NSCFString *'
found cstr a.out: block = 0x100114530, size = 112, offset = 97, type = '__NSCFString *'
found cstr a.out: block = 0x100114e40, size = 32, offset = 17, type = '__NSCFString *'
found cstr a.out: block = 0x100114fa0, size = 32, offset = 17, type = '__NSCFString *'
found cstr a.out: block = 0x100300780, size = 160, offset = 128, type = '__NSCFData *'
found cstr a.out: block = 0x100301a60, size = 112, offset = 97, type = '__NSCFString *'
found cstr a.out: block = 0x100821000, size = 4096, offset = 100, type = 'void *'

We see we have some objective C classes that contain this, so lets "po" all of the results by adding the --po option:

(lldb)  heap_cstr_refs a.out --po
found cstr a.out: block = 0x10010ce00, size = 96, offset = 85, type = '__NSCFString *'
  (__NSCFString *) 0x10010ce00 /Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out

found cstr a.out: block = 0x100112d90, size = 80, offset = 68, type = 'void *'
found cstr a.out: block = 0x100114490, size = 96, offset = 85, type = '__NSCFString *'
  (__NSCFString *) 0x100114490 /Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out

found cstr a.out: block = 0x100114530, size = 112, offset = 97, type = '__NSCFString *'
  (__NSCFString *) 0x100114530 Hello from '/Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out'

found cstr a.out: block = 0x100114e40, size = 32, offset = 17, type = '__NSCFString *'
  (__NSCFString *) 0x100114e40 a.out.dSYM

found cstr a.out: block = 0x100114fa0, size = 32, offset = 17, type = '__NSCFString *'
  (__NSCFString *) 0x100114fa0 a.out

found cstr a.out: block = 0x100300780, size = 160, offset = 128, type = '__NSCFData *'
  (__NSCFData *) 0x100300780 <48656c6c 6f206672 6f6d2027 2f566f6c 756d6573 2f776f72 6b2f6763 6c617974 6f6e2f44 6f63756d 656e7473 2f737263 2f6c6c64 622f7465 73742f6c 616e672f 6f626a63 2f666f75 6e646174 696f6e2f 612e6f75 742700>

found cstr a.out: block = 0x100301a60, size = 112, offset = 97, type = '__NSCFString *'
  (__NSCFString *) 0x100301a60 Hello from '/Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out'

found cstr a.out: block = 0x100821000, size = 4096, offset = 100, type = 'void *'

llvm-svn: 154519

llvm-svn: 154518

correctly. clang diagnostics can provide fixits inside a macro argument now.

rdar://11014346

llvm-svn: 154517

llvm-svn: 154514

<stdatomic.h> header.

In passing, fix LanguageExtensions to note that C11 and C++11 are no longer
"upcoming standards" but are now actually standardized.

llvm-svn: 154513

While there is an encoding for it in VUZP, the result of that is undefined,
so we should avoid it. Define the instruction as a pseudo for VTRN.32
instead, as the ARM ARM indicates.

rdar://11222366

llvm-svn: 154511

The pruning is more complete if it is not done incrementally. The code
is also a tad less convluted.

llvm-svn: 154510

initialisation, do the right thing with regard to atomic initialisation.

Note: clang r154507 or later required for <atomic> to work now.
llvm-svn: 154508

llvm-svn: 154507

llvm-svn: 154506

While there is an encoding for it in VZIP, the result of that is undefined,
so we should avoid it. Define the instruction as a pseudo for VTRN.32
instead, as the ARM ARM indicates.

rdar://11221911

llvm-svn: 154505

Added a new "heap.py" module that adds a new command line command that can find values on the heap and print out the dynamic type of the malloc block that contains the data. I will be modifying this a bit more to tweak the output and make the output more useful.

llvm-svn: 154504

llvm-svn: 154503

llvm-svn: 154502

llvm-svn: 154501

Thanks to Pino Toscano for the patch

llvm-svn: 154500

llvm-svn: 154499

FoldingSet is implemented as a chained hash table. When there is a hash
collision during insertion, which is common as we fill the table until a
load factor of 2.0 is hit, we walk the chained elements, comparing every
operand with the new element's operands. This can be very expensive if the
MDNode has many operands.

We sacrifice a word of space in MDNode to cache the full hash value, reducing
compares on collision to a minimum. MDNode grows from 28 to 32 bytes + operands
on x86. On x86_64 the new bits fit nicely into existing padding, not growing
the struct at all.

The actual speedup depends a lot on the test case and is typically between
1% and 2% for C++ code with clang -c -O0 -g.

llvm-svn: 154497

llvm-svn: 154496

llvm-svn: 154495

llvm-svn: 154494

binary and assembly. Patch by Carlo Kok.  Emitting was inspired by but not based
on the D llvm bindings. 

llvm-svn: 154493