llvm-svn: 149269

This is to prevent diagnostic when using NSLocalizedString or CFCopyLocalizedString
macros which are usually used in place of NS and CF strings literals.

llvm-svn: 149268

This has shown better results for 2mm, 3mm and a couple of other benchmarks.

After this we show consistenly better results as PoCC with maxfuse. We need
to see if PoCC can also give better results with another fusion strategy.

llvm-svn: 149267

maximise_band_depth does not seem to have any effect for now, but it may help to
increase the amount of tileable loops. We expose the flag to be able to analyze
its effects when looking into individual benchmarks.

llvm-svn: 149266

llvm-svn: 149265

After this we can now compile all polybench 2.0 kernels without any compiler
crash.

llvm-svn: 149264

This speeds up the scheduler by orders of magnitude and in addition yields often
to a better schedule.

With this we can compile all polybench kernels with less than 5x compile time
overhead. In general the overhead is even less than 2-3x.  This is still with
running a lot of redundant passes and no compile time tuning at all. There are
several obvious areas where we can improve here further.

There are also two test cases where we cannot find a schedule any more (cholesky
and another). I will look into them later on.

With this we have a very solid base line from which we can start to optimize
further.

llvm-svn: 149263

This allows us to set the fusion strategy and to gist-simplify union_maps.

llvm-svn: 149262

llvm-svn: 149261

sbvalue.value (<SBValue>)
sbvalue.variable (<SBValue>)

Initialize both with a lldb.SBValue

sbvalue.value() make all sorts of convenience properties. Type "help(sbvalue.value)" 
in the embedded python interpreter to see what is available.

sbvalue.variable() wraps a lldb.SBValue and allows you to play with your variable just
as you would expect:

pt = sbvalue.variable (lldb.frame.FindVariable("pt"))

print pt.x
print py.y

argv = sbvalue.variable (lldb.frame.FindVariable("argv"))
print argv[0]

Member access and array acccess is all taken care of!

llvm-svn: 149260

*function*. Wrap the function in #ifndef NDEBUG.

llvm-svn: 149259

llvm-svn: 149258

llvm-svn: 149257

mangling of floating-point literals.  I just went ahead and
reimplemented toString() here;  if someone wants to generalize
the library routine to do this, or feels strongly that we should
be post-processing, please feel free.

llvm-svn: 149256

llvm-svn: 149255

llvm-svn: 149254

llvm-svn: 149253

Add a descriptive name for a constant.  Also I'm at least temporarily waging war on throw specs, both old and new style.  Except where we have already publicly exposed the throw spec, I'm getting rid of them.  They may come back later.  But they seem somewhat prone to cyclic dependencies here.  The throw spec implies compiler generated code that this library has to jump to during stack unwinding.  I'd like to minimize the possiblity that the code used to properly make that jump is itself creating such jumps.

llvm-svn: 149251

llvm-svn: 149250

Put throw() clauses back on these functions in cxxabi.h.  This header must be C++03 compatible and these throw specs are consistent with the current cxxabi.h that Apple ships.

llvm-svn: 149249

llvm-svn: 149248

llvm-svn: 149247

llvm-svn: 149245

'-target'. The original flag was part of a flag group that marked it as
driver-only. The new flag didn't ever get equivalent treatment. This
caused the '-target' flag to get passed down to any raw GCC invocation.
Marking it as a driver option fixes this and PR11875.

llvm-svn: 149244

Fix compilation of ASan tests on OS X Lion (see http://code.google.com/p/address-sanitizer/issues/detail?id=32)
The redzones emitted by AddressSanitizer for CFString instances confuse the linker and are of little use, so we shouldn't add them. 

llvm-svn: 149243

llvm-svn: 149242

llvm-svn: 149241

llvm-svn: 149240

llvm-svn: 149239

contain shared pointers to the lldb_private::Target and lldb_private::Process
objects respectively as we won't want the target or process just going away.

Also cleaned up the lldb::SBModule to remove dangerous pointer accessors.

For any code the public API files, we should always be grabbing shared 
pointers to any objects for the current class, and any other classes prior
to running code with them.

llvm-svn: 149238

llvm-svn: 149237

- Remove the printf0 special handling as we treat it as printf anyway.
- Perform basic checks (non-literal, empty) for all formats and not only printf/scanf.

llvm-svn: 149236

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