'invoke' instruction. You will get a situation like this:

bb:
  %ehptr = eh.exception()
  %sel = eh.selector(%ehptr, @per, 0);

...

bb2:
  invoke _Unwind_Resume_or_Rethrow(%ehptr) %normal unwind to %lpad

lpad:
  ...

The unwinder will see the %sel call as a clean-up and, if it doesn't have a
catch further up the call stack, it will skip running it. But there *is* another
catch up the stack -- the catch for the %lpad. However, we can't see that. This
is fixed in code-gen, where we detect this situation, and convert the "clean-up"
selector call into a "catch-all" selector call. This gives us the correct
semantics.

llvm-svn: 99671

llvm-svn: 99656

llvm-svn: 99637

LiveVariables should clear kill / dead markers first. This allows us to remove a hack in the scheduler.

llvm-svn: 99597

Try trivial remat before the coalescer gives up on a vr / physreg coalescing for fear of tying up a physical register.

llvm-svn: 99575

llvm-svn: 99573

llvm-svn: 99544

the custom insertion hook deletes the instruction, then we try to set dead
flags on it.  Neither the code that I added nor the code that was there 
before was safe.

llvm-svn: 99538

llvm-svn: 99537

llvm-svn: 99507

Scheduler assumes SDDbgValue nodes are in source order. That's true currently. But add an assertion to verify it.

llvm-svn: 99501

bytes instead of one byte.  This is important because
we're running up to too many opcodes to fit in a byte
and it is aggrevated by FIRST_TARGET_MEMORY_OPCODE
making the numbering sparse.  This just bites the
bullet and bloats out the table.  In practice, this
increases the size of the x86 isel table from 74.5K
to 76K.  I think we'll cope :)

This fixes rdar://7791648

llvm-svn: 99494

llvm-svn: 99489

llvm-svn: 99487

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

r99453.

llvm-svn: 99482

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

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

llvm-svn: 99444

llvm-svn: 99429

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

llvm-svn: 99419

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

llvm-svn: 99378

llvm-svn: 99372

needed here.

llvm-svn: 99339

beyond just calling getTypeToTransformTo.

llvm-svn: 99335

llvm-svn: 99321

llvm-svn: 99319

llvm-svn: 99227

llvm-svn: 99225

DW_AT_stmt_list attribute attached with a compile unit encodes offset of line number information for this compile unit in debug_line section. This offset is always zero when only one compile unit is emitted in a object file. 

llvm-svn: 99223

llvm-svn: 99214

it allocates to DwarfDebug::DIEValues.

llvm-svn: 99196

llvm-svn: 99195

llvm-svn: 99113

disabled for several months (since svn r88806) and no one noticed.  My fix
for pr6543 yesterday reenabled it, but broke the ARM port's code for using
TBB/TBH.  Rather than adding a target hook to disable merging for Thumb2 only,
I'm just taking this out.  It is not common to have identical jump tables,
the code we used to merge them was O(N^2), and it only helps code size, not
performance.

llvm-svn: 98977

llvm-svn: 98920

llvm-svn: 98888