| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
which was an expensive checks failure due to a bug in the checking. This
patch in essence reverts the original fix for PR3393, and refixes it by a
tweak to the way expensive checking is done.
llvm-svn: 89454
|
| |
|
|
| |
llvm-svn: 88946
|
| |
|
|
| |
llvm-svn: 86354
|
| |
|
|
| |
llvm-svn: 85853
|
| |
|
|
|
|
|
|
|
|
|
|
| |
to break up CFG diamonds by banishing one of the blocks to the end of
the function, which is bad for code density and branch size.
This does pessimize MultiSource/Benchmarks/Ptrdist/yacr2, the
benchmark cited as the reason for the change, however I've examined
the code and it looks more like a case of gaming a particular
branch than of being generally applicable.
llvm-svn: 84803
|
| |
|
|
| |
llvm-svn: 81545
|
| |
|
|
|
|
|
|
| |
input filename so that opt doesn't print the input filename in the
output so that grep lines in the tests don't unintentionally match
strings in the input filename.
llvm-svn: 81537
|
| |
|
|
| |
llvm-svn: 81293
|
| |
|
|
| |
llvm-svn: 81257
|
| |
|
|
|
|
| |
of using llvm-as, now that opt supports this.
llvm-svn: 81226
|
| |
|
|
| |
llvm-svn: 79992
|
| |
|
|
| |
llvm-svn: 79926
|
| |
|
|
|
|
|
|
|
| |
all Darwin targets; could be split into separate tests for
the chip subdirectories, but from Chris' last mail on testing
I assume he'd rather have only one test. Generic seems to be
the best available, maybe there should be a Darwin subdirectory?
llvm-svn: 79877
|
| |
|
|
| |
llvm-svn: 76920
|
| |
|
|
| |
llvm-svn: 75433
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer and floating-point opcodes, introducing
FAdd, FSub, and FMul.
For now, the AsmParser, BitcodeReader, and IRBuilder all preserve
backwards compatability, and the Core LLVM APIs preserve backwards
compatibility for IR producers. Most front-ends won't need to change
immediately.
This implements the first step of the plan outlined here:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt
llvm-svn: 72897
|