| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 129875
|
|
|
|
|
|
|
| |
delete the instruction pointed to by CGP's current instruction
iterator, leading to a crash on the testcase. This fixes PR9578.
llvm-svn: 129200
|
|
|
|
| |
llvm-svn: 128891
|
|
|
|
| |
llvm-svn: 126650
|
|
|
|
| |
llvm-svn: 126574
|
|
|
|
|
|
|
|
| |
The DAGCombiner created illegal BUILD_VECTOR operations.
The patch added a check that either illegal operations are
allowed or that the created operation is legal.
llvm-svn: 125435
|
|
|
|
|
|
| |
llvm.objectsize changes.
llvm-svn: 123771
|
|
|
|
|
|
| |
comes back some day.
llvm-svn: 122982
|
|
|
|
|
|
|
|
| |
In the bottom-up selection DAG scheduling, handle two-address
instructions that read/write unspillable registers. Treat
the entire chain of two-address nodes as a single live range.
llvm-svn: 122472
|
|
|
|
| |
llvm-svn: 122222
|
|
|
|
| |
llvm-svn: 122185
|
|
|
|
|
|
| |
but not complicated enough to merit another test.
llvm-svn: 119898
|
|
|
|
| |
llvm-svn: 118908
|
|
|
|
| |
llvm-svn: 118906
|
|
|
|
|
|
|
|
|
| |
sequence of loads and stores was being generated to perform the
copy on the x86 targets if the parameter was less than 4 byte
aligned, causing llc to use up vast amounts of memory and time.
Use a "rep movs" form instead. PR7170.
llvm-svn: 118260
|
|
|
|
|
|
|
|
| |
ConstantFoldBIT_CONVERTofBUILD_VECTOR calling itself
recursively and returning a SCALAR_TO_VECTOR node, but assuming the input was always a BUILD_VECTOR.
llvm-svn: 109519
|
|
|
|
|
|
|
|
|
| |
registers. Split out testcases per architecture and os
now.
Patch from Nelson Elhage.
llvm-svn: 107640
|
|
|
|
| |
llvm-svn: 106562
|
|
|
|
|
|
| |
matches what llvm-gcc and clang now produce.
llvm-svn: 106221
|
|
|
|
|
|
|
| |
The test should also likely have some FileCheck bits to validate the
output(?).
llvm-svn: 106146
|
|
|
|
|
|
| |
Please use the fast allocator instead.
llvm-svn: 106051
|
|
|
|
|
|
| |
Putkinen!
llvm-svn: 106038
|
|
|
|
|
|
|
|
|
|
| |
expansion is the same as that used by LegalizeDAG.
The resulting code sucks in terms of performance/codesize on x86-32 for a
64-bit operation; I haven't looked into whether different expansions might be
better in general.
llvm-svn: 105378
|
|
|
|
| |
llvm-svn: 103531
|
|
|
|
|
|
|
| |
and not the real problem itself, by dropping debug info for i128 values.
rdar://7958162.
llvm-svn: 103310
|
|
|
|
|
|
|
| |
Remove the -enable-eh option which is only used by the JIT,
and replace it with -jit-enable-eh.
llvm-svn: 102865
|
|
|
|
|
|
| |
even if the element of the array has no size.
llvm-svn: 101662
|
|
|
|
| |
llvm-svn: 99840
|
|
|
|
|
|
|
|
| |
--- 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: 99227
|
|
|
|
| |
llvm-svn: 98686
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to LLVM IR changes with addr label weirdness. In the testcase, we
generate references to the two bb's when codegen'ing the first
function:
_test1: ## @test1
leaq Ltmp0(%rip), %rax
..
leaq Ltmp1(%rip), %rax
Then continue to codegen the second function where the blocks
get merged. We're now smart enough to emit both labels, producing
this code:
_test_fun: ## @test_fun
## BB#0: ## %entry
Ltmp1: ## Block address taken
Ltmp0:
## BB#1: ## %ret
movl $-1, %eax
ret
Rejoice.
llvm-svn: 98595
|
|
|
|
|
|
|
|
|
| |
label is generated, but then the block is deleted. Since the
value is undefined, we just emit the label right after the entry
label of the function. It might matter that the label is in the
same section as the function was afterall.
llvm-svn: 98579
|
|
|
|
| |
llvm-svn: 98508
|
|
|
|
| |
llvm-svn: 97491
|
|
|
|
|
|
| |
llvm.dbg.stoppoint intrinsic anymore. There are tests to check new implementation, which attaches location information directly with an instruction using metadata.
llvm-svn: 97464
|
|
|
|
|
|
| |
Personality / FDE / LSDA / TType encoding depending on target / options (e.g. code model / relocation model) - MCIzation of Dwarf EH printer to use encoding information - Stub generation for ELF target (needed for indirect references) - Some other small changes here and there
llvm-svn: 96285
|
|
|
|
|
|
| |
and remove a few old and unreduced ones. Fixes PR5624.
llvm-svn: 95656
|
|
|
|
| |
llvm-svn: 95655
|
|
|
|
| |
llvm-svn: 95654
|
|
|
|
| |
llvm-svn: 95651
|
|
|
|
|
|
| |
it is dying due to fragility in the asmprinter .s comments.
llvm-svn: 94372
|
|
|
|
| |
llvm-svn: 94276
|
|
|
|
| |
llvm-svn: 94272
|
|
|
|
| |
llvm-svn: 92943
|
|
|
|
| |
llvm-svn: 92740
|
|
|
|
|
|
|
|
|
| |
the problem only shows for msp430 and pic16 which is why it specifies
them using -march. But it is wrong to put such tests in CodeGen/Generic,
since not everyone builds these targets. Put a copy of the test in each
of the target test directories.
llvm-svn: 90005
|
|
|
|
| |
llvm-svn: 89589
|
|
|
|
| |
llvm-svn: 89531
|