llvm-svn: 153672

llvm-svn: 153671

llvm-svn: 153670

llvm-svn: 153669

llvm-svn: 153667

LLVM intrinsics for.

I have an implementation of these functions, which wants to go in a libgcc_s
equivalent in compiler-rt.  It's currently here:

http://people.freebsd.org/~theraven/atomic.c

It will be committed to compiler-rt as soon as I work out where would be a
sensible place to put it...

llvm-svn: 153666

llvm-svn: 153665

llvm-svn: 153664

visibility directives for a variety of exported
meta-data symbols. // rdar://11144048

llvm-svn: 153663

llvm-svn: 153662

llvm-svn: 153661

llvm-svn: 153660

in the property debug info. Any more isn't necessary after all.

rdar://11144023

llvm-svn: 153659

llvm-svn: 153658

CodeGenPrepare sinks compare instructions down to their uses to prevent
live flags and predicate registers across basic blocks.

PRE of a compare instruction prevents that, forcing the i1 compare
result into a general purpose register.  That is usually more expensive
than the redundant compare PRE was trying to eliminate in the first
place.

llvm-svn: 153657

llvm-svn: 153648

- Link to several new bug reports that describe problems in more detail
- Add some more items
- Remove owners for inactive projects. This just blocks other people
- Rename 'middle part' to 'optimizer'

llvm-svn: 153647

llvm-svn: 153646

llvm-svn: 153645

llvm-svn: 153644

Replace assert(0) with llvm_unreachable to avoid warnings about dropping off the end of a non-void function in Release builds.

llvm-svn: 153643

  r152924, by $(LibDir). Because we assume polly built by autoconf is always
  in llvm tree.

llvm-svn: 153642

llvm-svn: 153641

    http://llvm.org/docs/SourceLevelDebugging.html#objcproperty

    including type and DECL. Expand the getter and setter names
    into the fully qualified names.

    rdar://11144023

llvm-svn: 153640

http://llvm.org/docs/SourceLevelDebugging.html#objcproperty

including type and DECL. Expand the metadata needed accordingly.

rdar://11144023

llvm-svn: 153639

Module-level ASM may contain definitions of functions and globals. However, we
were not telling the linker that these globals had definitions. As far as it was
concerned, they were just declarations.

Attempt to resolve this by inserting module-level ASM functions and globals into
the '_symbol' set so that the linker will know that they have values.

This gets us further towards our goal of compiling LLVM, but it still has
problems when linking libLTO.dylib because of the `-dead_strip' flag that's
passed to the linker.

<rdar://problem/11124216>

llvm-svn: 153638

llvm-svn: 153637

Only allow symbolic names for (v)cmpss/sd/ps/pd encodings 8-31 to be used with 'v' version of instructions.

llvm-svn: 153636

This is a code change to add support for changing instruction sequences of the form:

  load
  inc/dec of 8/16/32/64 bits
  store

into the appropriate X86 inc/dec through memory instruction:

  inc[qlwb] / dec[qlwb]

The checks that were in X86DAGToDAGISel::Select(SDNode *Node)>>ISD::STORE have been extracted to isLoadIncOrDecStore and reworked to use the better
named wrappers for getOperand(unsigned) (e.g. getOffset()) and replaced Chain.getNode() with LoadNode.  The comments have also been expanded.

llvm-svn: 153635

llvm-svn: 153634

with libunwind installed.
Patch by Jeffrey Yasskin!

llvm-svn: 153633

llvm-svn: 153632

llvm-svn: 153630

<rdar://problem/11051056>

Found a race condition when sending async packets in the ProcessGDBRemote.

A little background: GDB remote clients can only send one packet at a time. You must send a packet and wait for a response. So when we continue, we obviously can't hold up the calling thread waiting for the process to stop again, so we have an async thread in the ProcessGDBRemote whose only job is to run packets that control the inferior process. When you send a continue packet, the only packet you can send is an interrupt packet (which consists of sending a CTRL+C (or a '\x03' byte)). This then stops the inferior and we can send the async packet, and then resume the target. There was a race condition that often happened during stepping where we are doing a source level single step which consists of many instruction steps and a few runs here and there when we step into a function. So the flow looks like:

inst single step
inst single step
inst single step
inst single step
inst single step
step BP and run
inst single step
inst single step
inst single step

Now if we got an async packet while the program is running we get something like:

send --> continue
send --> interrupt
recv <-- interrupt stop reply packet
send --> async packet
recv <-- async response
send --> continue again and wait for actual stop

Problems arise when this was happening when single stepping a thread where we would get:

send --> step thread 123
send --> interrupt
send --> stop reply for thread 123 (from the step)

Now we _might_ have an extra stop reply packet from the "interrupt" which we weren't checking for and we could end up with:

send --> async packet (like memory read!)
recv <-- async response (which is the interrupt stop reply packet)

Now we have the read memroy reply sitting in our buffer and waiting to be used as the reply for the next packet... 

To further complicate things, the single step should have exited the async thread since the run control is finished, but now it will continue if it was interrupted.

The fixes I checked in to two major things:
- watch for the extra stop reply if we need to
- make sure we exit from the async thread run loop when the previous run control (like the instruction level single step) is finished.

Needless to say this makes very fast stepping in Xcode much more reliable.

llvm-svn: 153629

name as a direct initializer.

llvm-svn: 153628

Fixed an issue with stepping where the stack frame list could get changed out from underneath you when multiple threads start accessing frame info.

llvm-svn: 153627

When running this from the command line, don't pass the python script file itself to be disassembled.

llvm-svn: 153626

llvm-svn: 153625

Fixing an issue where Unicode characters in an NSString were printed as escape sequences by the summary provider shipping with LLDB - Added relevant test case code. Bonus points for identifying the source of the quotes :-)

llvm-svn: 153624

llvm-svn: 153623