g++.dg/abi/key2.C

llvm-svn: 51458

Reading .bc files from before that change will no longer work.

llvm-svn: 51457

exclude struct and array types.

llvm-svn: 51456

X86CodeEmitter should not set PIC style to None at initialization time. This will break codegen if relocation model is changed to PIC_ later.

llvm-svn: 51455

llvm-svn: 51454

llvm-svn: 51453

exclude struct and array types.

llvm-svn: 51452

Also added a FIXME related to how we represent @properties in the ObjCInterfaceDecl AST.

llvm-svn: 51450

llvm-svn: 51449

and supported in the grammar, in the lexer.

llvm-svn: 51448

llvm::Type::isSingleValueType. Currently these two functions have
the same behavior, but soon isFirstClassType will return true for
struct and array types.

Clang may some day want to use of isFirstClassType for some of
these some day as an optimization, but it'll require some
consideration.

llvm-svn: 51446

llvm-svn: 51441

When rewriting defs and uses after spilling, don't set the weight of a
live interval to infinity if the instruction being rewritten is an
original remat def instruction.  We were only checking against the clone
of the remat def which doesn't actually appear in the IR at all.

llvm-svn: 51440

Don't attempt to update SpillSlotToUsesMap for stack slots that aren't
generated by the spiller.

llvm-svn: 51439

llvm-svn: 51436

llvm-svn: 51435

tracked object to "escape": it's reference count might be incremented by the
called function, thus causing an object's lifetime to extend beyond when the
local reference count is decremented to 0.

This addresses: <rdar://problem/5933215>

llvm-svn: 51433

Don't use ostringstream (pulling in <sstream>) when creating the dead store diagnostic (simply not needed).

llvm-svn: 51432

llvm-svn: 51431

Suppress warnings about missing placement delete. This should now be std-conformant even if compiled with exceptions on.

llvm-svn: 51429

void f(const void) in one place and rejecting it in another.

llvm-svn: 51424

Rewrite operand loops to use iterators. This shrinks .o file (at gcc4.0.1 -O3 x86) substantially (>500 bytes). Reason still unknown.

llvm-svn: 51423

llvm-svn: 51422

get inline asm working as well as it did previously with the CBE
with the new MRV support for inline asm.

llvm-svn: 51420

with normal outputs.  Testcase here: 
test/CodeGen/X86/asm-indirect-mem.ll

llvm-svn: 51409

llvm-svn: 51408

llvm-svn: 51407

more aggressive, and more correct.  Verify that we only attempt to
promote loads and stores.

llvm-svn: 51406

llvm-svn: 51405

actually work (instead of crashing llc), and there's enough info emitted 
to get line number information in gdb. This should hopefully be helpful 
for debugging non-working programs.

I got rid of the begin/endregion calls because the implementation wasn't 
working; someone who knows the debugging info a bit better might try to 
add it. I really have no clue how a compiler is supposed to emit them.

This commit shouldn't have any effect without -g.

llvm-svn: 51404

ret.

llvm-svn: 51403

bit that wants to use CurFuncDecl as a FunctionDecl.

llvm-svn: 51402

llvm-svn: 51399

lib/CodeGen/CGExpr.cpp and to change include/clang/AST/Attr.h to
use its own enum for visibility types instead of using
llvm::GlobalValue::VisibilityTypes. These changes eliminate
dependencies in the AST library on LLVM's VMCore library.

llvm-svn: 51398

that currently uses Type::isFirstClassType and depends on it
returning false for struct or array types.

This commit doesn't change the behavior of Type::isFirstClassType.

llvm-svn: 51396

llvm-svn: 51395

BB1:                                                                                                                                                  
  vr1025 = copy vr1024                                                                                                                                
  ..                                                                                                                                                  
BB2:                                                                                                                                                  
  vr1024 = op                                                                                                                                         
         = op vr1025                                                                                                                                     
  <loop eventually branch back to BB1>

Even though vr1025 is copied from vr1024, it's not safe to coalesced them since live range of vr1025 intersects the def of vr1024. This happens when vr1025 is assigned the value of the previous iteration of vr1024 in the loop.

llvm-svn: 51394

they aren't in the header file, systems with a <string> header file that isn't
64-bit clean shouldn't warn if #including Path.h and specifying
-Wshorten-64-to-32.

llvm-svn: 51393

llvm-svn: 51392

llvm-svn: 51391