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

Yea, 'NumCallerCallersAnalyzed' isn't a great name, suggestions welcome.

llvm-svn: 154492

Fix a dagcombine optimization which assumes that the vsetcc result type is always
of the same size as the compared values. This is ture for SSE/AVX/NEON but not
for all targets.

llvm-svn: 154490

llvm-svn: 154488

This reverts commit 97bd8d50881000c11b65b0e033996ec5f57bcd15.

llvm-svn: 154487

This reverts commit 2c6bdbf972ac966498489d30a33bfd252df9107d.

llvm-svn: 154486

llvm-svn: 154485

llvm-svn: 154484

Original message:
Modify the code that lowers shuffles to blends from using blendvXX to vblendXX.
blendV uses a register for the selection while Vblend uses an immediate.
On sandybridge they still have the same latency and execute on the same execution ports.

llvm-svn: 154483

dependent upon metadata ordering.

llvm-svn: 154482

an explicit instance variable.

rdar://10590352

llvm-svn: 154481

predicates.
Also remove NEON2 since it's not really useful and it is confusing. If
NEON + VFP4 implies NEON2 but NEON2 doesn't imply NEON + VFP4, what does it
really mean?

rdar://10139676

llvm-svn: 154480

llvm-svn: 154479

llvm-svn: 154478

llvm-svn: 154477

llvm-svn: 154476

emits but not clang.

llvm-svn: 154475