handles dead implicit results more aggressively.  More
to come, I think this is now just a data entry problem.

llvm-svn: 99486

happening.

Enhance scheduling to set the DEAD flag on implicit defs
more aggressively.  Before, we'd set an implicit def operand
to dead if it were present in the SDNode corresponding to
the machineinstr but had no use.  Now we do it in this case
AND if the implicit def does not exist in the SDNode at all.

This exposes a couple of problems: one is the FIXME, which
causes a live intervals crash on CodeGen/X86/sibcall.ll.
The second is that it makes machinecse and licm more 
aggressive (which is a good thing) but also exposes a case
where licm hoists a set0 and then it doesn't get resunk.

Talking to codegen folks about both these issues, but I need
this patch in in the meantime.

llvm-svn: 99485

llvm-svn: 99484

instead of InlineFunction.

llvm-svn: 99483

r99453.

llvm-svn: 99482

buildbot.  The tramp3d test fails.
--- Reverse-merging r99477 into '.':
U    test/SemaTemplate/friend-template.cpp
U    test/CXX/temp/temp.decls/temp.friend/p1.cpp
U    lib/Sema/SemaTemplateInstantiateDecl.cpp
U    lib/Sema/SemaAccess.cpp

llvm-svn: 99481

(1) Do not assume the data arguments start after the format string
(2) Do not use the fact that a function is variadic to treat it like a va_list printf function

Fixes PR 6697.

llvm-svn: 99480

llvm-svn: 99479

llvm-svn: 99477

llvm-svn: 99476

llvm-svn: 99475

llvm-svn: 99474

llvm-svn: 99473

Fariborz please review and make sure this is what you meant.

llvm-svn: 99472

Instead of setting the ReturnExpr GDM to NULL, remove it.

llvm-svn: 99470

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

llvm-svn: 99467

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

llvm-svn: 99465

llvm-svn: 99463

llvm-svn: 99462

llvm-svn: 99461

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

        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

llvm-svn: 99454

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

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

llvm-svn: 99451

--- 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

llvm-svn: 99448

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

llvm-svn: 99446

llvm-svn: 99445

llvm-svn: 99444

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

llvm-svn: 99442

llvm-svn: 99441

llvm-svn: 99440

Preliminary testing shows significant performance wins by not using these
instructions.

llvm-svn: 99436

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