llvm-svn: 99465

llvm-svn: 99463

        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

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

llvm-svn: 99445

llvm-svn: 99444

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

llvm-svn: 99434

llvm-svn: 99429

llvm-svn: 99428

llvm-svn: 99423

--- Reverse-merging r99400 into '.':
D    test/CodeGen/Generic/2010-03-24-liveintervalleak.ll
U    lib/CodeGen/LiveIntervalAnalysis.cpp

llvm-svn: 99419

llvm-svn: 99418

llvm-svn: 99416

NVCVTFrm will later be used to describe "vcvt with fractional bits".

llvm-svn: 99415

llvm-svn: 99414

raw_ostream variables immediately before they go out of scope.

llvm-svn: 99413

llvm-svn: 99410

N3VX instructions using special case code.

llvm-svn: 99409

llvm-svn: 99402

otherwise the SmallVector it contains doesn't free its memory.
In most cases LiveIntervalAnalysis could get away by not calling the destructor,
because VNInfos are bumpptr-allocated, and smallvectors usually don't grow.
However when the SmallVector does grow it always leaks.

This is the valgrind shown leak from the original testcase:
==8206== 18,304 bytes in 151 blocks are definitely lost in loss record 164 of 164
==8206==    at 0x4A079C7: operator new(unsigned long) (vg_replace_malloc.c:220)
==8206==    by 0x4DB7A7E: llvm::SmallVectorBase::grow_pod(unsigned long, unsigned long) (in /home/edwin/clam/git/builds/defaul
t/libclamav/.libs/libclamav.so.6.1.0)
==8206==    by 0x4F90382: llvm::VNInfo::addKill(llvm::SlotIndex) (in /home/edwin/clam/git/builds/default/libclamav/.libs/libcl
amav.so.6.1.0)
==8206==    by 0x5126B5C: llvm::LiveIntervals::handleVirtualRegisterDef(llvm::MachineBasicBlock*, llvm::ilist_iterator<llvm::M
achineInstr>, llvm::SlotIndex, llvm::MachineOperand&, unsigned int, llvm::LiveInterval&) (in /home/edwin/clam/git/builds/defau
lt/libclamav/.libs/libclamav.so.6.1.0)
==8206==    by 0x512725E: llvm::LiveIntervals::handleRegisterDef(llvm::MachineBasicBlock*, llvm::ilist_iterator<llvm::MachineI
nstr>, llvm::SlotIndex, llvm::MachineOperand&, unsigned int) (in /home/edwin/clam/git/builds/default/libclamav/.libs/libclamav
.so.6.1.0)
==8206==    by 0x51278A8: llvm::LiveIntervals::computeIntervals() (in /home/edwin/clam/git/builds/default/libclamav/.libs/libc
lamav.so.6.1.0)
==8206==    by 0x5127CB4: llvm::LiveIntervals::runOnMachineFunction(llvm::MachineFunction&) (in /home/edwin/clam/git/builds/de
fault/libclamav/.libs/libclamav.so.6.1.0)
==8206==    by 0x4DAE935: llvm::FPPassManager::runOnFunction(llvm::Function&) (in /home/edwin/clam/git/builds/default/libclama
v/.libs/libclamav.so.6.1.0)
==8206==    by 0x4DAEB10: llvm::FunctionPassManagerImpl::run(llvm::Function&) (in /home/edwin/clam/git/builds/default/libclama
v/.libs/libclamav.so.6.1.0)
==8206==    by 0x4DAED3D: llvm::FunctionPassManager::run(llvm::Function&) (in /home/edwin/clam/git/builds/default/libclamav/.l
ibs/libclamav.so.6.1.0)
==8206==    by 0x4D8BE8E: llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) (in /home/edwin/clam/git/builds/default/libclamav/.libs/libclamav.so.6.1.0)
==8206==    by 0x4D8CA72: llvm::JIT::getPointerToFunction(llvm::Function*) (in /home/edwin/clam/git/builds/default/libclamav/.libs/libclamav.so.6.1.0)

llvm-svn: 99400

I have audited all getOperandNo calls now, fixing
hidden assumptions. CallSite related uglyness will
be eliminated successively.

Note this patch has a long and griveous history,
for all the back-and-forths have a look at
CallSite.h's log.

llvm-svn: 99399

llvm-svn: 99398

llvm-svn: 99395

llvm-svn: 99394

llvm-svn: 99392

llvm-svn: 99380

llvm-svn: 99378

llvm-svn: 99376

and defining the add pattern with Pat<>, eliminating a use of
parallel.

llvm-svn: 99375

respectively, and add some more comment.

llvm-svn: 99373

llvm-svn: 99372

data it contains (similar to GetStringMapEntryFromValue).  
Patch by Greg Clayton!

llvm-svn: 99371

llvm-svn: 99370