| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 99695
|
| |
|
|
|
|
| |
converted, then use the initializer, since using the name itself won't work.
llvm-svn: 99692
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'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
|
| |
|
|
|
|
| |
remove a hack in the scheduler.
llvm-svn: 99597
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
RecyclingAllocator to allow client code to be simpler, and
simplify several clients.
llvm-svn: 98847
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
always create a new jump table. The intention was to avoid merging jump
tables in SelectionDAGBuilder, and to wait for the branch folding pass to
merge tables. Unfortunately, the same getJumpTableIndex() method is also
used to merge tables in branch folding, so as a result of this change
branch tables are never merged. Worse, the branch folding code is expecting
getJumpTableIndex to always return the index of an existing table, but with
this change, it never does so. In at least some cases, e.g., pr6543, this
creates references to non-existent tables.
I've fixed the problem by adding a new createJumpTableIndex function, which
will always create a new table, and I've changed getJumpTableIndex to only
look at existing tables.
llvm-svn: 98845
|
| |
|
|
| |
llvm-svn: 98838
|
| |
|
|
| |
llvm-svn: 98830
|
| |
|
|
|
|
| |
This reverts commit 98776. It broke the llvm-gcc boot strap.
llvm-svn: 98784
|
| |
|
|
| |
llvm-svn: 98778
|
| |
|
|
|
|
|
|
|
| |
Remove ugly hack that aborted the coalescer before using N^2 time.
This affects functions with very complicated live intervals for physical
registers, i.e. functions with thousands of function calls.
llvm-svn: 98776
|
| |
|
|
|
|
| |
so isEH is always false. This was hiding until now from compilers because of default arguments. This was hiding from dwarf debug info users because for most of the platform isAbsoluteEHSectionOffsets() is same as isAbsoluteDebugSectionOffsets(). But Chris found it while updating dwarf printer to use MC*.
llvm-svn: 98743
|