search for: bitcodereadervaluelist

...e problem? I am using CLANG/LLVM 2.8 compiled from source. The test program I am trying to compile is simply: int main() { return 0; } Thanks, Lorenzo De Carli Output for problem #1: $ clang -c -emit-llvm test.c -o test.bc $ llvm-dis test.bc llvm-dis: BitcodeReader.cpp:205: llvm::Value* llvm::BitcodeReaderValueList::getValueFwdRef(unsigned int, const llvm::Type*): Assertion `(Ty == 0 || Ty == V->getType()) && "Type mismatch in value table!"' failed. 0 llvm-dis 0x00000000006131c6 1 llvm-dis 0x0000000000613502 2 libc.so.6 0x00000039cf4302d0 3 libc.so.6 0x00000039cf430265 gsign...

...trying to compile is > simply: > > int main() > { > return 0; > } > > > Thanks, > Lorenzo De Carli > > Output for problem #1: > $ clang -c -emit-llvm test.c -o test.bc > $ llvm-dis test.bc > llvm-dis: BitcodeReader.cpp:205: llvm::Value* > llvm::BitcodeReaderValueList::getValueFwdRef(unsigned int, const > llvm::Type*): Assertion `(Ty == 0 || Ty == V->getType()) && "Type > mismatch in value table!"' failed. > 0 llvm-dis 0x00000000006131c6 > 1 llvm-dis 0x0000000000613502 > 2 libc.so.6 0x00000039cf4302d0 > 3 libc...

...60eb10 4 libc.so.6 0x000000332fa30265 gsignal + 53 5 libc.so.6 0x000000332fa31d10 abort + 272 6 libc.so.6 0x000000332fa296e6 __assert_fail + 246 7 llc 0x00000000014702df llvm::Value::replaceAllUsesWith(llvm::Value*) + 173 8 llc 0x00000000006b91e3 llvm::BitcodeReaderValueList::ResolveConstantForwardRefs() + 1127 9 llc 0x00000000006b9d97 llvm::BitcodeReader::ParseConstants() + 339 10 llc 0x00000000006bc634 llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 594 11 llc 0x00000000006c2d63 llvm::BitcodeReader::Materialize(llvm::Glo...

...53 >> 5 libc.so.6 0x000000332fa31d10 abort + 272 >> 6 libc.so.6 0x000000332fa296e6 __assert_fail + 246 >> 7 llc 0x00000000014702df >> llvm::Value::replaceAllUsesWith(llvm::Value*) + 173 >> 8 llc 0x00000000006b91e3 >> llvm::BitcodeReaderValueList::ResolveConstantForwardRefs() + 1127 >> 9 llc 0x00000000006b9d97 >> llvm::BitcodeReader::ParseConstants() + 339 >> 10 llc 0x00000000006bc634 >> llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 594 >> 11 llc 0x00000000006c2d...

...32 ratio of the two second best CPU times: pixxi:~ ggreif$ expr 854530000 / 85132 10037 It looks like we have a degradation of 0.3%. The <system> and <real> times show no surprises at all. There is one important change still missing from the use-diet branch, viz. the capacity of the BitcodeReaderValueList is computed very naively with the new algorithm at each push_back. I left this in to see whether the algorithm scales. Kimwitu++ bitcode-reading puts more than 250.000 Use objects into a contiguous array. To get its capacity my algoritm has to visit more than 18 pointers each time. Tonight I will...

...0000332fa30265 gsignal + 53 > 5 libc.so.6 0x000000332fa31d10 abort + 272 > 6 libc.so.6 0x000000332fa296e6 __assert_fail + 246 > 7 llc 0x00000000014702df > llvm::Value::replaceAllUsesWith(llvm::Value*) + 173 > 8 llc 0x00000000006b91e3 > llvm::BitcodeReaderValueList::ResolveConstantForwardRefs() + 1127 > 9 llc 0x00000000006b9d97 > llvm::BitcodeReader::ParseConstants() + 339 > 10 llc 0x00000000006bc634 > llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 594 > 11 llc 0x00000000006c2d63 > llvm::Bitcod...

...main() >> { >>   return 0; >> } >> >> >> Thanks, >> Lorenzo De Carli >> >> Output for problem #1: >> $ clang -c -emit-llvm test.c -o test.bc >> $ llvm-dis test.bc >> llvm-dis: BitcodeReader.cpp:205: llvm::Value* >> llvm::BitcodeReaderValueList::getValueFwdRef(unsigned int, const >> llvm::Type*): Assertion `(Ty == 0 || Ty == V->getType()) && "Type >> mismatch in value table!"' failed. >> 0   llvm-dis  0x00000000006131c6 >> 1   llvm-dis  0x0000000000613502 >> 2   libc.so.6 0x00000039cf...

On Apr 16, 2008, at 11:25 AM, Dan Gohman wrote: >> So, my idea is that these changes are performance neutral. I strongly agree with Dan that we need to measure performance to ensure there is no significant performance regression. >> I hope that this is interesting, but I'd like to ask anybody who is >> comfortable with performance testing to help provide some hard

....so.6 0x000000332fa31d10 abort + 272 >>> 6 libc.so.6 0x000000332fa296e6 __assert_fail + 246 >>> 7 llc 0x00000000014702df >>> llvm::Value::replaceAllUsesWith(llvm::Value*) + 173 >>> 8 llc 0x00000000006b91e3 >>> llvm::BitcodeReaderValueList::ResolveConstantForwardRefs() + 1127 >>> 9 llc 0x00000000006b9d97 >>> llvm::BitcodeReader::ParseConstants() + 339 >>> 10 llc 0x00000000006bc634 >>> llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 594 >>> 11 llc...

...e discussion on type resolution), not in the header. +++ lib/Bitcode/Reader/BitcodeReader.h (Arbeitskopie) + if (Idx >= size()) { + // Insert a bunch of null values. + resize(Idx * 2 + 1); + } strange indentation +++ lib/Bitcode/Reader/BitcodeReader.cpp (Arbeitskopie) +void BitcodeReaderValueList::resize(unsigned Desired) { + if (Desired > Capacity) + { Please put brace on same line as if. - Constant *C= ConstantExpr::getFCmp(FCmpInst::FCMP_OEQ, - const_cast<Constant*>(CP1->getOperand(i)), - const_cast<Constant*>(CP2->getOperand(i))...

Hi all, I have reported more than enough about the space savings achieved and the associated costs, here comes the current patch for review. Since this one is substantially smaller than the previous one, I did not cut it in pieces. The front part is about headers and the rest the .cpp and other files. Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>