Add additional checking to ensure that MachineMemOperands are never set to null, which can happen in weird circumstances where target intrinsic hooks are implemented incorrectly.

llvm-svn: 144303

Added the ability to get a type without qualifiers (const, volatile, restrict, etc).

llvm-svn: 144302

More of rdar://9704684

llvm-svn: 144301

llvm-svn: 144300

require this tool to resolve (currently).

llvm-svn: 144299

llvm-svn: 144298

string to avoid possible later crashes.

Modified the locations that do set the crash description to NULL out the 
string when they are done doing their tasks.

llvm-svn: 144297

llvm-svn: 144296

Start of rdar://9704684

llvm-svn: 144293

consistency with other targets.

llvm-svn: 144292

llvm-svn: 144291

test/CodeGen/X86/lsr-loop-exit-cond.ll: Try to appease linux and freebsd bots to specify explicit -mtriple=x86_64-darwin.

I guess it expects -relocation-model=pic.

llvm-svn: 144290

llvm-svn: 144289

llvm-svn: 144288

llvm-svn: 144287

This does not work reliable and is probably not needed. I accidentally changed
this in this recent commit:

commit a0bcd63c6ffa81616cf8c6663a87588803f7d91c
Author: grosser <grosser@91177308-0d34-0410-b5e6-96231b3b80d8>
Date:   Thu Nov 10 12:47:21 2011 +0000

    ScopDetect: Use INVALID macro to fail in case of aliasing

    This simplifies the code and also makes the error message available to the
    graphviz scop viewer.

    git-svn-id: https://llvm.org/svn/llvm-project/polly/trunk@144284

llvm-svn: 144286

llvm-svn: 144285

This simplifies the code and also makes the error message available to
the graphviz scop viewer.

llvm-svn: 144284

llvm-svn: 144283

llvm-svn: 144282

llvm-svn: 144281

address is part of the access function. Also remove unused special cases that
were necessery when the base address was still contained in the access function

llvm-svn: 144280

llvm-svn: 144279

Previously we allowed in access functions only a single SCEVUnknown, which later
became the base address. We now use getPointerBase() to derive the base address
and all remaining unknowns are handled as parameters. This allows us to handle
cases like A[b+c];

llvm-svn: 144278

llvm-svn: 144277

need to provide a 'dominating IP' which is guaranteed to
dominate the (de)activation point but which cannot be avoided
along any execution path from the (de)activation point to
the push-point of the cleanup.  Using the entry block is
bad mojo.

llvm-svn: 144276

llvm-svn: 144275

llvm-svn: 144274

llvm-svn: 144273

llvm-svn: 144272

a previously-inactive cleanup, not only do we need a
flag variable, but we should also force the cleanup to
query the flag variable.  However, we only need to do
this when we're activating in a context that's
conditionally executed;  otherwise, we may safely
assume that the cleanup is dominated by the activation
point.

llvm-svn: 144271

defaulted or deleted.

llvm-svn: 144270

I've tested it on simple cases and it works.  Test cases to follow as well as a few tweaks.

llvm-svn: 144269

full-expression.  Naturally they're inactive before we enter
the block literal expression.  This restores the intended
behavior that blocks belong to their enclosing scope.

There's a useful -O0 / compile-time optimization that we're
missing here with activating cleanups following straight-line
code from their inactive beginnings.

llvm-svn: 144268

instruction lower optimization" in the pre-RA scheduler.

The optimization, rather the hack, was done before MI use-list was available.
Now we should be able to implement it in a better way, perhaps in the
two-address pass until a MI scheduler is available.

Now that the scheduler has to backtrack to handle call sequences. Adding
artificial scheduling constraints is just not safe. Furthermore, the hack
is not taking all the other scheduling decisions into consideration so it's just
as likely to pessimize code. So I view disabling this optimization goodness
regardless of PR11314.

llvm-svn: 144267

Note: These patterns only works in some cases because
many times the load sd node is bitcasted from a load
node of a different type.

llvm-svn: 144266

literal types, as well as derived-to-base casts for lvalues and
derived-to-virtual-base casts.

llvm-svn: 144265

llvm-svn: 144264

but it is sometimes useful to track blocks.  Do so.  Also
optimize the storage of these expressions.

llvm-svn: 144263

things out correctly again.

llvm-svn: 144261