This is same as r99772 (which was reverted) with just one meaningful difference where two source lines exchanged their positions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99816 91177308-0d34-0410-b5e6-96231b3b80d8
and those derived from them. These are obnoxious because
they were written as: PatLeaf<(bitconvert). Not having an
argument was foiling adding better type checking for operand
count matching up with what was required (in this case,
bitconvert always requires an operand!)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99759 91177308-0d34-0410-b5e6-96231b3b80d8
1, 1 cases which are by-far the most frequent. This shrinks the X86
isel table from 77014 -> 74657 bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99740 91177308-0d34-0410-b5e6-96231b3b80d8
'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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99671 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99538 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99494 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99485 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99469 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99453 91177308-0d34-0410-b5e6-96231b3b80d8
--- Reverse-merging r99400 into '.':
D test/CodeGen/Generic/2010-03-24-liveintervalleak.ll
U lib/CodeGen/LiveIntervalAnalysis.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99419 91177308-0d34-0410-b5e6-96231b3b80d8
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99400 91177308-0d34-0410-b5e6-96231b3b80d8
