- Mar 25, 2010
-
-
Ted Kremenek authored
llvm-svn: 99479
-
John McCall authored
llvm-svn: 99477
-
Ted Kremenek authored
llvm-svn: 99476
-
Ted Kremenek authored
llvm-svn: 99475
-
Daniel Dunbar authored
llvm-svn: 99474
-
Daniel Dunbar authored
llvm-svn: 99473
-
Eric Christopher authored
Fariborz please review and make sure this is what you meant. llvm-svn: 99472
-
Zhongxing Xu authored
Instead of setting the ReturnExpr GDM to NULL, remove it. llvm-svn: 99470
-
Evan Cheng authored
Change how dbg_value sdnodes are converted into machine instructions. Their placement should be determined by the relative order of incoming llvm instructions. The scheduler will now use the SDNode ordering information to determine where to insert them. A dbg_value instruction is inserted after the instruction with the last highest source order and before the instruction with the next highest source order. It will optimize the placement by inserting right after the instruction that produces the value if they have consecutive order numbers. Here is a theoretical example that illustrates why the placement is important. tmp1 = store tmp1 -> x ... tmp2 = add ... ... call ... store tmp2 -> x Now mem2reg comes along: tmp1 = dbg_value (tmp1 -> x) ... tmp2 = add ... ... call ... dbg_value (tmp2 -> x) When the debugger examine the value of x after the add instruction but before the call, it should have the value of tmp1. Furthermore, for dbg_value's that reference constants, they should not be emitted at the beginning of the block (since they do not have "producers"). This patch also cleans up how SDISel manages DbgValue nodes. It allow a SDNode to be referenced by multiple SDDbgValue nodes. When a SDNode is deleted, it uses the information to find the SDDbgValues and invalidate them. They are not deleted until the corresponding SelectionDAG is destroyed. llvm-svn: 99469
-
Daniel Dunbar authored
llvm-svn: 99467
-
Daniel Dunbar authored
MC: Fix refacto in MCExpr evaluation, I mistakenly replaced a fragment address with a symbol address. - This fixes the integrated-as nightly test regressions. llvm-svn: 99466
-
Evan Cheng authored
llvm-svn: 99465
-
Eric Christopher authored
llvm-svn: 99463
-
Anders Carlsson authored
llvm-svn: 99462
-
Anders Carlsson authored
llvm-svn: 99461
-
Douglas Gregor authored
initialization code. Exposed a bug where we were not marking an implicit conversion as an lvalue when we were forming a call to a conversion function whose return type is a reference. llvm-svn: 99459
-
Evan Cheng authored
addl $12, %esp popl %esi popl %edi popl %ebx popl %ebp jmpl *__Block_deallocator-L1$pb(%esi) # TAILCALL The problem is the global base register is assigned GR32 register class. TCRETURNmi needs the registers making up the address mode to have the GR32_TC register class. The *proper* fix is for X86DAGToDAGISel::getGlobalBaseReg() to return a copy from the global base register of the machine function rather than returning the register itself. But that has the potential of causing it to be coalesced to a more restrictive register class: GR32_TC. It can introduce additional copies and spills. For something as important the PIC base, it's not worth it especially since this is not an issue on 64-bit. llvm-svn: 99455
-
Dan Gohman authored
llvm-svn: 99454
-
Chris Lattner authored
2006-07-19-stwbrx-crash.ll for me, but it's the only likely patch in the blame list of several bots. Lets see if this fixes it. llvm-svn: 99453
-
Douglas Gregor authored
CheckReferenceInit) over to the new initialization code (InitializationSequence), which is better-tested and doesn't require us to compute the entire conversion sequence twice. llvm-svn: 99452
-
Eric Christopher authored
llvm-svn: 99451
-
Bob Wilson authored
--- Reverse-merging r99440 into '.': U test/MC/AsmParser/X86/x86_32-bit_cat.s U test/MC/AsmParser/X86/x86_32-encoding.s U include/llvm/IntrinsicsX86.td U include/llvm/CodeGen/SelectionDAGNodes.h U lib/Target/X86/X86InstrSSE.td U lib/Target/X86/X86ISelLowering.h llvm-svn: 99450
-
Douglas Gregor authored
llvm-svn: 99448
-
Douglas Gregor authored
EmitReferenceBindingToExpr() rather than assuming we have an lvalue. This is just the lowest hanging fruit for PR6024, which still requires a bit of work. llvm-svn: 99447
-
Chris Lattner authored
llvm-svn: 99446
-
- Mar 24, 2010
-
-
Chris Lattner authored
llvm-svn: 99445
-
Chris Lattner authored
llvm-svn: 99444
-
Rafael Espindola authored
implicit methods on explicit template instantiation definitions. As a consequence, we should emit them at every use, even if we see a explicit template instantiation declaration. This is already the current behaviour, but it is good to test for that :-) llvm-svn: 99443
-
Ted Kremenek authored
llvm-svn: 99442
-
Ted Kremenek authored
llvm-svn: 99441
-
Kevin Enderby authored
llvm-svn: 99440
-
Jim Grosbach authored
Preliminary testing shows significant performance wins by not using these instructions. llvm-svn: 99436
-
Kevin Enderby authored
not get an "Unknown immediate size" assert failure when used. All instructions of this form have an 8-bit immediate. Also added a test case of an example instruction that is of this form. llvm-svn: 99435
-
Nate Begeman authored
llvm-svn: 99434
-
Douglas Gregor authored
make the vtable tester a little friendlier, with a clean target and without requiring . to be in your path llvm-svn: 99433
-
Devang Patel authored
llvm-svn: 99429
-
Johnny Chen authored
llvm-svn: 99428
-
Douglas Gregor authored
not pick apart a CXXTemporaryObjectExpr because such an object construction was explicitly written in the source code. Fixes PR6657. llvm-svn: 99427
-
Douglas Gregor authored
deserialize diagnostics. llvm-svn: 99426
-
Fariborz Jahanian authored
Class type to match gcc's. Fixes radar 7789113. llvm-svn: 99425
-