Remove custom handling for cmpsd/cmpss/cmppd/cmpps builtins. The builtins are now in IntrinsicsX86.td.

llvm-svn: 149235

Add GCCBuiltin declarations for cmpsd/cmpss/cmppd/cmpps to allow custom code to be removed from clang.

llvm-svn: 149234

Cleanup 3dnow builtin handling. Most of them were already handled by LLVM connecting intrinsics and builtins in IntrinsicsX86.td.

llvm-svn: 149233

Fix pattern for memory form of PSHUFD for use with FP vectors to remove bitcast to an integer vector that normal code wouldn't have. Also remove bitcasts from code that turns splat vector loads into a shuffle as it was making the broken pattern necessary.

llvm-svn: 149232

frames might go away (the object itself, not the actual logical frame) when
we are single stepping due to the way we currently sometimes end up flushing
frames when stepping in/out/over. They later will come back to life 
represented by another object yet they have the same StackID. Now when you get
a lldb::SBFrame object, it will track the frame it is initialized with until 
the thread goes away or the StackID no longer exists in the stack for the 
thread it was created on. It uses a weak_ptr to both the frame and thread and
also stores the StackID. These three items allow us to determine when the
stack frame object has gone away (the weak_ptr will be NULL) and allows us to
find the correct frame again. In our test suite we had such cases where we
were just getting lucky when something like this happened:

1 - stop at breakpoint
2 - get first frame in thread where we stopped
3 - run an expression that causes the program to JIT and run code
4 - run more expressions on the frame from step 2 which was very very luckily
    still around inside a shared pointer, yet, not part of the current 
    thread (a new stack frame object had appeared with the same stack ID and
    depth). 
    
We now avoid all such issues and properly keep up to date, or we start 
returning errors when the frame doesn't exist and always responds with
invalid answers.

Also fixed the UserSettingsController  (not going to rewrite this just yet)
so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to
track when the master controller has already gone away and this allowed me to
pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer 
needed.

llvm-svn: 149231

llvm-svn: 149230

llvm-svn: 149229

llvm-svn: 149228

each of the targets. Use this for module requirements, so that we can
pin the availability of certain modules to certain target features,
e.g., provide a module for xmmintrin.h only when SSE support is
available.

Use these feature names to provide a nearly-complete module map for
Clang's built-in headers. Only mm_alloc.h and unwind.h are missing,
and those two are fairly specialized at the moment. Finishes
<rdar://problem/10710060>.

llvm-svn: 149227

to be formed whenever ConstantVector::get is used.

llvm-svn: 149226

recently.  This also conveniently gets clang ready for a change about to
land in mainline.

llvm-svn: 149225

target-specific module requirements.

llvm-svn: 149224

like normal integers.

llvm-svn: 149223

llvm-svn: 149222

when the result type has a different # elements than the input vectors.

llvm-svn: 149221

llvm-svn: 149220

llvm-svn: 149219

all RTTI types, and since we don't use RTTI anymore since clang and llvm don't
we don't really need this header file. All shared pointer definitions have
been moved into "lldb-forward.h".

Defined std::tr1::weak_ptr definitions for all of the types that inherit from
enable_shared_from_this() in "lldb-forward.h" in preparation for thread
hardening our public API.

The first in the thread hardening check-ins. First we start with SBThread.
We have issues in our lldb::SB API right now where if you have one object
that is being used by two threads we have a race condition. Consider the
following code:

 1    int
 2    SBThread::SomeFunction()
 3    {
 4        int result = -1;
 5        if (m_opaque_sp)
 6        {
 7            result = m_opaque_sp->DoSomething();
 8        }
 9        return result;
10    }

And now this happens:

Thread 1 enters any SBThread function and checks its m_opaque_sp and is about
to execute the code on line 7 but hasn't yet
Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear()
and clears the contents of the shared pointer member
Thread 1 now crashes when it resumes.

The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a
lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this 
function would look like:

 1    int
 2    SBThread::SomeFunction()
 3    {
 4        int result = -1;
 5        ThreadSP thread_sp(m_opaque_wp.lock());
 6        if (thread_sp)
 7        {
 8            result = m_opaque_sp->DoSomething();
 9        }
10        return result;
11    }

Now we have a solid thread safe API where we get a local copy of our thread
shared pointer from our weak_ptr and then we are guaranteed it can't go away
during our function.

So lldb::SBThread has been thread hardened, more checkins to follow shortly.

llvm-svn: 149218

llvm-svn: 149217

Move some XOP patterns into instruction definition. Replae VPCMOV intrinsic patterns with custom lowering to a target specific nodes.

llvm-svn: 149216

should be feature complete now.  Lets see if it works.

llvm-svn: 149215

llvm-svn: 149214

llvm-svn: 149213

llvm-svn: 149212

a better doxyment group for convenience predicates.

llvm-svn: 149211

llvm-svn: 149210

llvm-svn: 149209

Temporary disable the -verify on this test in the hope of getting some useful output from the buildbots

llvm-svn: 149208

due to RTTI worries since llvm and clang don't use RTTI, but I was able to 
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared 
pointer from just a pointer, which is also easily solved using the 
std::tr1::enable_shared_from_this class. 

The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.

So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
pointers).

llvm-svn: 149207

headers. The remaining headers require more sophisticated
requirements; they'll be handled separately. Part of
<rdar://problem/10710060>.

llvm-svn: 149206

llvm-svn: 149205

llvm-svn: 149204

library, since it doesn't really have anything to do with Clang.

llvm-svn: 149203

llvm-svn: 149202

llvm-svn: 149201

results in libclang.

llvm-svn: 149200

  @import <complete with module names here>

or

  @import std.<complete with submodule names here>

Addresses <rdar://problem/10710117>.

llvm-svn: 149199

for getting the name of the module file, unifying the code for
searching for a module with a given name (into lookupModule()) and
separating out the mapping to a module file (into
getModuleFileName()). No functionality change.

llvm-svn: 149197

llvm-svn: 149196

llvm-svn: 149195