From reid at x10sys.com Mon Dec 6 00:16:08 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 00:16:08 -0600 Subject: [llvm-commits] CVS: llvm-test/MultiSource/Benchmarks/Prolangs-C/bison/output.c Message-ID: <200412060616.AAA30689@zion.cs.uiuc.edu> Changes in directory llvm-test/MultiSource/Benchmarks/Prolangs-C/bison: output.c updated: 1.1 -> 1.2 --- Log message: Eliminate a fatal SIGSEGV if the input file hasn't been opened. This clears up an optimization problem when compiled with GCC 3.4.0 -O2 and avoids a nightly test failure. --- Diffs of the changes: (+2 -1) Index: llvm-test/MultiSource/Benchmarks/Prolangs-C/bison/output.c diff -u llvm-test/MultiSource/Benchmarks/Prolangs-C/bison/output.c:1.1 llvm-test/MultiSource/Benchmarks/Prolangs-C/bison/output.c:1.2 --- llvm-test/MultiSource/Benchmarks/Prolangs-C/bison/output.c:1.1 Tue Oct 5 13:31:50 2004 +++ llvm-test/MultiSource/Benchmarks/Prolangs-C/bison/output.c Mon Dec 6 00:15:58 2004 @@ -1226,7 +1226,8 @@ fpars = fparser; else fpars = fparser1; #endif - + if (!fpars || feof(fpars)) + return; c = getc(fpars); while (c != EOF) { From gaeke at cs.uiuc.edu Mon Dec 6 01:02:05 2004 From: gaeke at cs.uiuc.edu (Brian Gaeke) Date: Mon, 6 Dec 2004 01:02:05 -0600 (CST) Subject: [llvm-commits] CVS: reopt/lib/LightWtProfiling/SecondTrigger.cpp Message-ID: <200412060702.BAA25606@kain.cs.uiuc.edu> Changes in directory reopt/lib/LightWtProfiling: SecondTrigger.cpp updated: 1.37 -> 1.38 --- Log message: Add comment describing firstTriggerAddr map. --- Diffs of the changes: (+3 -0) Index: reopt/lib/LightWtProfiling/SecondTrigger.cpp diff -u reopt/lib/LightWtProfiling/SecondTrigger.cpp:1.37 reopt/lib/LightWtProfiling/SecondTrigger.cpp:1.38 --- reopt/lib/LightWtProfiling/SecondTrigger.cpp:1.37 Tue Nov 9 15:40:55 2004 +++ reopt/lib/LightWtProfiling/SecondTrigger.cpp Mon Dec 6 01:01:55 2004 @@ -50,6 +50,9 @@ // pair counts the number of times a given trace is *not* selected: static std::map > backOffCounters; +// Maps the return addresses of llvm_first_trigger calls to the +// target of the branch that follows the call. This is sort of like the FLIMap +// in TraceToFunction. std::map firstTriggerAddr; static Statistic FoundTraces ("reopt", "Number of traces found"); From gaeke at cs.uiuc.edu Mon Dec 6 01:54:51 2004 From: gaeke at cs.uiuc.edu (Brian Gaeke) Date: Mon, 6 Dec 2004 01:54:51 -0600 (CST) Subject: [llvm-commits] CVS: reopt/lib/LightWtProfiling/SecondTrigger.cpp Message-ID: <200412060754.BAA17894@kain.cs.uiuc.edu> Changes in directory reopt/lib/LightWtProfiling: SecondTrigger.cpp updated: 1.38 -> 1.39 --- Log message: Remove whitespace. --- Diffs of the changes: (+0 -1) Index: reopt/lib/LightWtProfiling/SecondTrigger.cpp diff -u reopt/lib/LightWtProfiling/SecondTrigger.cpp:1.38 reopt/lib/LightWtProfiling/SecondTrigger.cpp:1.39 --- reopt/lib/LightWtProfiling/SecondTrigger.cpp:1.38 Mon Dec 6 01:01:55 2004 +++ reopt/lib/LightWtProfiling/SecondTrigger.cpp Mon Dec 6 01:54:40 2004 @@ -49,7 +49,6 @@ // of times a given trace is selected, and the second element of the // pair counts the number of times a given trace is *not* selected: static std::map > backOffCounters; - // Maps the return addresses of llvm_first_trigger calls to the // target of the branch that follows the call. This is sort of like the FLIMap // in TraceToFunction. From gaeke at cs.uiuc.edu Mon Dec 6 01:56:25 2004 From: gaeke at cs.uiuc.edu (Brian Gaeke) Date: Mon, 6 Dec 2004 01:56:25 -0600 (CST) Subject: [llvm-commits] CVS: reopt/lib/LightWtProfiling/SLI.cpp Message-ID: <200412060756.BAA17905@kain.cs.uiuc.edu> Changes in directory reopt/lib/LightWtProfiling: SLI.cpp updated: 1.23 -> 1.24 --- Log message: Add more comments, and a couple of very slight refactorings... no functional changes. --- Diffs of the changes: (+59 -30) Index: reopt/lib/LightWtProfiling/SLI.cpp diff -u reopt/lib/LightWtProfiling/SLI.cpp:1.23 reopt/lib/LightWtProfiling/SLI.cpp:1.24 --- reopt/lib/LightWtProfiling/SLI.cpp:1.23 Thu Sep 23 14:48:34 2004 +++ reopt/lib/LightWtProfiling/SLI.cpp Mon Dec 6 01:56:14 2004 @@ -282,31 +282,43 @@ std::map branchStub; std::map toInline; + // index should always be equal to the size of the trace. int index = 0; std::vector trace; - //generate a vector of instructions - trace.push_back(initial_code[0]); + + // Start generating a vector of binary instruction words. + trace.push_back(initial_code[0]); // Start with %g1 = 1. index += 1; //assume: succ[0] is 0, succ[1] is 1 for(std::vector::iterator VBI = vBB.begin(), VBE = vBB.end(); - VBI != VBE; ++VBI){//loop on vBB + VBI != VBE; ++VBI){ + // We're looping over the basic blocks in the trace, copying their + // machine code into the trace vector. First get the start and end + // addresses of the basic block's machine code: std::pair bbInst = getBasicBlockInfo(*VBI); uint64_t bbStart = bbInst.first; uint64_t bbEnd = bbInst.second; - if(exitBBs.find(*VBI) != exitBBs.end()){ //is an exit BB - bbPlacement[*VBI] = index; - trace.push_back(call_code[2]); - trace.push_back(exit_code[0]); - trace.push_back(exit_code[1]); - trace.push_back(call_code[3]); - trace.push_back(BRANCH_ALWAYS); - trace.push_back(NOP); - branchMap[index + 4] = bbStart; + + // Keep track of where we're going to emit this block's machine code + // into the SLI trace: + bbPlacement[*VBI] = index; + + if(exitBBs.find(*VBI) != exitBBs.end()){ + // This basic block is a trace-exiting BB. We don't trace it; rather, we + // emit a call to llvm_time_end() to account for the trace exit, and then + // we emit a branch to the original version of this BB (at bbStart). + trace.push_back(call_code[2]); // save %o7 to stack + trace.push_back(exit_code[0]); // call llvm_time_end callMap[index+1] = (uint64_t)(intptr_t)(&llvm_time_end); + trace.push_back(exit_code[1]); // nop + trace.push_back(call_code[3]); // restore %o7 from stack + trace.push_back(BRANCH_ALWAYS); // ba bbStart + branchMap[index + 4] = bbStart; + trace.push_back(NOP); // nop index += 6; - } else{ //This is not an exit BB - bbPlacement[*VBI] = index; + } else{ + // This is a regular, non-trace-exiting BB. bool isCondBranch = false; int fillLater = 0; bool isSucc0 = false; @@ -326,53 +338,69 @@ for(uint64_t addr = bbStart; addr <= bbEnd; addr+=4){//loop on BB unsigned instr = vm->readInstrFrmVm(addr, tr, tr2); + // We're looping over the instructions in the BB, possibly modifying + // them as we go along, and copying them into the trace. instr is + // the current instruction. if(isIndirectCall(instr)){ - trace.push_back(call_code[0]); - trace.push_back(instr); + trace.push_back(call_code[0]); // save %g1 to stack + trace.push_back(instr); // do the indirect call trace.push_back(vm->readInstrFrmVm(addr+4, tr, tr2)); - trace.push_back(call_code[1]); + // copy delay-slot instr. + trace.push_back(call_code[1]); // restore %g1 from stack index += 4; addr += 4; } else if(isCallInstr(instr)){ uint64_t callTarget = getCallTarget(instr, addr); if(callTarget != (uint64_t)(intptr_t)&llvm_first_trigger){ + // This is a real call, not FLI instrumentation... if(isInlinable(getRevFunction(M, callTarget))){ - trace.push_back(instr); - trace.push_back(vm->readInstrFrmVm(addr+4, tr, tr2)); + trace.push_back(instr); // do the call callMap[index] = getCallTarget(instr, addr); + trace.push_back(vm->readInstrFrmVm(addr+4, tr, tr2)); + // copy delay-slot instr. + // Remember that we're going to inline this call. toInline[callTarget] = 1; index += 2; } else { - trace.push_back(call_code[0]); - trace.push_back(instr); - trace.push_back(vm->readInstrFrmVm(addr+4, tr, tr2)); - trace.push_back(call_code[1]); + trace.push_back(call_code[0]); // save %g1 to stack + trace.push_back(instr); // do the call callMap[index+1] = getCallTarget(instr, addr); + trace.push_back(vm->readInstrFrmVm(addr+4, tr, tr2)); + // copy delay-slot instr. + trace.push_back(call_code[1]); // restore %g1 from stack index += 4; } addr += 4; - } else{ - trace.push_back(call_code[2]); //save o7 - trace.push_back(loop_top_code[0]); - trace.push_back(loop_top_code[1]); - trace.push_back(call_code[3]); //restore o7 + } else { + // Calls to llvm_first_trigger are replaced with + // calls to countPath. + trace.push_back(call_code[2]); // save %o7 on stack + trace.push_back(loop_top_code[0]); // call countPath callMap[index+1] = (uint64_t)(intptr_t)&countPath; + trace.push_back(loop_top_code[1]); // nop + trace.push_back(call_code[3]); // restore %o7 from stack index += 4; } - } else if(isBranchInstr(instr)){//is branch + } else if(isBranchInstr(instr)){ + // Handle branch always and conditional branches. assert(!isBranchNever(instr) && "Branch never not handled!"); if(isBranchAlways(instr)){ uint64_t target = getBranchTarget(instr, addr); trace.push_back(instr); trace.push_back(vm->readInstrFrmVm(addr+4, tr, tr2)); if(target == brTarget){ + // Branch to beginning of the loop - replace it with a branch to + // the beginning of the SLI trace. trace[index] = getBranchInst(instr, (uint64_t)(intptr_t)&trace[0], (uint64_t)(intptr_t)&trace[index]); } else{ + // Branch to somewhere else - put it in our "stub" list for + // a fixup, below. BasicBlock *targetBB=NULL; - bool found = getReverseBBMap(getBranchTarget(instr, addr), M, targetBB); + bool found = getReverseBBMap(getBranchTarget(instr, addr), M, + targetBB); assert(found); branchStub[index] = targetBB; } @@ -396,6 +424,7 @@ addr += 4; } } else{ + // All other instructions are simply copied. trace.push_back(instr); index++; } From alkis at cs.uiuc.edu Mon Dec 6 01:57:29 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Mon, 6 Dec 2004 01:57:29 -0600 Subject: [llvm-commits] CVS: llvm-java/lib/Compiler/Compiler.cpp Message-ID: <200412060757.BAA31826@zion.cs.uiuc.edu> Changes in directory llvm-java/lib/Compiler: Compiler.cpp updated: 1.168 -> 1.169 --- Log message: Make interface calls work. --- Diffs of the changes: (+29 -19) Index: llvm-java/lib/Compiler/Compiler.cpp diff -u llvm-java/lib/Compiler/Compiler.cpp:1.168 llvm-java/lib/Compiler/Compiler.cpp:1.169 --- llvm-java/lib/Compiler/Compiler.cpp:1.168 Sun Dec 5 19:00:46 2004 +++ llvm-java/lib/Compiler/Compiler.cpp Mon Dec 6 01:57:18 2004 @@ -628,7 +628,7 @@ globalName, &module_); - return gv; + return ConstantExpr::getCast(gv, PointerType::get(VTableInfo::VTableTy)); } /// Builds the interfaces vtable array for this classfile and its @@ -648,37 +648,46 @@ PointerType::get(PointerType::get(VTableInfo::VTableTy)))); // Otherwise we must fill in the interfaces vtables array. For - // each implemented vtable we insert a pointer to the + // each implemented interface we insert a pointer to the // vtable for this class. Note that we only // fill in up to the highest index of the implemented // interfaces. std::vector vtables; - const Classes& interfaces = cf->getInterfaces(); llvm::Constant* nullVTable = llvm::Constant::getNullValue(PointerType::get(VTableInfo::VTableTy)); - for (unsigned i = 0, e = interfaces.size(); i != e; ++i) { - ClassFile* interface = ClassFile::get(interfaces[i]->getName()->str()); - assert(interface->isInterface() && - "Class in interfaces list is not an interface!"); - const ClassInfo& interfaceCI = getClassInfo(interface); - if (interfaceCI.interfaceIdx >= vtables.size()) - vtables.resize(interfaceCI.interfaceIdx+1, nullVTable); - vtables[interfaceCI.interfaceIdx] = buildInterfaceVTable(cf, interface); + ClassFile* curCf = cf; + while (true) { + const Classes& interfaces = curCf->getInterfaces(); + for (unsigned i = 0, e = interfaces.size(); i != e; ++i) { + ClassFile* interface = + ClassFile::get(interfaces[i]->getName()->str()); + assert(interface->isInterface() && + "Class in interfaces list is not an interface!"); + const ClassInfo& interfaceCI = getClassInfo(interface); + if (interfaceCI.interfaceIdx >= vtables.size()) + vtables.resize(interfaceCI.interfaceIdx+1, nullVTable); + vtables[interfaceCI.interfaceIdx] = + buildInterfaceVTable(cf, interface); + } + if (!curCf->getSuperClass()) + break; + curCf = ClassFile::get(curCf->getSuperClass()->getName()->str()); } - ArrayType* interfacesArrayTy = - ArrayType::get(PointerType::get(VTableInfo::VTableTy), vtables.size()); - const std::string& globalName = cf->getThisClass()->getName()->str() + ""; - module_.addTypeName(globalName, interfacesArrayTy); + + llvm::Constant* init = ConstantArray::get( + ArrayType::get(PointerType::get(VTableInfo::VTableTy), vtables.size()), + vtables); + module_.addTypeName(globalName, init->getType()); GlobalVariable* interfacesArray = new GlobalVariable( - interfacesArrayTy, + init->getType(), true, GlobalVariable::ExternalLinkage, - ConstantArray::get(interfacesArrayTy, vtables), + init, globalName, &module_); @@ -2191,11 +2200,12 @@ interfaceVTable = new CastInst(interfaceVTable, vi->vtable->getType(), TMP, currentBB_); // Get the function pointer. - indices.resize(1); assert(vi->m2iMap.find(methodDescr) != vi->m2iMap.end() && "could not find slot for virtual function!"); unsigned vSlot = vi->m2iMap.find(methodDescr)->second; - indices.push_back(ConstantUInt::get(Type::UIntTy, vSlot)); + indices.resize(2); + indices[0] = ConstantUInt::get(Type::UIntTy, 0); + indices[1] = ConstantUInt::get(Type::UIntTy, vSlot); Value* vfunPtr = new GetElementPtrInst(interfaceVTable, indices, TMP, currentBB_); Value* vfun = new LoadInst(vfunPtr, className + '/' + methodDescr, From alkis at cs.uiuc.edu Mon Dec 6 02:10:40 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Mon, 6 Dec 2004 02:10:40 -0600 Subject: [llvm-commits] CVS: llvm-java/lib/Compiler/Compiler.cpp Message-ID: <200412060810.CAA32044@zion.cs.uiuc.edu> Changes in directory llvm-java/lib/Compiler: Compiler.cpp updated: 1.169 -> 1.170 --- Log message: Make instanceof work. --- Diffs of the changes: (+13 -6) Index: llvm-java/lib/Compiler/Compiler.cpp diff -u llvm-java/lib/Compiler/Compiler.cpp:1.169 llvm-java/lib/Compiler/Compiler.cpp:1.170 --- llvm-java/lib/Compiler/Compiler.cpp:1.169 Mon Dec 6 01:57:18 2004 +++ llvm-java/lib/Compiler/Compiler.cpp Mon Dec 6 02:10:29 2004 @@ -568,15 +568,22 @@ /// the array. std::pair buildSuperClassesVTables(ClassFile* cf, const VTableInfo& vi) const { - ArrayType* vtablesArrayTy = + std::vector superVtables(vi.superVtables.size()); + for (unsigned i = 0, e = vi.superVtables.size(); i != e; ++i) + superVtables[i] = ConstantExpr::getCast( + vi.superVtables[i], + PointerType::get(VTableInfo::VTableTy)); + + llvm::Constant* init = ConstantArray::get( ArrayType::get(PointerType::get(VTableInfo::VTableTy), - vi.superVtables.size()); + superVtables.size()), + superVtables); GlobalVariable* vtablesArray = new GlobalVariable( - vtablesArrayTy, + init->getType(), true, GlobalVariable::ExternalLinkage, - ConstantArray::get(vtablesArrayTy, vi.superVtables), + init, cf->getThisClass()->getName()->str() + "", &module_); @@ -610,8 +617,8 @@ assert(classVI.m2iMap.find(i->first) != classVI.m2iMap.end() && "Interface method not found in class definition!"); unsigned classMethodIdx = classVI.m2iMap.find(i->first)->second; - init[i->second] = - cast(classVI.vtable->getInitializer())->getElementAt(classMethodIdx); + init[i->second] = cast( + classVI.vtable->getInitializer())->getElementAt(classMethodIdx); } llvm::Constant* vtable = ConstantStruct::get(init); From gaeke at cs.uiuc.edu Mon Dec 6 03:09:48 2004 From: gaeke at cs.uiuc.edu (Brian Gaeke) Date: Mon, 6 Dec 2004 03:09:48 -0600 (CST) Subject: [llvm-commits] CVS: reopt/lib/TraceToFunction/TraceToFunction.cpp Message-ID: <200412060909.DAA07175@kain.cs.uiuc.edu> Changes in directory reopt/lib/TraceToFunction: TraceToFunction.cpp updated: 1.87 -> 1.88 --- Log message: Update a couple of doxygen comments. --- Diffs of the changes: (+3 -3) Index: reopt/lib/TraceToFunction/TraceToFunction.cpp diff -u reopt/lib/TraceToFunction/TraceToFunction.cpp:1.87 reopt/lib/TraceToFunction/TraceToFunction.cpp:1.88 --- reopt/lib/TraceToFunction/TraceToFunction.cpp:1.87 Tue Oct 26 15:08:20 2004 +++ reopt/lib/TraceToFunction/TraceToFunction.cpp Mon Dec 6 03:09:38 2004 @@ -561,8 +561,6 @@ /// buildFLIMap - Removes any FLI blocks which ended up in the trace, and /// identifies the source and sink BasicBlocks of all FLI-instrumented /// back-edges. Information about FLI edges is stored in the FLIMap. -/// Information about FLI sinks that could end up in the middle of the trace -/// is stored in the AlternateEntryPoints set. /// void TraceFunctionBuilder::buildFLIMap (Trace &T, FLIMapTy &FLIMap) { Function *F = T.getFunction (); @@ -585,7 +583,9 @@ } } -// Fill in b with all the (possible) alternate entry points into T. +/// findAlternateEntryPoints - Fill in b with all the (possible) alternate +/// entry points into T. +/// void TraceFunctionBuilder::findAlternateEntryPoints (Trace &T, std::vector &b) { for (Trace::iterator TI = T.begin (), TE = T.end(); TI != TE; ++TI) { From reid at x10sys.com Mon Dec 6 12:28:22 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 12:28:22 -0600 Subject: [llvm-commits] CVS: llvm-test/TEST.nightly.Makefile TEST.nightly.report Message-ID: <200412061828.MAA32334@zion.cs.uiuc.edu> Changes in directory llvm-test: TEST.nightly.Makefile updated: 1.34 -> 1.35 TEST.nightly.report updated: 1.29 -> 1.30 --- Log message: Excise the linear scan llc-BETA and cbe-BETA columns as linear scan is now the default. --- Diffs of the changes: (+4 -22) Index: llvm-test/TEST.nightly.Makefile diff -u llvm-test/TEST.nightly.Makefile:1.34 llvm-test/TEST.nightly.Makefile:1.35 --- llvm-test/TEST.nightly.Makefile:1.34 Sat Nov 6 15:34:36 2004 +++ llvm-test/TEST.nightly.Makefile Mon Dec 6 12:28:11 2004 @@ -20,9 +20,6 @@ ifndef DISABLE_CBE REPORTS_TO_GEN += cbe endif -ifdef ENABLE_LINEARSCAN -REPORTS_TO_GEN += llc-ls jit-ls -endif REPORTS_SUFFIX := $(addsuffix .report.txt, $(REPORTS_TO_GEN)) Index: llvm-test/TEST.nightly.report diff -u llvm-test/TEST.nightly.report:1.29 llvm-test/TEST.nightly.report:1.30 --- llvm-test/TEST.nightly.report:1.29 Sun Nov 7 16:13:29 2004 +++ llvm-test/TEST.nightly.report Mon Dec 6 12:28:11 2004 @@ -22,8 +22,8 @@ sub GCCCBERatio { my ($Cols, $Col) = @_; - my $GCC = $Cols->[$Col-6]; - my $CBE = $Cols->[$Col-5]; + my $GCC = $Cols->[$Col-4]; + my $CBE = $Cols->[$Col-3]; if ($GCC ne "*" and $CBE ne "*" and $CBE != "0") { return sprintf("%3.2f", $GCC/$CBE); } else { @@ -33,8 +33,8 @@ sub GCCLLCRatio { my ($Cols, $Col) = @_; - my $GCC = $Cols->[$Col-7]; - my $LLC = $Cols->[$Col-5]; + my $GCC = $Cols->[$Col-5]; + my $LLC = $Cols->[$Col-3]; if ($GCC ne "*" and $LLC ne "*" and $LLC != "0") { return sprintf("%3.2f", $GCC/$LLC); } else { @@ -42,17 +42,6 @@ } } -sub GCCLLC_BETARatio { - my ($Cols, $Col) = @_; - my $GCC = $Cols->[$Col-8]; - my $LLC_BETA = $Cols->[$Col-5]; - if ($GCC ne "*" and $LLC_BETA ne "*" and $LLC_BETA != "0") { - return sprintf("%3.2f", $GCC/$LLC_BETA); - } else { - return "n/a"; - } -} - # These are the columns for the report. The first entry is the header for the # column, the second is the regex to use to match the value. Empty list create # separators, and closures may be put in for custom processing. @@ -64,17 +53,13 @@ ["GCCAS" , "TEST-RESULT-compile: $WallTimeRE"], ["Bytecode" , 'TEST-RESULT-compile: *([0-9]+)'], ["LLC
compile" , "TEST-RESULT-llc: $WallTimeRE"], - ["LLC-BETA
compile" , "TEST-RESULT-llc-ls: $WallTimeRE"], ["JIT
codegen" , "TEST-RESULT-jit-comptime: $WallTimeRE"], ["Machine
code", 'TEST-RESULT-jit-machcode: *([0-9]+).*bytes of machine code'], [], ["GCC" , 'TEST-RESULT-nat-time: program\s*([.0-9m:]+)', \&FormatTime], ["CBE" , 'TEST-RESULT-cbe-time: program\s*([.0-9m:]+)', \&FormatTime], ["LLC" , 'TEST-RESULT-llc-time: program\s*([.0-9m:]+)', \&FormatTime], - ["LLC-BETA" , 'TEST-RESULT-llc-ls-time: program\s*([.0-9m:]+)', \&FormatTime], ["JIT" , 'TEST-RESULT-jit-time: program\s*([.0-9m:]+)', \&FormatTime], - ["JIT-BETA" , 'TEST-RESULT-jit-ls-time: program\s*([.0-9m:]+)', \&FormatTime], ["GCC/CBE" , \&GCCCBERatio], ["GCC/LLC" , \&GCCLLCRatio], - ["GCC/LLC-BETA" , \&GCCLLC_BETARatio] ); From reid at x10sys.com Mon Dec 6 12:29:25 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 12:29:25 -0600 Subject: [llvm-commits] CVS: llvm/utils/NightlyTestTemplate.html NightlyTest.pl Message-ID: <200412061829.MAA32366@zion.cs.uiuc.edu> Changes in directory llvm/utils: NightlyTestTemplate.html updated: 1.36 -> 1.37 NightlyTest.pl updated: 1.78 -> 1.79 --- Log message: Remove LLC-BETA and linear scan options as they are no longer reported. --- Diffs of the changes: (+0 -4) Index: llvm/utils/NightlyTestTemplate.html diff -u llvm/utils/NightlyTestTemplate.html:1.36 llvm/utils/NightlyTestTemplate.html:1.37 --- llvm/utils/NightlyTestTemplate.html:1.36 Sat Dec 4 14:18:21 2004 +++ llvm/utils/NightlyTestTemplate.html Mon Dec 6 12:29:14 2004 @@ -215,9 +215,6 @@ GCC output: greater than 1 is a speedup, less than 1 is a slowdown.
  • GCC/CBE - The speed-up of the CBE output vs the native GCC output: greater than 1 is a speedup, less than 1 is a slowdown.
    • -
  • LLC-BETA - How long does the program generated by the static - backend LLC take to execute the program, when compiled with new experimental - features. This is temporary, for tuning.

    • A complete log of testing Index: llvm/utils/NightlyTest.pl diff -u llvm/utils/NightlyTest.pl:1.78 llvm/utils/NightlyTest.pl:1.79 --- llvm/utils/NightlyTest.pl:1.78 Sat Dec 4 16:18:28 2004 +++ llvm/utils/NightlyTest.pl Mon Dec 6 12:29:14 2004 @@ -260,7 +260,6 @@ $MAKEOPTS = "$MAKEOPTS CompileOptimizeOpts='-O3 -DNDEBUG -finline-functions -Wpointer-arith -Wcast-align -Wno-deprecated -Wold-style-cast -Wabi -Woverloaded-virtual -ffor-scope'"; next; } - if (/^-enable-linscan$/) { $PROGTESTOPTS .= " ENABLE_LINEARSCAN=1"; next; } if (/^-disable-llc$/) { $PROGTESTOPTS .= " DISABLE_LLC=1"; $CONFIGUREARGS .= " --disable-llc_diffs"; next; } if (/^-disable-jit$/) { $PROGTESTOPTS .= " DISABLE_JIT=1"; From reid at x10sys.com Mon Dec 6 12:34:05 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 12:34:05 -0600 Subject: [llvm-commits] CVS: llvm/utils/NightlyTest.pl Message-ID: <200412061834.MAA32421@zion.cs.uiuc.edu> Changes in directory llvm/utils: NightlyTest.pl updated: 1.79 -> 1.80 --- Log message: Rather than break all the nightly test invocations, permit -enable-linscan option to be specified, but do nothing with it. --- Diffs of the changes: (+2 -1) Index: llvm/utils/NightlyTest.pl diff -u llvm/utils/NightlyTest.pl:1.79 llvm/utils/NightlyTest.pl:1.80 --- llvm/utils/NightlyTest.pl:1.79 Mon Dec 6 12:29:14 2004 +++ llvm/utils/NightlyTest.pl Mon Dec 6 12:33:54 2004 @@ -23,7 +23,7 @@ # -parallel Run two parallel jobs with GNU Make. # -release Build an LLVM Release version # -pedantic Enable additional GCC warnings to detect possible errors. -# -enable-linscan Enable linearscan tests +# -enable-linscan Accepted but ignored # -disable-llc Disable LLC tests in the nightly tester. # -disable-jit Disable JIT tests in the nightly tester. # -verbose Turn on some debug output @@ -260,6 +260,7 @@ $MAKEOPTS = "$MAKEOPTS CompileOptimizeOpts='-O3 -DNDEBUG -finline-functions -Wpointer-arith -Wcast-align -Wno-deprecated -Wold-style-cast -Wabi -Woverloaded-virtual -ffor-scope'"; next; } + if (/^-enable-linscan$/) { next; } if (/^-disable-llc$/) { $PROGTESTOPTS .= " DISABLE_LLC=1"; $CONFIGUREARGS .= " --disable-llc_diffs"; next; } if (/^-disable-jit$/) { $PROGTESTOPTS .= " DISABLE_JIT=1"; From reid at x10sys.com Mon Dec 6 14:13:41 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 14:13:41 -0600 Subject: [llvm-commits] CVS: llvm-test/TEST.nightly.report TEST.nightly.Makefile Message-ID: <200412062013.OAA01813@zion.cs.uiuc.edu> Changes in directory llvm-test: TEST.nightly.report updated: 1.30 -> 1.31 TEST.nightly.Makefile updated: 1.35 -> 1.36 --- Log message: Revert changes to remove llc-BETA, etc. as they are still needed for the iterative linear scan allocator. --- Diffs of the changes: (+22 -4) Index: llvm-test/TEST.nightly.report diff -u llvm-test/TEST.nightly.report:1.30 llvm-test/TEST.nightly.report:1.31 --- llvm-test/TEST.nightly.report:1.30 Mon Dec 6 12:28:11 2004 +++ llvm-test/TEST.nightly.report Mon Dec 6 14:13:31 2004 @@ -22,8 +22,8 @@ sub GCCCBERatio { my ($Cols, $Col) = @_; - my $GCC = $Cols->[$Col-4]; - my $CBE = $Cols->[$Col-3]; + my $GCC = $Cols->[$Col-6]; + my $CBE = $Cols->[$Col-5]; if ($GCC ne "*" and $CBE ne "*" and $CBE != "0") { return sprintf("%3.2f", $GCC/$CBE); } else { @@ -33,8 +33,8 @@ sub GCCLLCRatio { my ($Cols, $Col) = @_; - my $GCC = $Cols->[$Col-5]; - my $LLC = $Cols->[$Col-3]; + my $GCC = $Cols->[$Col-7]; + my $LLC = $Cols->[$Col-5]; if ($GCC ne "*" and $LLC ne "*" and $LLC != "0") { return sprintf("%3.2f", $GCC/$LLC); } else { @@ -42,6 +42,17 @@ } } +sub GCCLLC_BETARatio { + my ($Cols, $Col) = @_; + my $GCC = $Cols->[$Col-8]; + my $LLC_BETA = $Cols->[$Col-5]; + if ($GCC ne "*" and $LLC_BETA ne "*" and $LLC_BETA != "0") { + return sprintf("%3.2f", $GCC/$LLC_BETA); + } else { + return "n/a"; + } +} + # These are the columns for the report. The first entry is the header for the # column, the second is the regex to use to match the value. Empty list create # separators, and closures may be put in for custom processing. @@ -53,13 +64,17 @@ ["GCCAS" , "TEST-RESULT-compile: $WallTimeRE"], ["Bytecode" , 'TEST-RESULT-compile: *([0-9]+)'], ["LLC
    compile" , "TEST-RESULT-llc: $WallTimeRE"], + ["LLC-BETA
    compile" , "TEST-RESULT-llc-ls: $WallTimeRE"], ["JIT
    codegen" , "TEST-RESULT-jit-comptime: $WallTimeRE"], ["Machine
    code", 'TEST-RESULT-jit-machcode: *([0-9]+).*bytes of machine code'], [], ["GCC" , 'TEST-RESULT-nat-time: program\s*([.0-9m:]+)', \&FormatTime], ["CBE" , 'TEST-RESULT-cbe-time: program\s*([.0-9m:]+)', \&FormatTime], ["LLC" , 'TEST-RESULT-llc-time: program\s*([.0-9m:]+)', \&FormatTime], + ["LLC-BETA" , 'TEST-RESULT-llc-ls-time: program\s*([.0-9m:]+)', \&FormatTime], ["JIT" , 'TEST-RESULT-jit-time: program\s*([.0-9m:]+)', \&FormatTime], + ["JIT-BETA" , 'TEST-RESULT-jit-ls-time: program\s*([.0-9m:]+)', \&FormatTime], ["GCC/CBE" , \&GCCCBERatio], ["GCC/LLC" , \&GCCLLCRatio], + ["GCC/LLC-BETA" , \&GCCLLC_BETARatio] ); Index: llvm-test/TEST.nightly.Makefile diff -u llvm-test/TEST.nightly.Makefile:1.35 llvm-test/TEST.nightly.Makefile:1.36 --- llvm-test/TEST.nightly.Makefile:1.35 Mon Dec 6 12:28:11 2004 +++ llvm-test/TEST.nightly.Makefile Mon Dec 6 14:13:31 2004 @@ -20,6 +20,9 @@ ifndef DISABLE_CBE REPORTS_TO_GEN += cbe endif +ifdef ENABLE_LINEARSCAN +REPORTS_TO_GEN += llc-ls jit-ls +endif REPORTS_SUFFIX := $(addsuffix .report.txt, $(REPORTS_TO_GEN)) From reid at x10sys.com Mon Dec 6 14:14:56 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 14:14:56 -0600 Subject: [llvm-commits] CVS: llvm/utils/NightlyTest.pl NightlyTestTemplate.html Message-ID: <200412062014.OAA01847@zion.cs.uiuc.edu> Changes in directory llvm/utils: NightlyTest.pl updated: 1.80 -> 1.81 NightlyTestTemplate.html updated: 1.37 -> 1.38 --- Log message: Revert previous changes to remove -enable-linscan and the *BETA columns of the nightly test. These are still needed for iterative linear scan testing. --- Diffs of the changes: (+5 -2) Index: llvm/utils/NightlyTest.pl diff -u llvm/utils/NightlyTest.pl:1.80 llvm/utils/NightlyTest.pl:1.81 --- llvm/utils/NightlyTest.pl:1.80 Mon Dec 6 12:33:54 2004 +++ llvm/utils/NightlyTest.pl Mon Dec 6 14:14:45 2004 @@ -23,7 +23,7 @@ # -parallel Run two parallel jobs with GNU Make. # -release Build an LLVM Release version # -pedantic Enable additional GCC warnings to detect possible errors. -# -enable-linscan Accepted but ignored +# -enable-linscan Enable linearscan tests # -disable-llc Disable LLC tests in the nightly tester. # -disable-jit Disable JIT tests in the nightly tester. # -verbose Turn on some debug output @@ -260,7 +260,7 @@ $MAKEOPTS = "$MAKEOPTS CompileOptimizeOpts='-O3 -DNDEBUG -finline-functions -Wpointer-arith -Wcast-align -Wno-deprecated -Wold-style-cast -Wabi -Woverloaded-virtual -ffor-scope'"; next; } - if (/^-enable-linscan$/) { next; } + if (/^-enable-linscan$/) { $PROGTESTOPTS .= " ENABLE_LINEARSCAN=1"; next; } if (/^-disable-llc$/) { $PROGTESTOPTS .= " DISABLE_LLC=1"; $CONFIGUREARGS .= " --disable-llc_diffs"; next; } if (/^-disable-jit$/) { $PROGTESTOPTS .= " DISABLE_JIT=1"; Index: llvm/utils/NightlyTestTemplate.html diff -u llvm/utils/NightlyTestTemplate.html:1.37 llvm/utils/NightlyTestTemplate.html:1.38 --- llvm/utils/NightlyTestTemplate.html:1.37 Mon Dec 6 12:29:14 2004 +++ llvm/utils/NightlyTestTemplate.html Mon Dec 6 14:14:45 2004 @@ -215,6 +215,9 @@ GCC output: greater than 1 is a speedup, less than 1 is a slowdown.

  • GCC/CBE - The speed-up of the CBE output vs the native GCC output: greater than 1 is a speedup, less than 1 is a slowdown.
    • +
  • LLC-BETA - How long does the program generated by the static + backend LLC take to execute the program, when compiled with new experimental + features. This is temporary, for tuning.

    • A complete log of testing From criswell at cs.uiuc.edu Mon Dec 6 15:12:13 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:12:13 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/ Message-ID: <200412062112.PAA20682@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime added to the repository --> Using per-directory sticky tag `ROOT_RELEASE_14' --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:13:32 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:13:32 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/libpng/ Message-ID: <200412062113.PAA20774@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/libpng: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/libpng added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:13:32 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:13:32 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/ Message-ID: <200412062113.PAA20775@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:16:40 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:16:40 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/libpng/contrib/ Message-ID: <200412062116.PAA21188@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/libpng/contrib: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/libpng/contrib added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:16:46 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:16:46 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/libpng/projects/ Message-ID: <200412062116.PAA21219@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/libpng/projects: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/libpng/projects added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:16:46 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:16:46 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/libpng/scripts/ Message-ID: <200412062116.PAA21220@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/libpng/scripts: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/libpng/scripts added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:19 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:19 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/amiga/ Message-ID: <200412062118.PAA21514@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/amiga: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/amiga added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:25 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:25 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/ada/ Message-ID: <200412062118.PAA21539@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/ada: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/ada added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:25 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:25 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/asm586/ Message-ID: <200412062118.PAA21542@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/asm586: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/asm586 added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/delphi/ Message-ID: <200412062118.PAA21554@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/delphi: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/delphi added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/gzappend/ Message-ID: <200412062118.PAA21557@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/gzappend: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/gzappend added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:25 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:25 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/asm686/ Message-ID: <200412062118.PAA21545@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/asm686: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/asm686 added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:25 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:25 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/blast/ Message-ID: <200412062118.PAA21550@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/blast: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/blast added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/infback9/ Message-ID: <200412062118.PAA21560@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/infback9: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/infback9 added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/iostream2/ Message-ID: <200412062118.PAA21569@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/iostream2: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/iostream2 added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/masm686/ Message-ID: <200412062118.PAA21575@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/masm686: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/masm686 added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/masmx86/ Message-ID: <200412062118.PAA21576@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/masmx86: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/masmx86 added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:19:55 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:19:55 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/as400/bndsrc compile.clp readme.txt zlib.inc Message-ID: <200412062119.PAA21656@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/as400: bndsrc added (r1.1) compile.clp added (r1.1) readme.txt added (r1.1) zlib.inc added (r1.1) --- Log message: Addition of runtime libraries needed for testing. Namely, libpng and zlib return to the testsuite for Povray. --- Diffs of the changes: (+693 -0) Index: llvm-test/Runtime/zlib/as400/bndsrc diff -c /dev/null llvm-test/Runtime/zlib/as400/bndsrc:1.1 *** /dev/null Mon Dec 6 15:19:50 2004 --- llvm-test/Runtime/zlib/as400/bndsrc Mon Dec 6 15:19:40 2004 *************** *** 0 **** --- 1,132 ---- + STRPGMEXP PGMLVL(*CURRENT) SIGNATURE('ZLIB') + + /*@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@*/ + /* Version 1.1.3 entry points. */ + /*@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@*/ + + /********************************************************************/ + /* *MODULE ADLER32 ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("adler32") + + /********************************************************************/ + /* *MODULE COMPRESS ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("compress") + EXPORT SYMBOL("compress2") + + /********************************************************************/ + /* *MODULE CRC32 ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("crc32") + EXPORT SYMBOL("get_crc_table") + + /********************************************************************/ + /* *MODULE DEFLATE ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("deflate") + EXPORT SYMBOL("deflateEnd") + EXPORT SYMBOL("deflateSetDictionary") + EXPORT SYMBOL("deflateCopy") + EXPORT SYMBOL("deflateReset") + EXPORT SYMBOL("deflateParams") + EXPORT SYMBOL("deflatePrime") + EXPORT SYMBOL("deflateInit_") + EXPORT SYMBOL("deflateInit2_") + + /********************************************************************/ + /* *MODULE GZIO ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("gzopen") + EXPORT SYMBOL("gzdopen") + EXPORT SYMBOL("gzsetparams") + EXPORT SYMBOL("gzread") + EXPORT SYMBOL("gzwrite") + EXPORT SYMBOL("gzprintf") + EXPORT SYMBOL("gzputs") + EXPORT SYMBOL("gzgets") + EXPORT SYMBOL("gzputc") + EXPORT SYMBOL("gzgetc") + EXPORT SYMBOL("gzflush") + EXPORT SYMBOL("gzseek") + EXPORT SYMBOL("gzrewind") + EXPORT SYMBOL("gztell") + EXPORT SYMBOL("gzeof") + EXPORT SYMBOL("gzclose") + EXPORT SYMBOL("gzerror") + + /********************************************************************/ + /* *MODULE INFLATE ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("inflate") + EXPORT SYMBOL("inflateEnd") + EXPORT SYMBOL("inflateSetDictionary") + EXPORT SYMBOL("inflateSync") + EXPORT SYMBOL("inflateReset") + EXPORT SYMBOL("inflateInit_") + EXPORT SYMBOL("inflateInit2_") + EXPORT SYMBOL("inflateSyncPoint") + + /********************************************************************/ + /* *MODULE UNCOMPR ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("uncompress") + + /********************************************************************/ + /* *MODULE ZUTIL ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("zlibVersion") + EXPORT SYMBOL("zError") + + /*@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@*/ + /* Version 1.2.1 additional entry points. */ + /*@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@*/ + + /********************************************************************/ + /* *MODULE COMPRESS ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("compressBound") + + /********************************************************************/ + /* *MODULE DEFLATE ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("deflateBound") + + /********************************************************************/ + /* *MODULE GZIO ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("gzungetc") + EXPORT SYMBOL("gzclearerr") + + /********************************************************************/ + /* *MODULE INFBACK ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("inflateBack") + EXPORT SYMBOL("inflateBackEnd") + EXPORT SYMBOL("inflateBackInit_") + + /********************************************************************/ + /* *MODULE INFLATE ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("inflateCopy") + + /********************************************************************/ + /* *MODULE ZUTIL ZLIB 01/02/01 00:15:09 */ + /********************************************************************/ + + EXPORT SYMBOL("zlibCompileFlags") + + ENDPGMEXP Index: llvm-test/Runtime/zlib/as400/compile.clp diff -c /dev/null llvm-test/Runtime/zlib/as400/compile.clp:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/as400/compile.clp Mon Dec 6 15:19:40 2004 *************** *** 0 **** --- 1,123 ---- + /******************************************************************************/ + /* */ + /* ZLIB */ + /* */ + /* Compile sources into modules and link them into a service program. */ + /* */ + /******************************************************************************/ + + PGM + + /* Configuration adjustable parameters. */ + + DCL VAR(&SRCLIB) TYPE(*CHAR) LEN(10) + + VALUE('ZLIB') /* Source library. */ + DCL VAR(&SRCFILE) TYPE(*CHAR) LEN(10) + + VALUE('SOURCES') /* Source member file. */ + DCL VAR(&CTLFILE) TYPE(*CHAR) LEN(10) + + VALUE('TOOLS') /* Control member file. */ + + DCL VAR(&MODLIB) TYPE(*CHAR) LEN(10) + + VALUE('ZLIB') /* Module library. */ + + DCL VAR(&SRVLIB) TYPE(*CHAR) LEN(10) + + VALUE('LGPL') /* Service program library. */ + + DCL VAR(&CFLAGS) TYPE(*CHAR) + + VALUE('OPTIMIZE(40)') /* Compile options. */ + + + /* Working storage. */ + + DCL VAR(&CMDLEN) TYPE(*DEC) LEN(15 5) VALUE(300) /* Command length. */ + DCL VAR(&CMD) TYPE(*CHAR) LEN(512) + + + /* Compile sources into modules. */ + + CHGVAR VAR(&CMD) VALUE('CRTCMOD MODULE(' *TCAT &MODLIB *TCAT + + '/ADLER32) SRCFILE(' *TCAT + + &SRCLIB *TCAT '/' *TCAT &SRCFILE *TCAT + + ') SYSIFCOPT(*IFSIO)' *BCAT &CFLAGS) + CALL PGM(QCMDEXC) PARM(&CMD &CMDLEN) + + CHGVAR VAR(&CMD) VALUE('CRTCMOD MODULE(' *TCAT &MODLIB *TCAT + + '/COMPRESS) SRCFILE(' *TCAT + + &SRCLIB *TCAT '/' *TCAT &SRCFILE *TCAT + + ') SYSIFCOPT(*IFSIO)' *BCAT &CFLAGS) + CALL PGM(QCMDEXC) PARM(&CMD &CMDLEN) + + CHGVAR VAR(&CMD) VALUE('CRTCMOD MODULE(' *TCAT &MODLIB *TCAT + + '/CRC32) SRCFILE(' *TCAT + + &SRCLIB *TCAT '/' *TCAT &SRCFILE *TCAT + + ') SYSIFCOPT(*IFSIO)' *BCAT &CFLAGS) + CALL PGM(QCMDEXC) PARM(&CMD &CMDLEN) + + CHGVAR VAR(&CMD) VALUE('CRTCMOD MODULE(' *TCAT &MODLIB *TCAT + + '/DEFLATE) SRCFILE(' *TCAT + + &SRCLIB *TCAT '/' *TCAT &SRCFILE *TCAT + + ') SYSIFCOPT(*IFSIO)' *BCAT &CFLAGS) + CALL PGM(QCMDEXC) PARM(&CMD &CMDLEN) + + CHGVAR VAR(&CMD) VALUE('CRTCMOD MODULE(' *TCAT &MODLIB *TCAT + + '/GZIO) SRCFILE(' *TCAT + + &SRCLIB *TCAT '/' *TCAT &SRCFILE *TCAT + + ') SYSIFCOPT(*IFSIO)' *BCAT &CFLAGS) + CALL PGM(QCMDEXC) PARM(&CMD &CMDLEN) + + CHGVAR VAR(&CMD) VALUE('CRTCMOD MODULE(' *TCAT &MODLIB *TCAT + + '/INFBACK) SRCFILE(' *TCAT + + &SRCLIB *TCAT '/' *TCAT &SRCFILE *TCAT + + ') SYSIFCOPT(*IFSIO)' *BCAT &CFLAGS) + CALL PGM(QCMDEXC) PARM(&CMD &CMDLEN) + + CHGVAR VAR(&CMD) VALUE('CRTCMOD MODULE(' *TCAT &MODLIB *TCAT + + '/INFFAST) SRCFILE(' *TCAT + + &SRCLIB *TCAT '/' *TCAT &SRCFILE *TCAT + + ') SYSIFCOPT(*IFSIO)' *BCAT &CFLAGS) + CALL PGM(QCMDEXC) PARM(&CMD &CMDLEN) + + CHGVAR VAR(&CMD) VALUE('CRTCMOD MODULE(' *TCAT &MODLIB *TCAT + + '/INFLATE) SRCFILE(' *TCAT + + &SRCLIB *TCAT '/' *TCAT &SRCFILE *TCAT + + ') SYSIFCOPT(*IFSIO)' *BCAT &CFLAGS) + CALL PGM(QCMDEXC) PARM(&CMD &CMDLEN) + + CHGVAR VAR(&CMD) VALUE('CRTCMOD MODULE(' *TCAT &MODLIB *TCAT + + '/INFTREES) SRCFILE(' *TCAT + + &SRCLIB *TCAT '/' *TCAT &SRCFILE *TCAT + + ') SYSIFCOPT(*IFSIO)' *BCAT &CFLAGS) + CALL PGM(QCMDEXC) PARM(&CMD &CMDLEN) + + CHGVAR VAR(&CMD) VALUE('CRTCMOD MODULE(' *TCAT &MODLIB *TCAT + + '/TREES) SRCFILE(' *TCAT + + &SRCLIB *TCAT '/' *TCAT &SRCFILE *TCAT + + ') SYSIFCOPT(*IFSIO)' *BCAT &CFLAGS) + CALL PGM(QCMDEXC) PARM(&CMD &CMDLEN) + + CHGVAR VAR(&CMD) VALUE('CRTCMOD MODULE(' *TCAT &MODLIB *TCAT + + '/UNCOMPR) SRCFILE(' *TCAT + + &SRCLIB *TCAT '/' *TCAT &SRCFILE *TCAT + + ') SYSIFCOPT(*IFSIO)' *BCAT &CFLAGS) + CALL PGM(QCMDEXC) PARM(&CMD &CMDLEN) + + CHGVAR VAR(&CMD) VALUE('CRTCMOD MODULE(' *TCAT &MODLIB *TCAT + + '/ZUTIL) SRCFILE(' *TCAT + + &SRCLIB *TCAT '/' *TCAT &SRCFILE *TCAT + + ') SYSIFCOPT(*IFSIO)' *BCAT &CFLAGS) + CALL PGM(QCMDEXC) PARM(&CMD &CMDLEN) + + + /* Link modules into a service program. */ + + CRTSRVPGM SRVPGM(&SRVLIB/ZLIB) + + MODULE(&MODLIB/ADLER32 &MODLIB/COMPRESS + + &MODLIB/CRC32 &MODLIB/DEFLATE + + &MODLIB/GZIO &MODLIB/INFBACK + + &MODLIB/INFFAST &MODLIB/INFLATE + + &MODLIB/INFTREES &MODLIB/TREES + + &MODLIB/UNCOMPR &MODLIB/ZUTIL) + + SRCFILE(&SRCLIB/&CTLFILE) SRCMBR(BNDSRC) + + TEXT('ZLIB 1.2.1') TGTRLS(V4R4M0) + + ENDPGM Index: llvm-test/Runtime/zlib/as400/readme.txt diff -c /dev/null llvm-test/Runtime/zlib/as400/readme.txt:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/as400/readme.txt Mon Dec 6 15:19:40 2004 *************** *** 0 **** --- 1,111 ---- + ZLIB version 1.2.1 for AS400 installation instructions + + I) From an AS400 *SAVF file: + + 1) Unpacking archive to an AS400 save file + + On the AS400: + + _ Create the ZLIB AS400 library: + + CRTLIB LIB(ZLIB) TYPE(PROD) TEXT('ZLIB compression API library') + + _ Create a work save file, for example: + + CRTSAVF FILE(ZLIB/ZLIBSAVF) + + On a PC connected to the target AS400: + + _ Unpack the save file image to a PC file "ZLIBSAVF" + _ Upload this file into the save file on the AS400, for example + using ftp in BINARY mode. + + + 2) Populating the ZLIB AS400 source library + + On the AS400: + + _ Extract the saved objects into the ZLIB AS400 library using: + + RSTOBJ OBJ(*ALL) SAVLIB(ZLIB) DEV(*SAVF) SAVF(ZLIB/ZLIBSAVF) RSTLIB(ZLIB) + + + 3) Customize installation: + + _ Edit CL member ZLIB/TOOLS(COMPILE) and change parameters if needed, + according to the comments. + + _ Compile this member with: + + CRTCLPGM PGM(ZLIB/COMPILE) SRCFILE(ZLIB/TOOLS) SRCMBR(COMPILE) + + + 4) Compile and generate the service program: + + _ This can now be done by executing: + + CALL PGM(ZLIB/COMPILE) + + + + II) From the original source distribution: + + 1) On the AS400, create the source library: + + CRTLIB LIB(ZLIB) TYPE(PROD) TEXT('ZLIB compression API library') + + 2) Create the source files: + + CRTSRCPF FILE(ZLIB/SOURCES) RCDLEN(112) TEXT('ZLIB library modules') + CRTSRCPF FILE(ZLIB/H) RCDLEN(112) TEXT('ZLIB library includes') + CRTSRCPF FILE(ZLIB/TOOLS) RCDLEN(112) TEXT('ZLIB library control utilities') + + 3) From the machine hosting the distribution files, upload them (with + FTP in text mode, for example) according to the following table: + + Original AS400 AS400 AS400 AS400 + file file member type description + SOURCES Original ZLIB C subprogram sources + adler32.c ADLER32 C ZLIB - Compute the Adler-32 checksum of a dta strm + compress.c COMPRESS C ZLIB - Compress a memory buffer + crc32.c CRC32 C ZLIB - Compute the CRC-32 of a data stream + deflate.c DEFLATE C ZLIB - Compress data using the deflation algorithm + gzio.c GZIO C ZLIB - IO on .gz files + infback.c INFBACK C ZLIB - Inflate using a callback interface + inffast.c INFFAST C ZLIB - Fast proc. literals & length/distance pairs + inflate.c INFLATE C ZLIB - Interface to inflate modules + inftrees.c INFTREES C ZLIB - Generate Huffman trees for efficient decode + trees.c TREES C ZLIB - Output deflated data using Huffman coding + uncompr.c UNCOMPR C ZLIB - Decompress a memory buffer + zutil.c ZUTIL C ZLIB - Target dependent utility functions + H Original ZLIB C and ILE/RPG include files + crc32.h CRC32 C ZLIB - CRC32 tables + deflate.h DEFLATE C ZLIB - Internal compression state + inffast.h INFFAST C ZLIB - Header to use inffast.c + inffixed.h INFFIXED C ZLIB - Table for decoding fixed codes + inflate.h INFLATE C ZLIB - Internal inflate state definitions + inftrees.h INFTREES C ZLIB - Header to use inftrees.c + trees.h TREES C ZLIB - Created automatically with -DGEN_TREES_H + zconf.h ZCONF C ZLIB - Compression library configuration + zlib.h ZLIB C ZLIB - Compression library C user interface + as400/zlib.inc ZLIB.INC RPGLE ZLIB - Compression library ILE RPG user interface + zutil.h ZUTIL C ZLIB - Internal interface and configuration + TOOLS Building source software & AS/400 README + as400/bndsrc BNDSRC Entry point exportation list + as400/compile.clp COMPILE CLP Compile sources & generate service program + as400/readme.txt README TXT Installation instructions + + 4) Continue as in I)3). + + + + + Notes: For AS400 ILE RPG programmers, a /copy member defining the ZLIB + API prototypes for ILE RPG can be found in ZLIB/H(ZLIB.INC). + Please read comments in this member for more information. + + Remember that most foreign textual data are ASCII coded: this + implementation does not handle conversion from/to ASCII, so + text data code conversions must be done explicitely. + + Always open zipped files in binary mode. Index: llvm-test/Runtime/zlib/as400/zlib.inc diff -c /dev/null llvm-test/Runtime/zlib/as400/zlib.inc:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/as400/zlib.inc Mon Dec 6 15:19:40 2004 *************** *** 0 **** --- 1,327 ---- + * ZLIB.INC - Interface to the general purpose compression library + * + * ILE RPG400 version by Patrick Monnerat, DATASPHERE. + * Version 1.2.1 + * + * + * WARNING: + * Procedures inflateInit(), inflateInit2(), deflateInit(), + * deflateInit2() and inflateBackInit() need to be called with + * two additional arguments: + * the package version string and the stream control structure. + * size. This is needed because RPG lacks some macro feature. + * Call these procedures as: + * inflateInit(...: ZLIB_VERSION: %size(z_stream)) + * + /if not defined(ZLIB_H_) + /define ZLIB_H_ + * + ************************************************************************** + * Constants + ************************************************************************** + * + D ZLIB_VERSION C '1.2.1' Header's version + D ZLIB_VERNUM C X'1210' + * + D Z_NO_FLUSH C 0 + D Z_SYNC_FLUSH C 2 + D Z_FULL_FLUSH C 3 + D Z_FINISH C 4 + D Z_BLOCK C 5 + * + D Z_OK C 0 + D Z_STREAM_END C 1 + D Z_NEED_DICT C 2 + D Z_ERRNO C -1 + D Z_STREAM_ERROR C -2 + D Z_DATA_ERROR C -3 + D Z_MEM_ERROR C -4 + D Z_BUF_ERROR C -5 + DZ_VERSION_ERROR C -6 + * + D Z_NO_COMPRESSION... + D C 0 + D Z_BEST_SPEED C 1 + D Z_BEST_COMPRESSION... + D C 9 + D Z_DEFAULT_COMPRESSION... + D C -1 + * + D Z_FILTERED C 1 + D Z_HUFFMAN_ONLY C 2 + D Z_RLE C 3 + D Z_DEFAULT_STRATEGY... + D C 0 + * + D Z_BINARY C 0 + D Z_ASCII C 1 + D Z_UNKNOWN C 2 + * + D Z_DEFLATED C 8 + * + D Z_NULL C 0 + * + ************************************************************************** + * Types + ************************************************************************** + * + D z_streamp S * Stream struct ptr + D gzFile S * File pointer + D z_off_t S 10i 0 Stream offsets + * + ************************************************************************** + * Structures + ************************************************************************** + * + * The GZIP encode/decode stream support structure. + * + D z_stream DS align based(z_streamp) + D zs_next_in * Next input byte + D zs_avail_in 10U 0 Byte cnt at next_in + D zs_total_in 10U 0 Total bytes read + D zs_next_out * Output buffer ptr + D zs_avail_out 10U 0 Room left @ next_out + D zs_total_out 10U 0 Total bytes written + D zs_msg * Last errmsg or null + D zs_state * Internal state + D zs_zalloc * procptr Int. state allocator + D zs_free * procptr Int. state dealloc. + D zs_opaque * Private alloc. data + D zs_data_type 10i 0 ASC/BIN best guess + D zs_adler 10u 0 Uncompr. adler32 val + D 10U 0 Reserved + D 10U 0 Ptr. alignment + * + ************************************************************************** + * Utility function prototypes + ************************************************************************** + * + D compress PR 10I 0 extproc('compress') + D dest 32767 options(*varsize) Destination buffer + D destLen 10U 0 Destination length + D source 32767 const options(*varsize) Source buffer + D sourceLen 10u 0 value Source length + * + D compress2 PR 10I 0 extproc('compress2') + D dest 32767 options(*varsize) Destination buffer + D destLen 10U 0 Destination length + D source 32767 const options(*varsize) Source buffer + D sourceLen 10U 0 value Source length + D level 10I 0 value Compression level + * + D compressBound PR 10U 0 extproc('compressBound') + D sourceLen 10U 0 value + * + D uncompress PR 10I 0 extproc('uncompress') + D dest 32767 options(*varsize) Destination buffer + D destLen 10U 0 Destination length + D source 32767 const options(*varsize) Source buffer + D sourceLen 10U 0 value Source length + * + D gzopen PR extproc('gzopen') + D like(gzFile) + D path * value options(*string) File pathname + D mode * value options(*string) Open mode + * + D gzdopen PR extproc('gzdopen') + D like(gzFile) + D fd 10i 0 value File descriptor + D mode * value options(*string) Open mode + * + D gzsetparams PR 10I 0 extproc('gzsetparams') + D file value like(gzFile) File pointer + D level 10I 0 value + D strategy 10i 0 value + * + D gzread PR 10I 0 extproc('gzread') + D file value like(gzFile) File pointer + D buf 32767 options(*varsize) Buffer + D len 10u 0 value Buffer length + * + D gzwrite PR 10I 0 extproc('gzwrite') + D file value like(gzFile) File pointer + D buf 32767 const options(*varsize) Buffer + D len 10u 0 value Buffer length + * + D gzputs PR 10I 0 extproc('gzputs') + D file value like(gzFile) File pointer + D s * value options(*string) String to output + * + D gzgets PR * extproc('gzgets') + D file value like(gzFile) File pointer + D buf 32767 options(*varsize) Read buffer + D len 10i 0 value Buffer length + * + D gzflush PR 10i 0 extproc('gzflush') + D file value like(gzFile) File pointer + D flush 10I 0 value Type of flush + * + D gzseek PR extproc('gzseek') + D like(z_off_t) + D file value like(gzFile) File pointer + D offset value like(z_off_t) Offset + D whence 10i 0 value Origin + * + D gzrewind PR 10i 0 extproc('gzrewind') + D file value like(gzFile) File pointer + * + D gztell PR extproc('gztell') + D like(z_off_t) + D file value like(gzFile) File pointer + * + D gzeof PR 10i 0 extproc('gzeof') + D file value like(gzFile) File pointer + * + D gzclose PR 10i 0 extproc('gzclose') + D file value like(gzFile) File pointer + * + D gzerror PR * extproc('gzerror') Error string + D file value like(gzFile) File pointer + D errnum 10I 0 Error code + * + D gzclearerr PR extproc('gzclearerr') + D file value like(gzFile) File pointer + * + ************************************************************************** + * Basic function prototypes + ************************************************************************** + * + D zlibVersion PR * extproc('zlibVersion') Version string + * + D deflateInit PR 10I 0 extproc('deflateInit_') Init. compression + D strm like(z_stream) Compression stream + D level 10I 0 value Compression level + D version * value options(*string) Version string + D stream_size 10i 0 value Stream struct. size + * + D deflate PR 10I 0 extproc('deflate') Compress data + D strm like(z_stream) Compression stream + D flush 10I 0 value Flush type required + * + D deflateEnd PR 10I 0 extproc('deflateEnd') Termin. compression + D strm like(z_stream) Compression stream + * + D inflateInit PR 10I 0 extproc('inflateInit_') Init. expansion + D strm like(z_stream) Expansion stream + D version * value options(*string) Version string + D stream_size 10i 0 value Stream struct. size + * + D inflate PR 10I 0 extproc('inflate') Expand data + D strm like(z_stream) Expansion stream + D flush 10I 0 value Flush type required + * + D inflateEnd PR 10I 0 extproc('inflateEnd') Termin. expansion + D strm like(z_stream) Expansion stream + * + ************************************************************************** + * Advanced function prototypes + ************************************************************************** + * + D deflateInit2 PR 10I 0 extproc('deflateInit2_') Init. compression + D strm like(z_stream) Compression stream + D level 10I 0 value Compression level + D method 10I 0 value Compression method + D windowBits 10I 0 value log2(window size) + D memLevel 10I 0 value Mem/cmpress tradeoff + D strategy 10I 0 value Compression stategy + D version * value options(*string) Version string + D stream_size 10i 0 value Stream struct. size + * + D deflateSetDictionary... + D PR 10I 0 extproc('deflateSetDictionary') Init. dictionary + D strm like(z_stream) Compression stream + D dictionary 32767 const options(*varsize) Dictionary bytes + D dictLength 10U 0 value Dictionary length + * + D deflateCopy PR 10I 0 extproc('deflateCopy') Compress strm 2 strm + D dest like(z_stream) Destination stream + D source like(z_stream) Source stream + * + D deflateReset PR 10I 0 extproc('deflateReset') End and init. stream + D strm like(z_stream) Compression stream + * + D deflateParams PR 10I 0 extproc('deflateParams') Change level & strat + D strm like(z_stream) Compression stream + D level 10I 0 value Compression level + D strategy 10I 0 value Compression stategy + * + D deflateBound PR 10U 0 extproc('deflateBound') Change level & strat + D strm like(z_stream) Compression stream + D sourcelen 10U 0 value Compression level + * + D deflatePrime PR 10I 0 extproc('deflatePrime') Change level & strat + D strm like(z_stream) Compression stream + D bits 10I 0 value Number of bits to insert + D value 10I 0 value Bits to insert + * + D inflateInit2 PR 10I 0 extproc('inflateInit2_') Init. expansion + D strm like(z_stream) Expansion stream + D windowBits 10I 0 value log2(window size) + D version * value options(*string) Version string + D stream_size 10i 0 value Stream struct. size + * + D inflateSetDictionary... + D PR 10I 0 extproc('inflateSetDictionary') Init. dictionary + D strm like(z_stream) Expansion stream + D dictionary 32767 const options(*varsize) Dictionary bytes + D dictLength 10U 0 value Dictionary length + * + D inflateSync PR 10I 0 extproc('inflateSync') Sync. expansion + D strm like(z_stream) Expansion stream + * + D inflateCopy PR 10I 0 extproc('inflateCopy') + D dest like(z_stream) Destination stream + D source like(z_stream) Source stream + * + D inflateReset PR 10I 0 extproc('inflateReset') End and init. stream + D strm like(z_stream) Expansion stream + * + D inflateBackInit... + D PR 10I 0 extproc('inflateBackInit_') + D strm like(z_stream) Expansion stream + D windowBits 10I 0 value Log2(buffer size) + D window 32767 options(*varsize) Buffer + D version * value options(*string) Version string + D stream_size 10i 0 value Stream struct. size + * + D inflateBack PR 10I 0 extproc('inflateBack') + D strm like(z_stream) Expansion stream + D in * value procptr Input function + D in_desc * value Input descriptor + D out * value procptr Output function + D out_desc * value Output descriptor + * + D inflateBackEnd PR 10I 0 extproc('inflateBackEnd') + D strm like(z_stream) Expansion stream + * + D zlibCompileFlags... + D PR 10U 0 extproc('zlibCompileFlags') + * + ************************************************************************** + * Checksum function prototypes + ************************************************************************** + * + D adler32 PR 10U 0 extproc('adler32') New checksum + D adler 10U 0 value Old checksum + D buf 32767 const options(*varsize) Bytes to accumulate + D len 10U 0 value Buffer length + * + D crc32 PR 10U 0 extproc('crc32') New checksum + D crc 10U 0 value Old checksum + D buf 32767 const options(*varsize) Bytes to accumulate + D len 10U 0 value Buffer length + * + ************************************************************************** + * Miscellaneous function prototypes + ************************************************************************** + * + D zError PR * extproc('zError') Error string + D err 10I 0 value Error code + * + D inflateSyncPoint... + D PR 10I 0 extproc('inflateSyncPoint') + D strm like(z_stream) Expansion stream + * + D get_crc_table PR * extproc('get_crc_table') Ptr to ulongs + * + /endif From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/minizip/ Message-ID: <200412062118.PAA21577@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/minizip: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/minizip added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:19:55 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:19:55 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/amiga/Makefile.pup Makefile.sas Message-ID: <200412062119.PAA21659@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/amiga: Makefile.pup added (r1.1) Makefile.sas added (r1.1) --- Log message: Addition of runtime libraries needed for testing. Namely, libpng and zlib return to the testsuite for Povray. --- Diffs of the changes: (+131 -0) Index: llvm-test/Runtime/zlib/amiga/Makefile.pup diff -c /dev/null llvm-test/Runtime/zlib/amiga/Makefile.pup:1.1 *** /dev/null Mon Dec 6 15:19:50 2004 --- llvm-test/Runtime/zlib/amiga/Makefile.pup Mon Dec 6 15:19:40 2004 *************** *** 0 **** --- 1,66 ---- + # Amiga powerUP (TM) Makefile + # makefile for libpng and SAS C V6.58/7.00 PPC compiler + # Copyright (C) 1998 by Andreas R. Kleinert + + LIBNAME = libzip.a + + CC = scppc + CFLAGS = NOSTKCHK NOSINT OPTIMIZE OPTGO OPTPEEP OPTINLOCAL OPTINL \ + OPTLOOP OPTRDEP=8 OPTDEP=8 OPTCOMP=8 NOVER + AR = ppc-amigaos-ar cr + RANLIB = ppc-amigaos-ranlib + LD = ppc-amigaos-ld -r + LDFLAGS = -o + LDLIBS = LIB:scppc.a LIB:end.o + RM = delete quiet + + OBJS = adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o \ + zutil.o inflate.o infback.o inftrees.o inffast.o + + TEST_OBJS = example.o minigzip.o + + all: example minigzip + + check: test + test: all + example + echo hello world | minigzip | minigzip -d + + $(LIBNAME): $(OBJS) + $(AR) $@ $(OBJS) + -$(RANLIB) $@ + + example: example.o $(LIBNAME) + $(LD) $(LDFLAGS) $@ LIB:c_ppc.o $@.o $(LIBNAME) $(LDLIBS) + + minigzip: minigzip.o $(LIBNAME) + $(LD) $(LDFLAGS) $@ LIB:c_ppc.o $@.o $(LIBNAME) $(LDLIBS) + + mostlyclean: clean + clean: + $(RM) *.o example minigzip $(LIBNAME) foo.gz + + zip: + zip -ul9 zlib README ChangeLog Makefile Make????.??? Makefile.?? \ + descrip.mms *.[ch] + + tgz: + cd ..; tar cfz zlib/zlib.tgz zlib/README zlib/ChangeLog zlib/Makefile \ + zlib/Make????.??? zlib/Makefile.?? zlib/descrip.mms zlib/*.[ch] + + # DO NOT DELETE THIS LINE -- make depend depends on it. + + adler32.o: zlib.h zconf.h + compress.o: zlib.h zconf.h + crc32.o: crc32.h zlib.h zconf.h + deflate.o: deflate.h zutil.h zlib.h zconf.h + example.o: zlib.h zconf.h + gzio.o: zutil.h zlib.h zconf.h + inffast.o: zutil.h zlib.h zconf.h inftrees.h inflate.h inffast.h + inflate.o: zutil.h zlib.h zconf.h inftrees.h inflate.h inffast.h + infback.o: zutil.h zlib.h zconf.h inftrees.h inflate.h inffast.h + inftrees.o: zutil.h zlib.h zconf.h inftrees.h + minigzip.o: zlib.h zconf.h + trees.o: deflate.h zutil.h zlib.h zconf.h trees.h + uncompr.o: zlib.h zconf.h + zutil.o: zutil.h zlib.h zconf.h Index: llvm-test/Runtime/zlib/amiga/Makefile.sas diff -c /dev/null llvm-test/Runtime/zlib/amiga/Makefile.sas:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/amiga/Makefile.sas Mon Dec 6 15:19:40 2004 *************** *** 0 **** --- 1,65 ---- + # SMakefile for zlib + # Modified from the standard UNIX Makefile Copyright Jean-loup Gailly + # Osma Ahvenlampi + # Amiga, SAS/C 6.56 & Smake + + CC=sc + CFLAGS=OPT + #CFLAGS=OPT CPU=68030 + #CFLAGS=DEBUG=LINE + LDFLAGS=LIB z.lib + + SCOPTIONS=OPTSCHED OPTINLINE OPTALIAS OPTTIME OPTINLOCAL STRMERGE \ + NOICONS PARMS=BOTH NOSTACKCHECK UTILLIB NOVERSION ERRORREXX \ + DEF=POSTINC + + OBJS = adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o \ + zutil.o inflate.o infback.o inftrees.o inffast.o + + TEST_OBJS = example.o minigzip.o + + all: SCOPTIONS example minigzip + + check: test + test: all + example + echo hello world | minigzip | minigzip -d + + install: z.lib + copy clone zlib.h zconf.h INCLUDE: + copy clone z.lib LIB: + + z.lib: $(OBJS) + oml z.lib r $(OBJS) + + example: example.o z.lib + $(CC) $(CFLAGS) LINK TO $@ example.o $(LDFLAGS) + + minigzip: minigzip.o z.lib + $(CC) $(CFLAGS) LINK TO $@ minigzip.o $(LDFLAGS) + + mostlyclean: clean + clean: + -delete force quiet example minigzip *.o z.lib foo.gz *.lnk SCOPTIONS + + SCOPTIONS: Makefile.sas + copy to $@ Changes in directory llvm-test/Runtime/zlib/contrib/pascal: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/pascal added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:19 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:19 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/as400/ Message-ID: <200412062118.PAA21517@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/as400: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/as400 added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:19:55 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:19:55 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/README.contrib visual-basic.txt Message-ID: <200412062119.PAA21666@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib: README.contrib added (r1.1) visual-basic.txt added (r1.1) --- Log message: Addition of runtime libraries needed for testing. Namely, libpng and zlib return to the testsuite for Povray. --- Diffs of the changes: (+230 -0) Index: llvm-test/Runtime/zlib/contrib/README.contrib diff -c /dev/null llvm-test/Runtime/zlib/contrib/README.contrib:1.1 *** /dev/null Mon Dec 6 15:19:50 2004 --- llvm-test/Runtime/zlib/contrib/README.contrib Mon Dec 6 15:19:40 2004 *************** *** 0 **** --- 1,70 ---- + All files under this contrib directory are UNSUPPORTED. There were + provided by users of zlib and were not tested by the authors of zlib. + Use at your own risk. Please contact the authors of the contributions + for help about these, not the zlib authors. Thanks. + + + ada/ by Dmitriy Anisimkov + Support for Ada + See http://zlib-ada.sourceforge.net/ + + asm586/ + asm686/ by Brian Raiter + asm code for Pentium and PPro/PII, using the AT&T (GNU as) syntax + See http://www.muppetlabs.com/~breadbox/software/assembly.html + + blast/ by Mark Adler + Decompressor for output of PKWare Data Compression Library (DCL) + + delphi/ by Cosmin Truta + Support for Delphi and C++ Builder + + gzappend/ by Mark Adler + append to a gzip file -- illustrates the use of Z_BLOCK + + infback9/ by Mark Adler + Unsupported diffs to infback to decode the deflate64 format + + inflate86/ by Chris Anderson + Tuned x86 gcc asm code to replace inflate_fast() + + iostream/ by Kevin Ruland + A C++ I/O streams interface to the zlib gz* functions + + iostream2/ by Tyge L?vset + Another C++ I/O streams interface + + iostream3/ by Ludwig Schwardt + and Kevin Ruland + Yet another C++ I/O streams interface + + masm686/ by Dan Higdon + and Chuck Walbourn + asm code for Pentium Pro/PII, using the MASM syntax + + masmx86/ by Gilles Vollant + x86 asm code to replace longest_match() and inflate_fast(), + for Visual C++ and MASM + + minizip/ by Gilles Vollant + Mini zip and unzip based on zlib + See http://www.winimage.com/zLibDll/unzip.html + + pascal/ by Bob Dellaca et al. + Support for Pascal + + puff/ by Mark Adler + Small, low memory usage inflate. Also serves to provide an + unambiguous description of the deflate format. + + testzlib/ by Gilles Vollant + Example of the use of zlib + + untgz/ by "Pedro A. Aranda Guti\irrez" + A very simple tar.gz file extractor using zlib + + visual-basic.txt by Carlos Rios + How to use compress(), uncompress() and the gz* functions from VB + + vstudio/ by Gilles Vollant + Building zlib with Visual Studio .NET Index: llvm-test/Runtime/zlib/contrib/visual-basic.txt diff -c /dev/null llvm-test/Runtime/zlib/contrib/visual-basic.txt:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/contrib/visual-basic.txt Mon Dec 6 15:19:40 2004 *************** *** 0 **** --- 1,160 ---- + See below some functions declarations for Visual Basic. + + Frequently Asked Question: + + Q: Each time I use the compress function I get the -5 error (not enough + room in the output buffer). + + A: Make sure that the length of the compressed buffer is passed by + reference ("as any"), not by value ("as long"). Also check that + before the call of compress this length is equal to the total size of + the compressed buffer and not zero. + + + From: "Jon Caruana" + Subject: Re: How to port zlib declares to vb? + Date: Mon, 28 Oct 1996 18:33:03 -0600 + + Got the answer! (I haven't had time to check this but it's what I got, and + looks correct): + + He has the following routines working: + compress + uncompress + gzopen + gzwrite + gzread + gzclose + + Declares follow: (Quoted from Carlos Rios , in Vb4 form) + + #If Win16 Then 'Use Win16 calls. + Declare Function compress Lib "ZLIB.DLL" (ByVal compr As + String, comprLen As Any, ByVal buf As String, ByVal buflen + As Long) As Integer + Declare Function uncompress Lib "ZLIB.DLL" (ByVal uncompr + As String, uncomprLen As Any, ByVal compr As String, ByVal + lcompr As Long) As Integer + Declare Function gzopen Lib "ZLIB.DLL" (ByVal filePath As + String, ByVal mode As String) As Long + Declare Function gzread Lib "ZLIB.DLL" (ByVal file As + Long, ByVal uncompr As String, ByVal uncomprLen As Integer) + As Integer + Declare Function gzwrite Lib "ZLIB.DLL" (ByVal file As + Long, ByVal uncompr As String, ByVal uncomprLen As Integer) + As Integer + Declare Function gzclose Lib "ZLIB.DLL" (ByVal file As + Long) As Integer + #Else + Declare Function compress Lib "ZLIB32.DLL" + (ByVal compr As String, comprLen As Any, ByVal buf As + String, ByVal buflen As Long) As Integer + Declare Function uncompress Lib "ZLIB32.DLL" + (ByVal uncompr As String, uncomprLen As Any, ByVal compr As + String, ByVal lcompr As Long) As Long + Declare Function gzopen Lib "ZLIB32.DLL" + (ByVal file As String, ByVal mode As String) As Long + Declare Function gzread Lib "ZLIB32.DLL" + (ByVal file As Long, ByVal uncompr As String, ByVal + uncomprLen As Long) As Long + Declare Function gzwrite Lib "ZLIB32.DLL" + (ByVal file As Long, ByVal uncompr As String, ByVal + uncomprLen As Long) As Long + Declare Function gzclose Lib "ZLIB32.DLL" + (ByVal file As Long) As Long + #End If + + -Jon Caruana + jon-net at usa.net + Microsoft Sitebuilder Network Level 1 Member - HTML Writer's Guild Member + + + Here is another example from Michael that he + says conforms to the VB guidelines, and that solves the problem of not + knowing the uncompressed size by storing it at the end of the file: + + 'Calling the functions: + 'bracket meaning: [optional] {Range of possible values} + 'Call subCompressFile( [, , [level of compression {1..9}]]) + 'Call subUncompressFile() + + Option Explicit + Private lngpvtPcnSml As Long 'Stores value for 'lngPercentSmaller' + Private Const SUCCESS As Long = 0 + Private Const strFilExt As String = ".cpr" + Private Declare Function lngfncCpr Lib "zlib.dll" Alias "compress2" (ByRef + dest As Any, ByRef destLen As Any, ByRef src As Any, ByVal srcLen As Long, + ByVal level As Integer) As Long + Private Declare Function lngfncUcp Lib "zlib.dll" Alias "uncompress" (ByRef + dest As Any, ByRef destLen As Any, ByRef src As Any, ByVal srcLen As Long) + As Long + + Public Sub subCompressFile(ByVal strargOriFilPth As String, Optional ByVal + strargCprFilPth As String, Optional ByVal intLvl As Integer = 9) + Dim strCprPth As String + Dim lngOriSiz As Long + Dim lngCprSiz As Long + Dim bytaryOri() As Byte + Dim bytaryCpr() As Byte + lngOriSiz = FileLen(strargOriFilPth) + ReDim bytaryOri(lngOriSiz - 1) + Open strargOriFilPth For Binary Access Read As #1 + Get #1, , bytaryOri() + Close #1 + strCprPth = IIf(strargCprFilPth = "", strargOriFilPth, strargCprFilPth) + 'Select file path and name + strCprPth = strCprPth & IIf(Right(strCprPth, Len(strFilExt)) = + strFilExt, "", strFilExt) 'Add file extension if not exists + lngCprSiz = (lngOriSiz * 1.01) + 12 'Compression needs temporary a bit + more space then original file size + ReDim bytaryCpr(lngCprSiz - 1) + If lngfncCpr(bytaryCpr(0), lngCprSiz, bytaryOri(0), lngOriSiz, intLvl) = + SUCCESS Then + lngpvtPcnSml = (1# - (lngCprSiz / lngOriSiz)) * 100 + ReDim Preserve bytaryCpr(lngCprSiz - 1) + Open strCprPth For Binary Access Write As #1 + Put #1, , bytaryCpr() + Put #1, , lngOriSiz 'Add the the original size value to the end + (last 4 bytes) + Close #1 + Else + MsgBox "Compression error" + End If + Erase bytaryCpr + Erase bytaryOri + End Sub + + Public Sub subUncompressFile(ByVal strargFilPth As String) + Dim bytaryCpr() As Byte + Dim bytaryOri() As Byte + Dim lngOriSiz As Long + Dim lngCprSiz As Long + Dim strOriPth As String + lngCprSiz = FileLen(strargFilPth) + ReDim bytaryCpr(lngCprSiz - 1) + Open strargFilPth For Binary Access Read As #1 + Get #1, , bytaryCpr() + Close #1 + 'Read the original file size value: + lngOriSiz = bytaryCpr(lngCprSiz - 1) * (2 ^ 24) _ + + bytaryCpr(lngCprSiz - 2) * (2 ^ 16) _ + + bytaryCpr(lngCprSiz - 3) * (2 ^ 8) _ + + bytaryCpr(lngCprSiz - 4) + ReDim Preserve bytaryCpr(lngCprSiz - 5) 'Cut of the original size value + ReDim bytaryOri(lngOriSiz - 1) + If lngfncUcp(bytaryOri(0), lngOriSiz, bytaryCpr(0), lngCprSiz) = SUCCESS + Then + strOriPth = Left(strargFilPth, Len(strargFilPth) - Len(strFilExt)) + Open strOriPth For Binary Access Write As #1 + Put #1, , bytaryOri() + Close #1 + Else + MsgBox "Uncompression error" + End If + Erase bytaryCpr + Erase bytaryOri + End Sub + Public Property Get lngPercentSmaller() As Long + lngPercentSmaller = lngpvtPcnSml + End Property From criswell at cs.uiuc.edu Mon Dec 6 15:19:51 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:19:51 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/Makefile Message-ID: <200412062119.PAA21645@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime: Makefile added (r1.1) --- Log message: Addition of runtime libraries needed for testing. Namely, libpng and zlib return to the testsuite for Povray. --- Diffs of the changes: (+18 -0) Index: llvm-test/Runtime/Makefile diff -c /dev/null llvm-test/Runtime/Makefile:1.1 *** /dev/null Mon Dec 6 15:19:46 2004 --- llvm-test/Runtime/Makefile Mon Dec 6 15:19:36 2004 *************** *** 0 **** --- 1,18 ---- + ##===- projects/llvm-test/Makefile -------------------------*- Makefile -*-===## + # + # The LLVM Compiler Infrastructure + # + # This file was developed by the LLVM research group and is distributed under + # the University of Illinois Open Source License. See LICENSE.TXT for details. + # + ##===----------------------------------------------------------------------===## + # + # This recursively traverses the programs, building them as necessary. This + # makefile also implements 'make report TEST='. + # + ##===----------------------------------------------------------------------===## + + LEVEL = .. + DIRS = zlib libpng + + include $(LEVEL)/Makefile.common From criswell at cs.uiuc.edu Mon Dec 6 15:21:06 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:21:06 -0600 Subject: [llvm-commits] CVS: llvm-test/External/Povray/Makefile Message-ID: <200412062121.PAA21760@choi.cs.uiuc.edu> Changes in directory llvm-test/External/Povray: Makefile updated: 1.11 -> 1.12 --- Log message: Look for libpng and zlib bytecode libraries inside of the llvm-test tree. --- Diffs of the changes: (+2 -2) Index: llvm-test/External/Povray/Makefile diff -u llvm-test/External/Povray/Makefile:1.11 llvm-test/External/Povray/Makefile:1.12 --- llvm-test/External/Povray/Makefile:1.11 Mon Sep 6 23:05:22 2004 +++ llvm-test/External/Povray/Makefile Mon Dec 6 15:20:54 2004 @@ -7,8 +7,8 @@ SourceDir = $(POVRAY_ROOT)/source CPPFLAGS += -I$(POVRAY_ROOT)/source/unix -I$(BUILD_SRC_ROOT)/runtime/libpng -DPREFIX=\"$(BUILD_OBJ_DIR)\" -DSYSCONFDIR=\"$(POVRAY_ROOT)\" -DPOV_LIB_DIR=\"$(BUILD_OBJ_DIR)/lib\" -IOutput/src -UHAVE_LIBVGA -LIBS += -lpng -lz -lm -LDFLAGS += -L$(BUILD_OBJ_ROOT)/lib/$(CONFIGURATION) -lpng -lz -lm +LIBS += -L$(BUILD_OBJ_ROOT)/$(CONFIGURATION)/lib -lpng -lz -lm +LDFLAGS += -L$(BUILD_OBJ_ROOT)/$(CONFIGURATION)/lib -lpng -lz -lm RUN_OPTIONS = -I$(POVRAY_ROOT)/scenes/advanced/chess2.pov -L$(POVRAY_ROOT)/include -GA$<.junk -O- include $(LEVEL)/MultiSource/Makefile.multisrc From criswell at cs.uiuc.edu Mon Dec 6 15:18:19 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:19 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/msdos/ Message-ID: <200412062118.PAA21523@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/msdos: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/msdos added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/puff/ Message-ID: <200412062118.PAA21587@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/puff: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/puff added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/testzlib/ Message-ID: <200412062118.PAA21590@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/testzlib: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/testzlib added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:19 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:19 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/win32/ Message-ID: <200412062118.PAA21533@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/win32: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/win32 added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:19 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:19 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/ Message-ID: <200412062118.PAA21520@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:19 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:19 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/qnx/ Message-ID: <200412062118.PAA21530@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/qnx: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/qnx added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/inflate86/ Message-ID: <200412062118.PAA21563@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/inflate86: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/inflate86 added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/iostream3/ Message-ID: <200412062118.PAA21572@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/iostream3: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/iostream3 added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/vstudio/ Message-ID: <200412062118.PAA21596@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/vstudio: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/vstudio added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:19 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:19 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/old/ Message-ID: <200412062118.PAA21527@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/old: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/old added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:19:56 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:19:56 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/ChangeLog FAQ INDEX LICENSE.TXT Makefile Makefile.in Makefile.orig README adler32.c algorithm.txt compress.c configure crc32.c crc32.h deflate.c deflate.h example.c gzio.c infback.c inffast.c inffast.h inffixed.h inflate.c inflate.h inftrees.c inftrees.h minigzip.c trees.c trees.h uncompr.c zconf.h zconf.in.h zlib.3 zlib.h zutil.c zutil.h Message-ID: <200412062119.PAA21740@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib: ChangeLog added (r1.1) FAQ added (r1.1) INDEX added (r1.1) LICENSE.TXT added (r1.1) Makefile added (r1.1) Makefile.in added (r1.1) Makefile.orig added (r1.1) README added (r1.1) adler32.c added (r1.1) algorithm.txt added (r1.1) compress.c added (r1.1) configure added (r1.1) crc32.c added (r1.1) crc32.h added (r1.1) deflate.c added (r1.1) deflate.h added (r1.1) example.c added (r1.1) gzio.c added (r1.1) infback.c added (r1.1) inffast.c added (r1.1) inffast.h added (r1.1) inffixed.h added (r1.1) inflate.c added (r1.1) inflate.h added (r1.1) inftrees.c added (r1.1) inftrees.h added (r1.1) minigzip.c added (r1.1) trees.c added (r1.1) trees.h added (r1.1) uncompr.c added (r1.1) zconf.h added (r1.1) zconf.in.h added (r1.1) zlib.3 added (r1.1) zlib.h added (r1.1) zutil.c added (r1.1) zutil.h added (r1.1) --- Log message: Addition of runtime libraries needed for testing. Namely, libpng and zlib return to the testsuite for Povray. --- Diffs of the changes: (+13624 -0) Index: llvm-test/Runtime/zlib/ChangeLog diff -c /dev/null llvm-test/Runtime/zlib/ChangeLog:1.1 *** /dev/null Mon Dec 6 15:19:50 2004 --- llvm-test/Runtime/zlib/ChangeLog Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,727 ---- + + ChangeLog file for zlib + + Changes made by the LLVM Team (llvmdev at cs.uiuc.edu, 2/6/2004): + - Makefile was modified for building with the LLVM build system and tools. + - Version numbers were updated as described in the FAQ. + - LLVM LICENSE.TXT file was added describing licensing information. + + Changes in 1.2.1 (17 November 2003) + - Remove a tab in contrib/gzappend/gzappend.c + - Update some interfaces in contrib for new zlib functions + - Update zlib version number in some contrib entries + - Add Windows CE definition for ptrdiff_t in zutil.h [Mai, Truta] + - Support shared libraries on Hurd and KFreeBSD [Brown] + - Fix error in NO_DIVIDE option of adler32.c + + Changes in 1.2.0.8 (4 November 2003) + - Update version in contrib/delphi/ZLib.pas and contrib/pascal/zlibpas.pas + - Add experimental NO_DIVIDE #define in adler32.c + - Possibly faster on some processors (let me know if it is) + - Correct Z_BLOCK to not return on first inflate call if no wrap + - Fix strm->data_type on inflate() return to correctly indicate EOB + - Add deflatePrime() function for appending in the middle of a byte + - Add contrib/gzappend for an example of appending to a stream + - Update win32/DLL_FAQ.txt [Truta] + - Delete Turbo C comment in README [Truta] + - Improve some indentation in zconf.h [Truta] + - Fix infinite loop on bad input in configure script [Church] + - Fix gzeof() for concatenated gzip files [Johnson] + - Add example to contrib/visual-basic.txt [Michael B.] + - Add -p to mkdir's in Makefile.in [vda] + - Fix configure to properly detect presence or lack of printf functions + - Add AS400 support [Monnerat] + - Add a little Cygwin support [Wilson] + + Changes in 1.2.0.7 (21 September 2003) + - Correct some debug formats in contrib/infback9 + - Cast a type in a debug statement in trees.c + - Change search and replace delimiter in configure from % to # [Beebe] + - Update contrib/untgz to 0.2 with various fixes [Truta] + - Add build support for Amiga [Nikl] + - Remove some directories in old that have been updated to 1.2 + - Add dylib building for Mac OS X in configure and Makefile.in + - Remove old distribution stuff from Makefile + - Update README to point to DLL_FAQ.txt, and add comment on Mac OS X + - Update links in README + + Changes in 1.2.0.6 (13 September 2003) + - Minor FAQ updates + - Update contrib/minizip to 1.00 [Vollant] + - Remove test of gz functions in example.c when GZ_COMPRESS defined [Truta] + - Update POSTINC comment for 68060 [Nikl] + - Add contrib/infback9 with deflate64 decoding (unsupported) + - For MVS define NO_vsnprintf and undefine FAR [van Burik] + - Add pragma for fdopen on MVS [van Burik] + + Changes in 1.2.0.5 (8 September 2003) + - Add OF to inflateBackEnd() declaration in zlib.h + - Remember start when using gzdopen in the middle of a file + - Use internal off_t counters in gz* functions to properly handle seeks + - Perform more rigorous check for distance-too-far in inffast.c + - Add Z_BLOCK flush option to return from inflate at block boundary + - Set strm->data_type on return from inflate + - Indicate bits unused, if at block boundary, and if in last block + - Replace size_t with ptrdiff_t in crc32.c, and check for correct size + - Add condition so old NO_DEFLATE define still works for compatibility + - FAQ update regarding the Windows DLL [Truta] + - INDEX update: add qnx entry, remove aix entry [Truta] + - Install zlib.3 into mandir [Wilson] + - Move contrib/zlib_dll_FAQ.txt to win32/DLL_FAQ.txt; update [Truta] + - Adapt the zlib interface to the new DLL convention guidelines [Truta] + - Introduce ZLIB_WINAPI macro to allow the export of functions using + the WINAPI calling convention, for Visual Basic [Vollant, Truta] + - Update msdos and win32 scripts and makefiles [Truta] + - Export symbols by name, not by ordinal, in win32/zlib.def [Truta] + - Add contrib/ada [Anisimkov] + - Move asm files from contrib/vstudio/vc70_32 to contrib/asm386 [Truta] + - Rename contrib/asm386 to contrib/masmx86 [Truta, Vollant] + - Add contrib/masm686 [Truta] + - Fix offsets in contrib/inflate86 and contrib/masmx86/inffas32.asm + [Truta, Vollant] + - Update contrib/delphi; rename to contrib/pascal; add example [Truta] + - Remove contrib/delphi2; add a new contrib/delphi [Truta] + - Avoid inclusion of the nonstandard in contrib/iostream, + and fix some method prototypes [Truta] + - Fix the ZCR_SEED2 constant to avoid warnings in contrib/minizip + [Truta] + - Avoid the use of backslash (\) in contrib/minizip [Vollant] + - Fix file time handling in contrib/untgz; update makefiles [Truta] + - Update contrib/vstudio/vc70_32 to comply with the new DLL guidelines + [Vollant] + - Remove contrib/vstudio/vc15_16 [Vollant] + - Rename contrib/vstudio/vc70_32 to contrib/vstudio/vc7 [Truta] + - Update README.contrib [Truta] + - Invert the assignment order of match_head and s->prev[...] in + INSERT_STRING [Truta] + - Compare TOO_FAR with 32767 instead of 32768, to avoid 16-bit warnings + [Truta] + - Compare function pointers with 0, not with NULL or Z_NULL [Truta] + - Fix prototype of syncsearch in inflate.c [Truta] + - Introduce ASMINF macro to be enabled when using an ASM implementation + of inflate_fast [Truta] + - Change NO_DEFLATE to NO_GZCOMPRESS [Truta] + - Modify test_gzio in example.c to take a single file name as a + parameter [Truta] + - Exit the example.c program if gzopen fails [Truta] + - Add type casts around strlen in example.c [Truta] + - Remove casting to sizeof in minigzip.c; give a proper type + to the variable compared with SUFFIX_LEN [Truta] + - Update definitions of STDC and STDC99 in zconf.h [Truta] + - Synchronize zconf.h with the new Windows DLL interface [Truta] + - Use SYS16BIT instead of __32BIT__ to distinguish between + 16- and 32-bit platforms [Truta] + - Use far memory allocators in small 16-bit memory models for + Turbo C [Truta] + - Add info about the use of ASMV, ASMINF and ZLIB_WINAPI in + zlibCompileFlags [Truta] + - Cygwin has vsnprintf [Wilson] + - In Windows16, OS_CODE is 0, as in MSDOS [Truta] + - In Cygwin, OS_CODE is 3 (Unix), not 11 (Windows32) [Wilson] + + Changes in 1.2.0.4 (10 August 2003) + - Minor FAQ updates + - Be more strict when checking inflateInit2's windowBits parameter + - Change NO_GUNZIP compile option to NO_GZIP to cover deflate as well + - Add gzip wrapper option to deflateInit2 using windowBits + - Add updated QNX rule in configure and qnx directory [Bonnefoy] + - Make inflate distance-too-far checks more rigorous + - Clean up FAR usage in inflate + - Add casting to sizeof() in gzio.c and minigzip.c + + Changes in 1.2.0.3 (19 July 2003) + - Fix silly error in gzungetc() implementation [Vollant] + - Update contrib/minizip and contrib/vstudio [Vollant] + - Fix printf format in example.c + - Correct cdecl support in zconf.in.h [Anisimkov] + - Minor FAQ updates + + Changes in 1.2.0.2 (13 July 2003) + - Add ZLIB_VERNUM in zlib.h for numerical preprocessor comparisons + - Attempt to avoid warnings in crc32.c for pointer-int conversion + - Add AIX to configure, remove aix directory [Bakker] + - Add some casts to minigzip.c + - Improve checking after insecure sprintf() or vsprintf() calls + - Remove #elif's from crc32.c + - Change leave label to inf_leave in inflate.c and infback.c to avoid + library conflicts + - Remove inflate gzip decoding by default--only enable gzip decoding by + special request for stricter backward compatibility + - Add zlibCompileFlags() function to return compilation information + - More typecasting in deflate.c to avoid warnings + - Remove leading underscore from _Capital #defines [Truta] + - Fix configure to link shared library when testing + - Add some Windows CE target adjustments [Mai] + - Remove #define ZLIB_DLL in zconf.h [Vollant] + - Add zlib.3 [Rodgers] + - Update RFC URL in deflate.c and algorithm.txt [Mai] + - Add zlib_dll_FAQ.txt to contrib [Truta] + - Add UL to some constants [Truta] + - Update minizip and vstudio [Vollant] + - Remove vestigial NEED_DUMMY_RETURN from zconf.in.h + - Expand use of NO_DUMMY_DECL to avoid all dummy structures + - Added iostream3 to contrib [Schwardt] + - Replace rewind() with fseek() for WinCE [Truta] + - Improve setting of zlib format compression level flags + - Report 0 for huffman and rle strategies and for level == 0 or 1 + - Report 2 only for level == 6 + - Only deal with 64K limit when necessary at compile time [Truta] + - Allow TOO_FAR check to be turned off at compile time [Truta] + - Add gzclearerr() function [Souza] + - Add gzungetc() function + + Changes in 1.2.0.1 (17 March 2003) + - Add Z_RLE strategy for run-length encoding [Truta] + - When Z_RLE requested, restrict matches to distance one + - Update zlib.h, minigzip.c, gzopen(), gzdopen() for Z_RLE + - Correct FASTEST compilation to allow level == 0 + - Clean up what gets compiled for FASTEST + - Incorporate changes to zconf.in.h [Vollant] + - Refine detection of Turbo C need for dummy returns + - Refine ZLIB_DLL compilation + - Include additional header file on VMS for off_t typedef + - Try to use _vsnprintf where it supplants vsprintf [Vollant] + - Add some casts in inffast.c + - Enchance comments in zlib.h on what happens if gzprintf() tries to + write more than 4095 bytes before compression + - Remove unused state from inflateBackEnd() + - Remove exit(0) from minigzip.c, example.c + - Get rid of all those darn tabs + - Add "check" target to Makefile.in that does the same thing as "test" + - Add "mostlyclean" and "maintainer-clean" targets to Makefile.in + - Update contrib/inflate86 [Anderson] + - Update contrib/testzlib, contrib/vstudio, contrib/minizip [Vollant] + - Add msdos and win32 directories with makefiles [Truta] + - More additions and improvements to the FAQ + + Changes in 1.2.0 (9 March 2003) + - New and improved inflate code + - About 20% faster + - Does not allocate 32K window unless and until needed + - Automatically detects and decompresses gzip streams + - Raw inflate no longer needs an extra dummy byte at end + - Added inflateBack functions using a callback interface--even faster + than inflate, useful for file utilities (gzip, zip) + - Added inflateCopy() function to record state for random access on + externally generated deflate streams (e.g. in gzip files) + - More readable code (I hope) + - New and improved crc32() + - About 50% faster, thanks to suggestions from Rodney Brown + - Add deflateBound() and compressBound() functions + - Fix memory leak in deflateInit2() + - Permit setting dictionary for raw deflate (for parallel deflate) + - Fix const declaration for gzwrite() + - Check for some malloc() failures in gzio.c + - Fix bug in gzopen() on single-byte file 0x1f + - Fix bug in gzread() on concatenated file with 0x1f at end of buffer + and next buffer doesn't start with 0x8b + - Fix uncompress() to return Z_DATA_ERROR on truncated input + - Free memory at end of example.c + - Remove MAX #define in trees.c (conflicted with some libraries) + - Fix static const's in deflate.c, gzio.c, and zutil.[ch] + - Declare malloc() and free() in gzio.c if STDC not defined + - Use malloc() instead of calloc() in zutil.c if int big enough + - Define STDC for AIX + - Add aix/ with approach for compiling shared library on AIX + - Add HP-UX support for shared libraries in configure + - Add OpenUNIX support for shared libraries in configure + - Use $cc instead of gcc to build shared library + - Make prefix directory if needed when installing + - Correct Macintosh avoidance of typedef Byte in zconf.h + - Correct Turbo C memory allocation when under Linux + - Use libz.a instead of -lz in Makefile (assure use of compiled library) + - Update configure to check for snprintf or vsnprintf functions and their + return value, warn during make if using an insecure function + - Fix configure problem with compile-time knowledge of HAVE_UNISTD_H that + is lost when library is used--resolution is to build new zconf.h + - Documentation improvements (in zlib.h): + - Document raw deflate and inflate + - Update RFCs URL + - Point out that zlib and gzip formats are different + - Note that Z_BUF_ERROR is not fatal + - Document string limit for gzprintf() and possible buffer overflow + - Note requirement on avail_out when flushing + - Note permitted values of flush parameter of inflate() + - Add some FAQs (and even answers) to the FAQ + - Add contrib/inflate86/ for x86 faster inflate + - Add contrib/blast/ for PKWare Data Compression Library decompression + - Add contrib/puff/ simple inflate for deflate format description + + Changes in 1.1.4 (11 March 2002) + - ZFREE was repeated on same allocation on some error conditions. + This creates a security problem described in + http://www.zlib.org/advisory-2002-03-11.txt + - Returned incorrect error (Z_MEM_ERROR) on some invalid data + - Avoid accesses before window for invalid distances with inflate window + less than 32K. + - force windowBits > 8 to avoid a bug in the encoder for a window size + of 256 bytes. (A complete fix will be available in 1.1.5). + + Changes in 1.1.3 (9 July 1998) + - fix "an inflate input buffer bug that shows up on rare but persistent + occasions" (Mark) + - fix gzread and gztell for concatenated .gz files (Didier Le Botlan) + - fix gzseek(..., SEEK_SET) in write mode + - fix crc check after a gzeek (Frank Faubert) + - fix miniunzip when the last entry in a zip file is itself a zip file + (J Lillge) + - add contrib/asm586 and contrib/asm686 (Brian Raiter) + See http://www.muppetlabs.com/~breadbox/software/assembly.html + - add support for Delphi 3 in contrib/delphi (Bob Dellaca) + - add support for C++Builder 3 and Delphi 3 in contrib/delphi2 (Davide Moretti) + - do not exit prematurely in untgz if 0 at start of block (Magnus Holmgren) + - use macro EXTERN instead of extern to support DLL for BeOS (Sander Stoks) + - added a FAQ file + + - Support gzdopen on Mac with Metrowerks (Jason Linhart) + - Do not redefine Byte on Mac (Brad Pettit & Jason Linhart) + - define SEEK_END too if SEEK_SET is not defined (Albert Chin-A-Young) + - avoid some warnings with Borland C (Tom Tanner) + - fix a problem in contrib/minizip/zip.c for 16-bit MSDOS (Gilles Vollant) + - emulate utime() for WIN32 in contrib/untgz (Gilles Vollant) + - allow several arguments to configure (Tim Mooney, Frodo Looijaard) + - use libdir and includedir in Makefile.in (Tim Mooney) + - support shared libraries on OSF1 V4 (Tim Mooney) + - remove so_locations in "make clean" (Tim Mooney) + - fix maketree.c compilation error (Glenn, Mark) + - Python interface to zlib now in Python 1.5 (Jeremy Hylton) + - new Makefile.riscos (Rich Walker) + - initialize static descriptors in trees.c for embedded targets (Nick Smith) + - use "foo-gz" in example.c for RISCOS and VMS (Nick Smith) + - add the OS/2 files in Makefile.in too (Andrew Zabolotny) + - fix fdopen and halloc macros for Microsoft C 6.0 (Tom Lane) + - fix maketree.c to allow clean compilation of inffixed.h (Mark) + - fix parameter check in deflateCopy (Gunther Nikl) + - cleanup trees.c, use compressed_len only in debug mode (Christian Spieler) + - Many portability patches by Christian Spieler: + . zutil.c, zutil.h: added "const" for zmem* + . Make_vms.com: fixed some typos + . Make_vms.com: msdos/Makefile.*: removed zutil.h from some dependency lists + . msdos/Makefile.msc: remove "default rtl link library" info from obj files + . msdos/Makefile.*: use model-dependent name for the built zlib library + . msdos/Makefile.emx, nt/Makefile.emx, nt/Makefile.gcc: + new makefiles, for emx (DOS/OS2), emx&rsxnt and mingw32 (Windows 9x / NT) + - use define instead of typedef for Bytef also for MSC small/medium (Tom Lane) + - replace __far with _far for better portability (Christian Spieler, Tom Lane) + - fix test for errno.h in configure (Tim Newsham) + + Changes in 1.1.2 (19 March 98) + - added contrib/minzip, mini zip and unzip based on zlib (Gilles Vollant) + See http://www.winimage.com/zLibDll/unzip.html + - preinitialize the inflate tables for fixed codes, to make the code + completely thread safe (Mark) + - some simplifications and slight speed-up to the inflate code (Mark) + - fix gzeof on non-compressed files (Allan Schrum) + - add -std1 option in configure for OSF1 to fix gzprintf (Martin Mokrejs) + - use default value of 4K for Z_BUFSIZE for 16-bit MSDOS (Tim Wegner + Glenn) + - added os2/Makefile.def and os2/zlib.def (Andrew Zabolotny) + - add shared lib support for UNIX_SV4.2MP (MATSUURA Takanori) + - do not wrap extern "C" around system includes (Tom Lane) + - mention zlib binding for TCL in README (Andreas Kupries) + - added amiga/Makefile.pup for Amiga powerUP SAS/C PPC (Andreas Kleinert) + - allow "make install prefix=..." even after configure (Glenn Randers-Pehrson) + - allow "configure --prefix $HOME" (Tim Mooney) + - remove warnings in example.c and gzio.c (Glenn Randers-Pehrson) + - move Makefile.sas to amiga/Makefile.sas + + Changes in 1.1.1 (27 Feb 98) + - fix macros _tr_tally_* in deflate.h for debug mode (Glenn Randers-Pehrson) + - remove block truncation heuristic which had very marginal effect for zlib + (smaller lit_bufsize than in gzip 1.2.4) and degraded a little the + compression ratio on some files. This also allows inlining _tr_tally for + matches in deflate_slow. + - added msdos/Makefile.w32 for WIN32 Microsoft Visual C++ (Bob Frazier) + + Changes in 1.1.0 (24 Feb 98) + - do not return STREAM_END prematurely in inflate (John Bowler) + - revert to the zlib 1.0.8 inflate to avoid the gcc 2.8.0 bug (Jeremy Buhler) + - compile with -DFASTEST to get compression code optimized for speed only + - in minigzip, try mmap'ing the input file first (Miguel Albrecht) + - increase size of I/O buffers in minigzip.c and gzio.c (not a big gain + on Sun but significant on HP) + + - add a pointer to experimental unzip library in README (Gilles Vollant) + - initialize variable gcc in configure (Chris Herborth) + + Changes in 1.0.9 (17 Feb 1998) + - added gzputs and gzgets functions + - do not clear eof flag in gzseek (Mark Diekhans) + - fix gzseek for files in transparent mode (Mark Diekhans) + - do not assume that vsprintf returns the number of bytes written (Jens Krinke) + - replace EXPORT with ZEXPORT to avoid conflict with other programs + - added compress2 in zconf.h, zlib.def, zlib.dnt + - new asm code from Gilles Vollant in contrib/asm386 + - simplify the inflate code (Mark): + . Replace ZALLOC's in huft_build() with single ZALLOC in inflate_blocks_new() + . ZALLOC the length list in inflate_trees_fixed() instead of using stack + . ZALLOC the value area for huft_build() instead of using stack + . Simplify Z_FINISH check in inflate() + + - Avoid gcc 2.8.0 comparison bug a little differently than zlib 1.0.8 + - in inftrees.c, avoid cc -O bug on HP (Farshid Elahi) + - in zconf.h move the ZLIB_DLL stuff earlier to avoid problems with + the declaration of FAR (Gilles VOllant) + - install libz.so* with mode 755 (executable) instead of 644 (Marc Lehmann) + - read_buf buf parameter of type Bytef* instead of charf* + - zmemcpy parameters are of type Bytef*, not charf* (Joseph Strout) + - do not redeclare unlink in minigzip.c for WIN32 (John Bowler) + - fix check for presence of directories in "make install" (Ian Willis) + + Changes in 1.0.8 (27 Jan 1998) + - fixed offsets in contrib/asm386/gvmat32.asm (Gilles Vollant) + - fix gzgetc and gzputc for big endian systems (Markus Oberhumer) + - added compress2() to allow setting the compression level + - include sys/types.h to get off_t on some systems (Marc Lehmann & QingLong) + - use constant arrays for the static trees in trees.c instead of computing + them at run time (thanks to Ken Raeburn for this suggestion). To create + trees.h, compile with GEN_TREES_H and run "make test". + - check return code of example in "make test" and display result + - pass minigzip command line options to file_compress + - simplifying code of inflateSync to avoid gcc 2.8 bug + + - support CC="gcc -Wall" in configure -s (QingLong) + - avoid a flush caused by ftell in gzopen for write mode (Ken Raeburn) + - fix test for shared library support to avoid compiler warnings + - zlib.lib -> zlib.dll in msdos/zlib.rc (Gilles Vollant) + - check for TARGET_OS_MAC in addition to MACOS (Brad Pettit) + - do not use fdopen for Metrowerks on Mac (Brad Pettit)) + - add checks for gzputc and gzputc in example.c + - avoid warnings in gzio.c and deflate.c (Andreas Kleinert) + - use const for the CRC table (Ken Raeburn) + - fixed "make uninstall" for shared libraries + - use Tracev instead of Trace in infblock.c + - in example.c use correct compressed length for test_sync + - suppress +vnocompatwarnings in configure for HPUX (not always supported) + + Changes in 1.0.7 (20 Jan 1998) + - fix gzseek which was broken in write mode + - return error for gzseek to negative absolute position + - fix configure for Linux (Chun-Chung Chen) + - increase stack space for MSC (Tim Wegner) + - get_crc_table and inflateSyncPoint are EXPORTed (Gilles Vollant) + - define EXPORTVA for gzprintf (Gilles Vollant) + - added man page zlib.3 (Rick Rodgers) + - for contrib/untgz, fix makedir() and improve Makefile + + - check gzseek in write mode in example.c + - allocate extra buffer for seeks only if gzseek is actually called + - avoid signed/unsigned comparisons (Tim Wegner, Gilles Vollant) + - add inflateSyncPoint in zconf.h + - fix list of exported functions in nt/zlib.dnt and mdsos/zlib.def + + Changes in 1.0.6 (19 Jan 1998) + - add functions gzprintf, gzputc, gzgetc, gztell, gzeof, gzseek, gzrewind and + gzsetparams (thanks to Roland Giersig and Kevin Ruland for some of this code) + - Fix a deflate bug occuring only with compression level 0 (thanks to + Andy Buckler for finding this one). + - In minigzip, pass transparently also the first byte for .Z files. + - return Z_BUF_ERROR instead of Z_OK if output buffer full in uncompress() + - check Z_FINISH in inflate (thanks to Marc Schluper) + - Implement deflateCopy (thanks to Adam Costello) + - make static libraries by default in configure, add --shared option. + - move MSDOS or Windows specific files to directory msdos + - suppress the notion of partial flush to simplify the interface + (but the symbol Z_PARTIAL_FLUSH is kept for compatibility with 1.0.4) + - suppress history buffer provided by application to simplify the interface + (this feature was not implemented anyway in 1.0.4) + - next_in and avail_in must be initialized before calling inflateInit or + inflateInit2 + - add EXPORT in all exported functions (for Windows DLL) + - added Makefile.nt (thanks to Stephen Williams) + - added the unsupported "contrib" directory: + contrib/asm386/ by Gilles Vollant + 386 asm code replacing longest_match(). + contrib/iostream/ by Kevin Ruland + A C++ I/O streams interface to the zlib gz* functions + contrib/iostream2/ by Tyge L?vset + Another C++ I/O streams interface + contrib/untgz/ by "Pedro A. Aranda Guti\irrez" + A very simple tar.gz file extractor using zlib + contrib/visual-basic.txt by Carlos Rios + How to use compress(), uncompress() and the gz* functions from VB. + - pass params -f (filtered data), -h (huffman only), -1 to -9 (compression + level) in minigzip (thanks to Tom Lane) + + - use const for rommable constants in deflate + - added test for gzseek and gztell in example.c + - add undocumented function inflateSyncPoint() (hack for Paul Mackerras) + - add undocumented function zError to convert error code to string + (for Tim Smithers) + - Allow compilation of gzio with -DNO_DEFLATE to avoid the compression code. + - Use default memcpy for Symantec MSDOS compiler. + - Add EXPORT keyword for check_func (needed for Windows DLL) + - add current directory to LD_LIBRARY_PATH for "make test" + - create also a link for libz.so.1 + - added support for FUJITSU UXP/DS (thanks to Toshiaki Nomura) + - use $(SHAREDLIB) instead of libz.so in Makefile.in (for HPUX) + - added -soname for Linux in configure (Chun-Chung Chen, + - assign numbers to the exported functions in zlib.def (for Windows DLL) + - add advice in zlib.h for best usage of deflateSetDictionary + - work around compiler bug on Atari (cast Z_NULL in call of s->checkfn) + - allow compilation with ANSI keywords only enabled for TurboC in large model + - avoid "versionString"[0] (Borland bug) + - add NEED_DUMMY_RETURN for Borland + - use variable z_verbose for tracing in debug mode (L. Peter Deutsch). + - allow compilation with CC + - defined STDC for OS/2 (David Charlap) + - limit external names to 8 chars for MVS (Thomas Lund) + - in minigzip.c, use static buffers only for 16-bit systems + - fix suffix check for "minigzip -d foo.gz" + - do not return an error for the 2nd of two consecutive gzflush() (Felix Lee) + - use _fdopen instead of fdopen for MSC >= 6.0 (Thomas Fanslau) + - added makelcc.bat for lcc-win32 (Tom St Denis) + - in Makefile.dj2, use copy and del instead of install and rm (Frank Donahoe) + - Avoid expanded $Id: ChangeLog,v 1.1 2004/12/06 21:19:39 criswell Exp $. Use "rcs -kb" or "cvs admin -kb" to avoid Id expansion. + - check for unistd.h in configure (for off_t) + - remove useless check parameter in inflate_blocks_free + - avoid useless assignment of s->check to itself in inflate_blocks_new + - do not flush twice in gzclose (thanks to Ken Raeburn) + - rename FOPEN as F_OPEN to avoid clash with /usr/include/sys/file.h + - use NO_ERRNO_H instead of enumeration of operating systems with errno.h + - work around buggy fclose on pipes for HP/UX + - support zlib DLL with BORLAND C++ 5.0 (thanks to Glenn Randers-Pehrson) + - fix configure if CC is already equal to gcc + + Changes in 1.0.5 (3 Jan 98) + - Fix inflate to terminate gracefully when fed corrupted or invalid data + - Use const for rommable constants in inflate + - Eliminate memory leaks on error conditions in inflate + - Removed some vestigial code in inflate + - Update web address in README + + Changes in 1.0.4 (24 Jul 96) + - In very rare conditions, deflate(s, Z_FINISH) could fail to produce an EOF + bit, so the decompressor could decompress all the correct data but went + on to attempt decompressing extra garbage data. This affected minigzip too. + - zlibVersion and gzerror return const char* (needed for DLL) + - port to RISCOS (no fdopen, no multiple dots, no unlink, no fileno) + - use z_error only for DEBUG (avoid problem with DLLs) + + Changes in 1.0.3 (2 Jul 96) + - use z_streamp instead of z_stream *, which is now a far pointer in MSDOS + small and medium models; this makes the library incompatible with previous + versions for these models. (No effect in large model or on other systems.) + - return OK instead of BUF_ERROR if previous deflate call returned with + avail_out as zero but there is nothing to do + - added memcmp for non STDC compilers + - define NO_DUMMY_DECL for more Mac compilers (.h files merged incorrectly) + - define __32BIT__ if __386__ or i386 is defined (pb. with Watcom and SCO) + - better check for 16-bit mode MSC (avoids problem with Symantec) + + Changes in 1.0.2 (23 May 96) + - added Windows DLL support + - added a function zlibVersion (for the DLL support) + - fixed declarations using Bytef in infutil.c (pb with MSDOS medium model) + - Bytef is define's instead of typedef'd only for Borland C + - avoid reading uninitialized memory in example.c + - mention in README that the zlib format is now RFC1950 + - updated Makefile.dj2 + - added algorithm.doc + + Changes in 1.0.1 (20 May 96) [1.0 skipped to avoid confusion] + - fix array overlay in deflate.c which sometimes caused bad compressed data + - fix inflate bug with empty stored block + - fix MSDOS medium model which was broken in 0.99 + - fix deflateParams() which could generated bad compressed data. + - Bytef is define'd instead of typedef'ed (work around Borland bug) + - added an INDEX file + - new makefiles for DJGPP (Makefile.dj2), 32-bit Borland (Makefile.b32), + Watcom (Makefile.wat), Amiga SAS/C (Makefile.sas) + - speed up adler32 for modern machines without auto-increment + - added -ansi for IRIX in configure + - static_init_done in trees.c is an int + - define unlink as delete for VMS + - fix configure for QNX + - add configure branch for SCO and HPUX + - avoid many warnings (unused variables, dead assignments, etc...) + - no fdopen for BeOS + - fix the Watcom fix for 32 bit mode (define FAR as empty) + - removed redefinition of Byte for MKWERKS + - work around an MWKERKS bug (incorrect merge of all .h files) + + Changes in 0.99 (27 Jan 96) + - allow preset dictionary shared between compressor and decompressor + - allow compression level 0 (no compression) + - add deflateParams in zlib.h: allow dynamic change of compression level + and compression strategy. + - test large buffers and deflateParams in example.c + - add optional "configure" to build zlib as a shared library + - suppress Makefile.qnx, use configure instead + - fixed deflate for 64-bit systems (detected on Cray) + - fixed inflate_blocks for 64-bit systems (detected on Alpha) + - declare Z_DEFLATED in zlib.h (possible parameter for deflateInit2) + - always return Z_BUF_ERROR when deflate() has nothing to do + - deflateInit and inflateInit are now macros to allow version checking + - prefix all global functions and types with z_ with -DZ_PREFIX + - make falloc completely reentrant (inftrees.c) + - fixed very unlikely race condition in ct_static_init + - free in reverse order of allocation to help memory manager + - use zlib-1.0/* instead of zlib/* inside the tar.gz + - make zlib warning-free with "gcc -O3 -Wall -Wwrite-strings -Wpointer-arith + -Wconversion -Wstrict-prototypes -Wmissing-prototypes" + - allow gzread on concatenated .gz files + - deflateEnd now returns Z_DATA_ERROR if it was premature + - deflate is finally (?) fully deterministic (no matches beyond end of input) + - Document Z_SYNC_FLUSH + - add uninstall in Makefile + - Check for __cpluplus in zlib.h + - Better test in ct_align for partial flush + - avoid harmless warnings for Borland C++ + - initialize hash_head in deflate.c + - avoid warning on fdopen (gzio.c) for HP cc -Aa + - include stdlib.h for STDC compilers + - include errno.h for Cray + - ignore error if ranlib doesn't exist + - call ranlib twice for NeXTSTEP + - use exec_prefix instead of prefix for libz.a + - renamed ct_* as _tr_* to avoid conflict with applications + - clear z->msg in inflateInit2 before any error return + - initialize opaque in example.c, gzio.c, deflate.c and inflate.c + - fixed typo in zconf.h (_GNUC__ => __GNUC__) + - check for WIN32 in zconf.h and zutil.c (avoid farmalloc in 32-bit mode) + - fix typo in Make_vms.com (f$trnlnm -> f$getsyi) + - in fcalloc, normalize pointer if size > 65520 bytes + - don't use special fcalloc for 32 bit Borland C++ + - use STDC instead of __GO32__ to avoid redeclaring exit, calloc, etc... + - use Z_BINARY instead of BINARY + - document that gzclose after gzdopen will close the file + - allow "a" as mode in gzopen. + - fix error checking in gzread + - allow skipping .gz extra-field on pipes + - added reference to Perl interface in README + - put the crc table in FAR data (I dislike more and more the medium model :) + - added get_crc_table + - added a dimension to all arrays (Borland C can't count). + - workaround Borland C bug in declaration of inflate_codes_new & inflate_fast + - guard against multiple inclusion of *.h (for precompiled header on Mac) + - Watcom C pretends to be Microsoft C small model even in 32 bit mode. + - don't use unsized arrays to avoid silly warnings by Visual C++: + warning C4746: 'inflate_mask' : unsized array treated as '__far' + (what's wrong with far data in far model?). + - define enum out of inflate_blocks_state to allow compilation with C++ + + Changes in 0.95 (16 Aug 95) + - fix MSDOS small and medium model (now easier to adapt to any compiler) + - inlined send_bits + - fix the final (:-) bug for deflate with flush (output was correct but + not completely flushed in rare occasions). + - default window size is same for compression and decompression + (it's now sufficient to set MAX_WBITS in zconf.h). + - voidp -> voidpf and voidnp -> voidp (for consistency with other + typedefs and because voidnp was not near in large model). + + Changes in 0.94 (13 Aug 95) + - support MSDOS medium model + - fix deflate with flush (could sometimes generate bad output) + - fix deflateReset (zlib header was incorrectly suppressed) + - added support for VMS + - allow a compression level in gzopen() + - gzflush now calls fflush + - For deflate with flush, flush even if no more input is provided. + - rename libgz.a as libz.a + - avoid complex expression in infcodes.c triggering Turbo C bug + - work around a problem with gcc on Alpha (in INSERT_STRING) + - don't use inline functions (problem with some gcc versions) + - allow renaming of Byte, uInt, etc... with #define. + - avoid warning about (unused) pointer before start of array in deflate.c + - avoid various warnings in gzio.c, example.c, infblock.c, adler32.c, zutil.c + - avoid reserved word 'new' in trees.c + + Changes in 0.93 (25 June 95) + - temporarily disable inline functions + - make deflate deterministic + - give enough lookahead for PARTIAL_FLUSH + - Set binary mode for stdin/stdout in minigzip.c for OS/2 + - don't even use signed char in inflate (not portable enough) + - fix inflate memory leak for segmented architectures + + Changes in 0.92 (3 May 95) + - don't assume that char is signed (problem on SGI) + - Clear bit buffer when starting a stored block + - no memcpy on Pyramid + - suppressed inftest.c + - optimized fill_window, put longest_match inline for gcc + - optimized inflate on stored blocks. + - untabify all sources to simplify patches + + Changes in 0.91 (2 May 95) + - Default MEM_LEVEL is 8 (not 9 for Unix) as documented in zlib.h + - Document the memory requirements in zconf.h + - added "make install" + - fix sync search logic in inflateSync + - deflate(Z_FULL_FLUSH) now works even if output buffer too short + - after inflateSync, don't scare people with just "lo world" + - added support for DJGPP + + Changes in 0.9 (1 May 95) + - don't assume that zalloc clears the allocated memory (the TurboC bug + was Mark's bug after all :) + - let again gzread copy uncompressed data unchanged (was working in 0.71) + - deflate(Z_FULL_FLUSH), inflateReset and inflateSync are now fully implemented + - added a test of inflateSync in example.c + - moved MAX_WBITS to zconf.h because users might want to change that. + - document explicitly that zalloc(64K) on MSDOS must return a normalized + pointer (zero offset) + - added Makefiles for Microsoft C, Turbo C, Borland C++ + - faster crc32() + + Changes in 0.8 (29 April 95) + - added fast inflate (inffast.c) + - deflate(Z_FINISH) now returns Z_STREAM_END when done. Warning: this + is incompatible with previous versions of zlib which returned Z_OK. + - work around a TurboC compiler bug (bad code for b << 0, see infutil.h) + (actually that was not a compiler bug, see 0.81 above) + - gzread no longer reads one extra byte in certain cases + - In gzio destroy(), don't reference a freed structure + - avoid many warnings for MSDOS + - avoid the ERROR symbol which is used by MS Windows + + Changes in 0.71 (14 April 95) + - Fixed more MSDOS compilation problems :( There is still a bug with + TurboC large model. + + Changes in 0.7 (14 April 95) + - Added full inflate support. + - Simplified the crc32() interface. The pre- and post-conditioning + (one's complement) is now done inside crc32(). WARNING: this is + incompatible with previous versions; see zlib.h for the new usage. + + Changes in 0.61 (12 April 95) + - workaround for a bug in TurboC. example and minigzip now work on MSDOS. + + Changes in 0.6 (11 April 95) + - added minigzip.c + - added gzdopen to reopen a file descriptor as gzFile + - added transparent reading of non-gziped files in gzread. + - fixed bug in gzread (don't read crc as data) + - fixed bug in destroy (gzio.c) (don't return Z_STREAM_END for gzclose). + - don't allocate big arrays in the stack (for MSDOS) + - fix some MSDOS compilation problems + + Changes in 0.5: + - do real compression in deflate.c. Z_PARTIAL_FLUSH is supported but + not yet Z_FULL_FLUSH. + - support decompression but only in a single step (forced Z_FINISH) + - added opaque object for zalloc and zfree. + - added deflateReset and inflateReset + - added a variable zlib_version for consistency checking. + - renamed the 'filter' parameter of deflateInit2 as 'strategy'. + Added Z_FILTERED and Z_HUFFMAN_ONLY constants. + + Changes in 0.4: + - avoid "zip" everywhere, use zlib instead of ziplib. + - suppress Z_BLOCK_FLUSH, interpret Z_PARTIAL_FLUSH as block flush + if compression method == 8. + - added adler32 and crc32 + - renamed deflateOptions as deflateInit2, call one or the other but not both + - added the method parameter for deflateInit2. + - added inflateInit2 + - simplied considerably deflateInit and inflateInit by not supporting + user-provided history buffer. This is supported only in deflateInit2 + and inflateInit2. + + Changes in 0.3: + - prefix all macro names with Z_ + - use Z_FINISH instead of deflateEnd to finish compression. + - added Z_HUFFMAN_ONLY + - added gzerror() Index: llvm-test/Runtime/zlib/FAQ diff -c /dev/null llvm-test/Runtime/zlib/FAQ:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/FAQ Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,315 ---- + + Frequently Asked Questions about zlib + + + If your question is not there, please check the zlib home page + http://www.zlib.org which may have more recent information. + The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html + + + 1. Is zlib Y2K-compliant? + + Yes. zlib doesn't handle dates. + + 2. Where can I get a Windows DLL version? + + The zlib sources can be compiled without change to produce a DLL. + See the file win32/DLL_FAQ.txt in the zlib distribution. + Pointers to the precompiled DLL are found in the zlib web site at + http://www.zlib.org. + + 3. Where can I get a Visual Basic interface to zlib? + + See + * http://www.winimage.com/zLibDll/ + * http://www.dogma.net/markn/articles/zlibtool/zlibtool.htm + * contrib/visual-basic.txt in the zlib distribution + + 4. compress() returns Z_BUF_ERROR + + Make sure that before the call of compress, the length of the compressed + buffer is equal to the total size of the compressed buffer and not + zero. For Visual Basic, check that this parameter is passed by reference + ("as any"), not by value ("as long"). + + 5. deflate() or inflate() returns Z_BUF_ERROR + + Before making the call, make sure that avail_in and avail_out are not + zero. When setting the parameter flush equal to Z_FINISH, also make sure + that avail_out is big enough to allow processing all pending input. + Note that a Z_BUF_ERROR is not fatal--another call to deflate() or + inflate() can be made with more input or output space. A Z_BUF_ERROR + may in fact be unavoidable depending on how the functions are used, since + it is not possible to tell whether or not there is more output pending + when strm.avail_out returns with zero. + + 6. Where's the zlib documentation (man pages, etc.)? + + It's in zlib.h for the moment, and Francis S. Lin has converted it to a + web page zlib.html. Volunteers to transform this to Unix-style man pages, + please contact Jean-loup Gailly (jloup at gzip.org). Examples of zlib usage + are in the files example.c and minigzip.c. + + 7. Why don't you use GNU autoconf or libtool or ...? + + Because we would like to keep zlib as a very small and simple + package. zlib is rather portable and doesn't need much configuration. + + 8. I found a bug in zlib. + + Most of the time, such problems are due to an incorrect usage of + zlib. Please try to reproduce the problem with a small program and send + the corresponding source to us at zlib at gzip.org . Do not send + multi-megabyte data files without prior agreement. + + 9. Why do I get "undefined reference to gzputc"? + + If "make test" produces something like + + example.o(.text+0x154): undefined reference to `gzputc' + + check that you don't have old files libz.* in /usr/lib, /usr/local/lib or + /usr/X11R6/lib. Remove any old versions, then do "make install". + + 10. I need a Delphi interface to zlib. + + See the contrib/delphi directory in the zlib distribution. + + 11. Can zlib handle .zip archives? + + See the directory contrib/minizip in the zlib distribution. + + 12. Can zlib handle .Z files? + + No, sorry. You have to spawn an uncompress or gunzip subprocess, or adapt + the code of uncompress on your own. + + 13. How can I make a Unix shared library? + + make clean + ./configure -s + make + + 14. How do I install a shared zlib library on Unix? + + make install + + However, many flavors of Unix come with a shared zlib already installed. + Before going to the trouble of compiling a shared version of zlib and + trying to install it, you may want to check if it's already there! If you + can #include , it's there. The -lz option will probably link to it. + + 15. I have a question about OttoPDF + + We are not the authors of OttoPDF. The real author is on the OttoPDF web + site Joel Hainley jhainley at myndkryme.com. + + 16. Why does gzip give an error on a file I make with compress/deflate? + + The compress and deflate functions produce data in the zlib format, which + is different and incompatible with the gzip format. The gz* functions in + zlib on the other hand use the gzip format. Both the zlib and gzip + formats use the same compressed data format internally, but have different + headers and trailers around the compressed data. + + 17. Ok, so why are there two different formats? + + The gzip format was designed to retain the directory information about + a single file, such as the name and last modification date. The zlib + format on the other hand was designed for in-memory and communication + channel applications, and has a much more compact header and trailer and + uses a faster integrity check than gzip. + + 18. Well that's nice, but how do I make a gzip file in memory? + + You can request that deflate write the gzip format instead of the zlib + format using deflateInit2(). You can also request that inflate decode + the gzip format using inflateInit2(). Read zlib.h for more details. + + Note that you cannot specify special gzip header contents (e.g. a file + name or modification date), nor will inflate tell you what was in the + gzip header. If you need to customize the header or see what's in it, + you can use the raw deflate and inflate operations and the crc32() + function and roll your own gzip encoding and decoding. Read the gzip + RFC 1952 for details of the header and trailer format. + + 19. Is zlib thread-safe? + + Yes. However any library routines that zlib uses and any application- + provided memory allocation routines must also be thread-safe. zlib's gz* + functions use stdio library routines, and most of zlib's functions use the + library memory allocation routines by default. zlib's Init functions allow + for the application to provide custom memory allocation routines. + + Of course, you should only operate on any given zlib or gzip stream from a + single thread at a time. + + 20. Can I use zlib in my commercial application? + + Yes. Please read the license in zlib.h. + + 21. Is zlib under the GNU license? + + No. Please read the license in zlib.h. + + 22. The license says that altered source versions must be "plainly marked". So + what exactly do I need to do to meet that requirement? + + You need to change the ZLIB_VERSION and ZLIB_VERNUM #defines in zlib.h. In + particular, the final version number needs to be changed to "f", and an + identification string should be appended to ZLIB_VERSION. Version numbers + x.x.x.f are reserved for modifications to zlib by others than the zlib + maintainers. For example, if the version of the base zlib you are altering + is "1.2.3.4", then in zlib.h you should change ZLIB_VERNUM to 0x123f, and + ZLIB_VERSION to something like "1.2.3.f-zachary-mods-v3". You can also + update the version strings in deflate.c and inftrees.c. + + For altered source distributions, you should also note the origin and + nature of the changes in zlib.h, as well as in ChangeLog and README, along + with the dates of the alterations. The origin should include at least your + name (or your company's name), and an email address to contact for help or + issues with the library. + + Note that distributing a compiled zlib library along with zlib.h and + zconf.h is also a source distribution, and so you should change + ZLIB_VERSION and ZLIB_VERNUM and note the origin and nature of the changes + in zlib.h as you would for a full source distribution. + + 23. Will zlib work on a big-endian or little-endian architecture, and can I + exchange compressed data between them? + + Yes and yes. + + 24. Will zlib work on a 64-bit machine? + + It should. It has been tested on 64-bit machines, and has no dependence + on any data types being limited to 32-bits in length. If you have any + difficulties, please provide a complete problem report to zlib at gzip.org + + 25. Will zlib decompress data from the PKWare Data Compression Library? + + No. The PKWare DCL uses a completely different compressed data format + than does PKZIP and zlib. However, you can look in zlib's contrib/blast + directory for a possible solution to your problem. + + 26. Can I access data randomly in a compressed stream? + + No, not without some preparation. If when compressing you periodically + use Z_FULL_FLUSH, carefully write all the pending data at those points, + and keep an index of those locations, then you can start decompression + at those points. You have to be careful to not use Z_FULL_FLUSH too + often, since it can significantly degrade compression. + + 27. Does zlib work on MVS, OS/390, CICS, etc.? + + We don't know for sure. We have heard occasional reports of success on + these systems. If you do use it on one of these, please provide us with + a report, instructions, and patches that we can reference when we get + these questions. Thanks. + + 28. Is there some simpler, easier to read version of inflate I can look at + to understand the deflate format? + + First off, you should read RFC 1951. Second, yes. Look in zlib's + contrib/puff directory. + + 29. Does zlib infringe on any patents? + + As far as we know, no. In fact, that was originally the whole point behind + zlib. Look here for some more information: + + http://www.gzip.org/#faq11 + + 30. Can zlib work with greater than 4 GB of data? + + Yes. inflate() and deflate() will process any amount of data correctly. + Each call of inflate() or deflate() is limited to input and output chunks + of the maximum value that can be stored in the compiler's "unsigned int" + type, but there is no limit to the number of chunks. Note however that the + strm.total_in and strm_total_out counters may be limited to 4 GB. These + counters are provided as a convenience and are not used internally by + inflate() or deflate(). The application can easily set up its own counters + updated after each call of inflate() or deflate() to count beyond 4 GB. + compress() and uncompress() may be limited to 4 GB, since they operate in a + single call. gzseek() and gztell() may be limited to 4 GB depending on how + zlib is compiled. See the zlibCompileFlags() function in zlib.h. + + The word "may" appears several times above since there is a 4 GB limit + only if the compiler's "long" type is 32 bits. If the compiler's "long" + type is 64 bits, then the limit is 16 exabytes. + + 31. Does zlib have any security vulnerabilities? + + The only one that we are aware of is potentially in gzprintf(). If zlib + is compiled to use sprintf() or vsprintf(), then there is no protection + against a buffer overflow of a 4K string space, other than the caller of + gzprintf() assuring that the output will not exceed 4K. On the other + hand, if zlib is compiled to use snprintf() or vsnprintf(), which should + normally be the case, then there is no vulnerability. The ./configure + script will display warnings if an insecure variation of sprintf() will + be used by gzprintf(). Also the zlibCompileFlags() function will return + information on what variant of sprintf() is used by gzprintf(). + + If you don't have snprintf() or vsnprintf() and would like one, you can + find a portable implementation here: + + http://www.ijs.si/software/snprintf/ + + Note that you should be using the most recent version of zlib. Versions + 1.1.3 and before were subject to a double-free vulnerability. + + 32. Is there a Java version of zlib? + + Probably what you want is to use zlib in Java. zlib is already included + as part of the Java SDK in the java.util.zip package. If you really want + a version of zlib written in the Java language, look on the zlib home + page for links: http://www.zlib.org/ + + 33. I get this or that compiler or source-code scanner warning when I crank it + up to maximally-pendantic. Can't you guys write proper code? + + Many years ago, we gave up attempting to avoid warnings on every compiler + in the universe. It just got to be a waste of time, and some compilers + were downright silly. So now, we simply make sure that the code always + works. + + 34. Will zlib read the (insert any ancient or arcane format here) compressed + data format? + + Probably not. Look in the comp.compression FAQ for pointers to various + formats and associated software. + + 35. How can I encrypt/decrypt zip files with zlib? + + zlib doesn't support encryption. The original PKZIP encryption is very weak + and can be broken with freely available programs. To get strong encryption, + use gpg ( http://www.gnupg.org/ ) which already includes zlib compression. + For PKZIP compatible "encryption", look at http://www.info-zip.org/ + + 36. What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings? + + "gzip" is the gzip format, and "deflate" is the zlib format. They should + probably have called the second one "zlib" instead to avoid confusion + with the raw deflate compressed data format. While the HTTP 1.1 RFC 2616 + correctly points to the zlib specification in RFC 1950 for the "deflate" + transfer encoding, there have been reports of servers and browsers that + incorrectly produce or expect raw deflate data per the deflate + specficiation in RFC 1951, most notably Microsoft. So even though the + "deflate" transfer encoding using the zlib format would be the more + efficient approach (and in fact exactly what the zlib format was designed + for), using the "gzip" transfer encoding is probably more reliable due to + an unfortunate choice of name on the part of the HTTP 1.1 authors. + + Bottom line: use the gzip format for HTTP 1.1 encoding. + + 37. Does zlib support the new "Deflate64" format introduced by PKWare? + + No. PKWare has apparently decided to keep that format proprietary, since + they have not documented it as they have previous compression formats. + In any case, the compression improvements are so modest compared to other + more modern approaches, that it's not worth the effort to implement. + + 38. Can you please sign these lengthy legal documents and fax them back to us + so that we can use your software in our product? + + No. Go away. Shoo. Index: llvm-test/Runtime/zlib/INDEX diff -c /dev/null llvm-test/Runtime/zlib/INDEX:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/INDEX Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,48 ---- + ChangeLog history of changes + FAQ Frequently Asked Questions about zlib + INDEX this file + Makefile makefile for Unix (generated by configure) + Makefile.in makefile for Unix (template for configure) + README guess what + algorithm.txt description of the (de)compression algorithm + configure configure script for Unix + zconf.in.h template for zconf.h (used by configure) + + msdos/ makefiles for MSDOS + old/ makefiles for various architectures and zlib documentation + files that have not yet been updated for zlib 1.2.x + qnx/ makefiles for QNX + win32/ makefiles for Windows + + zlib public header files (must be kept): + zconf.h + zlib.h + + private source files used to build the zlib library: + adler32.c + compress.c + crc32.c + crc32.h + deflate.c + deflate.h + gzio.c + infback.c + inffast.c + inffast.h + inffixed.h + inflate.c + inflate.h + inftrees.c + inftrees.h + trees.c + trees.h + uncompr.c + zutil.c + zutil.h + + source files for sample programs: + example.c + minigzip.c + + unsupported contribution by third parties + See contrib/README.contrib Index: llvm-test/Runtime/zlib/LICENSE.TXT diff -c /dev/null llvm-test/Runtime/zlib/LICENSE.TXT:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/LICENSE.TXT Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,9 ---- + This is the zlib compression library. It is licensed to you under the Illinois + Open Source License. + + In addition, you must follow any additional licensing restrictions in the + zlib.h file. + + The zlib.h file from the original zlib distribution contains additional + copyrights. + Index: llvm-test/Runtime/zlib/Makefile diff -c /dev/null llvm-test/Runtime/zlib/Makefile:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/Makefile Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,19 ---- + ##===- runtime/zlib/Makefile -------------------------------*- Makefile -*-===## + # + # The LLVM Compiler Infrastructure + # + # This file was developed by the LLVM research group and is distributed under + # the University of Illinois Open Source License. See LICENSE.TXT for details. + # + ##===----------------------------------------------------------------------===## + LEVEL = ../.. + BYTECODE_LIBRARY=1 + BUILD_ARCHIVE=1 + DONT_BUILD_RELINKED=1 + LIBRARYNAME=z + CPPFLAGS += -DNO_DUMMY_DECL=1 + + Source = adler32.c compress.c crc32.c gzio.c uncompr.c deflate.c trees.c \ + zutil.c inflate.c infback.c inftrees.c inffast.c + + include $(LEVEL)/Makefile.common Index: llvm-test/Runtime/zlib/Makefile.in diff -c /dev/null llvm-test/Runtime/zlib/Makefile.in:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/Makefile.in Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,154 ---- + # Makefile for zlib + # Copyright (C) 1995-2003 Jean-loup Gailly. + # For conditions of distribution and use, see copyright notice in zlib.h + + # To compile and test, type: + # ./configure; make test + # The call of configure is optional if you don't have special requirements + # If you wish to build zlib as a shared library, use: ./configure -s + + # To use the asm code, type: + # cp contrib/asm?86/match.S ./match.S + # make LOC=-DASMV OBJA=match.o + + # To install /usr/local/lib/libz.* and /usr/local/include/zlib.h, type: + # make install + # To install in $HOME instead of /usr/local, use: + # make install prefix=$HOME + + CC=cc + + CFLAGS=-O + #CFLAGS=-O -DMAX_WBITS=14 -DMAX_MEM_LEVEL=7 + #CFLAGS=-g -DDEBUG + #CFLAGS=-O3 -Wall -Wwrite-strings -Wpointer-arith -Wconversion \ + # -Wstrict-prototypes -Wmissing-prototypes + + LDFLAGS=libz.a + LDSHARED=$(CC) + CPP=$(CC) -E + + LIBS=libz.a + SHAREDLIB=libz.so + SHAREDLIBV=libz.so.1.2.1 + SHAREDLIBM=libz.so.1 + + AR=ar rc + RANLIB=ranlib + TAR=tar + SHELL=/bin/sh + EXE= + + prefix = /usr/local + exec_prefix = ${prefix} + libdir = ${exec_prefix}/lib + includedir = ${prefix}/include + mandir = ${prefix}/share/man + man3dir = ${mandir}/man3 + + OBJS = adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o \ + zutil.o inflate.o infback.o inftrees.o inffast.o + + OBJA = + # to use the asm code: make OBJA=match.o + + TEST_OBJS = example.o minigzip.o + + all: example$(EXE) minigzip$(EXE) + + check: test + test: all + @LD_LIBRARY_PATH=.:$(LD_LIBRARY_PATH) ; export LD_LIBRARY_PATH; \ + echo hello world | ./minigzip | ./minigzip -d || \ + echo ' *** minigzip test FAILED ***' ; \ + if ./example; then \ + echo ' *** zlib test OK ***'; \ + else \ + echo ' *** zlib test FAILED ***'; \ + fi + + libz.a: $(OBJS) $(OBJA) + $(AR) $@ $(OBJS) $(OBJA) + -@ ($(RANLIB) $@ || true) >/dev/null 2>&1 + + match.o: match.S + $(CPP) match.S > _match.s + $(CC) -c _match.s + mv _match.o match.o + rm -f _match.s + + $(SHAREDLIBV): $(OBJS) + $(LDSHARED) -o $@ $(OBJS) + rm -f $(SHAREDLIB) $(SHAREDLIBM) + ln -s $@ $(SHAREDLIB) + ln -s $@ $(SHAREDLIBM) + + example$(EXE): example.o $(LIBS) + $(CC) $(CFLAGS) -o $@ example.o $(LDFLAGS) + + minigzip$(EXE): minigzip.o $(LIBS) + $(CC) $(CFLAGS) -o $@ minigzip.o $(LDFLAGS) + + install: $(LIBS) + - at if [ ! -d $(exec_prefix) ]; then mkdir -p $(exec_prefix); fi + - at if [ ! -d $(includedir) ]; then mkdir -p $(includedir); fi + - at if [ ! -d $(libdir) ]; then mkdir -p $(libdir); fi + - at if [ ! -d $(man3dir) ]; then mkdir -p $(man3dir); fi + cp zlib.h zconf.h $(includedir) + chmod 644 $(includedir)/zlib.h $(includedir)/zconf.h + cp $(LIBS) $(libdir) + cd $(libdir); chmod 755 $(LIBS) + -@(cd $(libdir); $(RANLIB) libz.a || true) >/dev/null 2>&1 + cd $(libdir); if test -f $(SHAREDLIBV); then \ + rm -f $(SHAREDLIB) $(SHAREDLIBM); \ + ln -s $(SHAREDLIBV) $(SHAREDLIB); \ + ln -s $(SHAREDLIBV) $(SHAREDLIBM); \ + (ldconfig || true) >/dev/null 2>&1; \ + fi + cp zlib.3 $(man3dir) + chmod 644 $(man3dir)/zlib.3 + # The ranlib in install is needed on NeXTSTEP which checks file times + # ldconfig is for Linux + + uninstall: + cd $(includedir); \ + cd $(libdir); rm -f libz.a; \ + if test -f $(SHAREDLIBV); then \ + rm -f $(SHAREDLIBV) $(SHAREDLIB) $(SHAREDLIBM); \ + fi + cd $(man3dir); rm -f zlib.3 + + mostlyclean: clean + clean: + rm -f *.o *~ example$(EXE) minigzip$(EXE) \ + libz.* foo.gz so_locations \ + _match.s maketree contrib/infback9/*.o + + maintainer-clean: distclean + distclean: clean + cp -p Makefile.in Makefile + cp -p zconf.in.h zconf.h + rm -f .DS_Store + + tags: + etags *.[ch] + + depend: + makedepend -- $(CFLAGS) -- *.[ch] + + # DO NOT DELETE THIS LINE -- make depend depends on it. + + adler32.o: zlib.h zconf.h + compress.o: zlib.h zconf.h + crc32.o: crc32.h zlib.h zconf.h + deflate.o: deflate.h zutil.h zlib.h zconf.h + example.o: zlib.h zconf.h + gzio.o: zutil.h zlib.h zconf.h + inffast.o: zutil.h zlib.h zconf.h inftrees.h inflate.h inffast.h + inflate.o: zutil.h zlib.h zconf.h inftrees.h inflate.h inffast.h + infback.o: zutil.h zlib.h zconf.h inftrees.h inflate.h inffast.h + inftrees.o: zutil.h zlib.h zconf.h inftrees.h + minigzip.o: zlib.h zconf.h + trees.o: deflate.h zutil.h zlib.h zconf.h trees.h + uncompr.o: zlib.h zconf.h + zutil.o: zutil.h zlib.h zconf.h Index: llvm-test/Runtime/zlib/Makefile.orig diff -c /dev/null llvm-test/Runtime/zlib/Makefile.orig:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/Makefile.orig Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,154 ---- + # Makefile for zlib + # Copyright (C) 1995-2003 Jean-loup Gailly. + # For conditions of distribution and use, see copyright notice in zlib.h + + # To compile and test, type: + # ./configure; make test + # The call of configure is optional if you don't have special requirements + # If you wish to build zlib as a shared library, use: ./configure -s + + # To use the asm code, type: + # cp contrib/asm?86/match.S ./match.S + # make LOC=-DASMV OBJA=match.o + + # To install /usr/local/lib/libz.* and /usr/local/include/zlib.h, type: + # make install + # To install in $HOME instead of /usr/local, use: + # make install prefix=$HOME + + CC=cc + + CFLAGS=-O + #CFLAGS=-O -DMAX_WBITS=14 -DMAX_MEM_LEVEL=7 + #CFLAGS=-g -DDEBUG + #CFLAGS=-O3 -Wall -Wwrite-strings -Wpointer-arith -Wconversion \ + # -Wstrict-prototypes -Wmissing-prototypes + + LDFLAGS=libz.a + LDSHARED=$(CC) + CPP=$(CC) -E + + LIBS=libz.a + SHAREDLIB=libz.so + SHAREDLIBV=libz.so.1.2.1 + SHAREDLIBM=libz.so.1 + + AR=ar rc + RANLIB=ranlib + TAR=tar + SHELL=/bin/sh + EXE= + + prefix = /usr/local + exec_prefix = ${prefix} + libdir = ${exec_prefix}/lib + includedir = ${prefix}/include + mandir = ${prefix}/share/man + man3dir = ${mandir}/man3 + + OBJS = adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o \ + zutil.o inflate.o infback.o inftrees.o inffast.o + + OBJA = + # to use the asm code: make OBJA=match.o + + TEST_OBJS = example.o minigzip.o + + all: example$(EXE) minigzip$(EXE) + + check: test + test: all + @LD_LIBRARY_PATH=.:$(LD_LIBRARY_PATH) ; export LD_LIBRARY_PATH; \ + echo hello world | ./minigzip | ./minigzip -d || \ + echo ' *** minigzip test FAILED ***' ; \ + if ./example; then \ + echo ' *** zlib test OK ***'; \ + else \ + echo ' *** zlib test FAILED ***'; \ + fi + + libz.a: $(OBJS) $(OBJA) + $(AR) $@ $(OBJS) $(OBJA) + -@ ($(RANLIB) $@ || true) >/dev/null 2>&1 + + match.o: match.S + $(CPP) match.S > _match.s + $(CC) -c _match.s + mv _match.o match.o + rm -f _match.s + + $(SHAREDLIBV): $(OBJS) + $(LDSHARED) -o $@ $(OBJS) + rm -f $(SHAREDLIB) $(SHAREDLIBM) + ln -s $@ $(SHAREDLIB) + ln -s $@ $(SHAREDLIBM) + + example$(EXE): example.o $(LIBS) + $(CC) $(CFLAGS) -o $@ example.o $(LDFLAGS) + + minigzip$(EXE): minigzip.o $(LIBS) + $(CC) $(CFLAGS) -o $@ minigzip.o $(LDFLAGS) + + install: $(LIBS) + - at if [ ! -d $(exec_prefix) ]; then mkdir -p $(exec_prefix); fi + - at if [ ! -d $(includedir) ]; then mkdir -p $(includedir); fi + - at if [ ! -d $(libdir) ]; then mkdir -p $(libdir); fi + - at if [ ! -d $(man3dir) ]; then mkdir -p $(man3dir); fi + cp zlib.h zconf.h $(includedir) + chmod 644 $(includedir)/zlib.h $(includedir)/zconf.h + cp $(LIBS) $(libdir) + cd $(libdir); chmod 755 $(LIBS) + -@(cd $(libdir); $(RANLIB) libz.a || true) >/dev/null 2>&1 + cd $(libdir); if test -f $(SHAREDLIBV); then \ + rm -f $(SHAREDLIB) $(SHAREDLIBM); \ + ln -s $(SHAREDLIBV) $(SHAREDLIB); \ + ln -s $(SHAREDLIBV) $(SHAREDLIBM); \ + (ldconfig || true) >/dev/null 2>&1; \ + fi + cp zlib.3 $(man3dir) + chmod 644 $(man3dir)/zlib.3 + # The ranlib in install is needed on NeXTSTEP which checks file times + # ldconfig is for Linux + + uninstall: + cd $(includedir); \ + cd $(libdir); rm -f libz.a; \ + if test -f $(SHAREDLIBV); then \ + rm -f $(SHAREDLIBV) $(SHAREDLIB) $(SHAREDLIBM); \ + fi + cd $(man3dir); rm -f zlib.3 + + mostlyclean: clean + clean: + rm -f *.o *~ example$(EXE) minigzip$(EXE) \ + libz.* foo.gz so_locations \ + _match.s maketree contrib/infback9/*.o + + maintainer-clean: distclean + distclean: clean + cp -p Makefile.in Makefile + cp -p zconf.in.h zconf.h + rm -f .DS_Store + + tags: + etags *.[ch] + + depend: + makedepend -- $(CFLAGS) -- *.[ch] + + # DO NOT DELETE THIS LINE -- make depend depends on it. + + adler32.o: zlib.h zconf.h + compress.o: zlib.h zconf.h + crc32.o: crc32.h zlib.h zconf.h + deflate.o: deflate.h zutil.h zlib.h zconf.h + example.o: zlib.h zconf.h + gzio.o: zutil.h zlib.h zconf.h + inffast.o: zutil.h zlib.h zconf.h inftrees.h inflate.h inffast.h + inflate.o: zutil.h zlib.h zconf.h inftrees.h inflate.h inffast.h + infback.o: zutil.h zlib.h zconf.h inftrees.h inflate.h inffast.h + inftrees.o: zutil.h zlib.h zconf.h inftrees.h + minigzip.o: zlib.h zconf.h + trees.o: deflate.h zutil.h zlib.h zconf.h trees.h + uncompr.o: zlib.h zconf.h + zutil.o: zutil.h zlib.h zconf.h Index: llvm-test/Runtime/zlib/README diff -c /dev/null llvm-test/Runtime/zlib/README:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/README Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,133 ---- + LLVM CHANGES TO ZLIB + + Changes made by the LLVM Team (llvmdev at cs.uiuc.edu, 2/6/2004): + 1) Makefile was modified for building with the LLVM build system and tools. + 2) Version numbers were updated as described in the FAQ. + 3) LLVM LICENSE.TXT file was added describing licensing information. + + ZLIB DATA COMPRESSION LIBRARY + + zlib 1.2.1 is a general purpose data compression library. All the code is + thread safe. The data format used by the zlib library is described by RFCs + (Request for Comments) 1950 to 1952 in the files + http://www.ietf.org/rfc/rfc1950.txt (zlib format), rfc1951.txt (deflate format) + and rfc1952.txt (gzip format). These documents are also available in other + formats from ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html + + All functions of the compression library are documented in the file zlib.h + (volunteer to write man pages welcome, contact zlib at gzip.org). A usage example + of the library is given in the file example.c which also tests that the library + is working correctly. Another example is given in the file minigzip.c. The + compression library itself is composed of all source files except example.c and + minigzip.c. + + To compile all files and run the test program, follow the instructions given at + the top of Makefile. In short "make test; make install" should work for most + machines. For Unix: "./configure; make test; make install" For MSDOS, use one + of the special makefiles such as Makefile.msc. For VMS, use Make_vms.com or + descrip.mms. + + Questions about zlib should be sent to , or to Gilles Vollant + for the Windows DLL version. The zlib home page is + http://www.zlib.org or http://www.gzip.org/zlib/ Before reporting a problem, + please check this site to verify that you have the latest version of zlib; + otherwise get the latest version and check whether the problem still exists or + not. + + PLEASE read the zlib FAQ http://www.gzip.org/zlib/zlib_faq.html before asking + for help. + + Mark Nelson wrote an article about zlib for the Jan. 1997 + issue of Dr. Dobb's Journal; a copy of the article is available in + http://dogma.net/markn/articles/zlibtool/zlibtool.htm + + The changes made in version 1.2.1 are documented in the file ChangeLog. + + Unsupported third party contributions are provided in directory "contrib". + + A Java implementation of zlib is available in the Java Development Kit + http://java.sun.com/j2se/1.4.2/docs/api/java/util/zip/package-summary.html + See the zlib home page http://www.zlib.org for details. + + A Perl interface to zlib written by Paul Marquess is in the + CPAN (Comprehensive Perl Archive Network) sites + http://www.cpan.org/modules/by-module/Compress/ + + A Python interface to zlib written by A.M. Kuchling is + available in Python 1.5 and later versions, see + http://www.python.org/doc/lib/module-zlib.html + + A zlib binding for TCL written by Andreas Kupries is + availlable at http://www.oche.de/~akupries/soft/trf/trf_zip.html + + An experimental package to read and write files in .zip format, written on top + of zlib by Gilles Vollant , is available in the + contrib/minizip directory of zlib. + + + Notes for some targets: + + - For Windows DLL versions, please see win32/DLL_FAQ.txt + + - For 64-bit Irix, deflate.c must be compiled without any optimization. With + -O, one libpng test fails. The test works in 32 bit mode (with the -n32 + compiler flag). The compiler bug has been reported to SGI. + + - zlib doesn't work with gcc 2.6.3 on a DEC 3000/300LX under OSF/1 2.1 it works + when compiled with cc. + + - On Digital Unix 4.0D (formely OSF/1) on AlphaServer, the cc option -std1 is + necessary to get gzprintf working correctly. This is done by configure. + + - zlib doesn't work on HP-UX 9.05 with some versions of /bin/cc. It works with + other compilers. Use "make test" to check your compiler. + + - gzdopen is not supported on RISCOS, BEOS and by some Mac compilers. + + - For PalmOs, see http://palmzlib.sourceforge.net/ + + - When building a shared, i.e. dynamic library on Mac OS X, the library must be + installed before testing (do "make install" before "make test"), since the + library location is specified in the library. + + + Acknowledgments: + + The deflate format used by zlib was defined by Phil Katz. The deflate + and zlib specifications were written by L. Peter Deutsch. Thanks to all the + people who reported problems and suggested various improvements in zlib; + they are too numerous to cite here. + + Copyright notice: + + (C) 1995-2003 Jean-loup Gailly and Mark Adler + + This software is provided 'as-is', without any express or implied + warranty. In no event will the authors be held liable for any damages + arising from the use of this software. + + Permission is granted to anyone to use this software for any purpose, + including commercial applications, and to alter it and redistribute it + freely, subject to the following restrictions: + + 1. The origin of this software must not be misrepresented; you must not + claim that you wrote the original software. If you use this software + in a product, an acknowledgment in the product documentation would be + appreciated but is not required. + 2. Altered source versions must be plainly marked as such, and must not be + misrepresented as being the original software. + 3. This notice may not be removed or altered from any source distribution. + + Jean-loup Gailly Mark Adler + jloup at gzip.org madler at alumni.caltech.edu + + If you use the zlib library in a product, we would appreciate *not* + receiving lengthy legal documents to sign. The sources are provided + for free but without warranty of any kind. The library has been + entirely written by Jean-loup Gailly and Mark Adler; it does not + include third-party code. + + If you redistribute modified sources, we would appreciate that you include + in the file ChangeLog history information documenting your changes. Please + read the FAQ for more information on the distribution of modified source + versions. Index: llvm-test/Runtime/zlib/adler32.c diff -c /dev/null llvm-test/Runtime/zlib/adler32.c:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/adler32.c Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,74 ---- + /* adler32.c -- compute the Adler-32 checksum of a data stream + * Copyright (C) 1995-2003 Mark Adler + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* @(#) $Id: adler32.c,v 1.1 2004/12/06 21:19:39 criswell Exp $ */ + + #define ZLIB_INTERNAL + #include "zlib.h" + + #define BASE 65521UL /* largest prime smaller than 65536 */ + #define NMAX 5552 + /* NMAX is the largest n such that 255n(n+1)/2 + (n+1)(BASE-1) <= 2^32-1 */ + + #define DO1(buf,i) {s1 += buf[i]; s2 += s1;} + #define DO2(buf,i) DO1(buf,i); DO1(buf,i+1); + #define DO4(buf,i) DO2(buf,i); DO2(buf,i+2); + #define DO8(buf,i) DO4(buf,i); DO4(buf,i+4); + #define DO16(buf) DO8(buf,0); DO8(buf,8); + + #ifdef NO_DIVIDE + # define MOD(a) \ + do { \ + if (a >= (BASE << 16)) a -= (BASE << 16); \ + if (a >= (BASE << 15)) a -= (BASE << 15); \ + if (a >= (BASE << 14)) a -= (BASE << 14); \ + if (a >= (BASE << 13)) a -= (BASE << 13); \ + if (a >= (BASE << 12)) a -= (BASE << 12); \ + if (a >= (BASE << 11)) a -= (BASE << 11); \ + if (a >= (BASE << 10)) a -= (BASE << 10); \ + if (a >= (BASE << 9)) a -= (BASE << 9); \ + if (a >= (BASE << 8)) a -= (BASE << 8); \ + if (a >= (BASE << 7)) a -= (BASE << 7); \ + if (a >= (BASE << 6)) a -= (BASE << 6); \ + if (a >= (BASE << 5)) a -= (BASE << 5); \ + if (a >= (BASE << 4)) a -= (BASE << 4); \ + if (a >= (BASE << 3)) a -= (BASE << 3); \ + if (a >= (BASE << 2)) a -= (BASE << 2); \ + if (a >= (BASE << 1)) a -= (BASE << 1); \ + if (a >= BASE) a -= BASE; \ + } while (0) + #else + # define MOD(a) a %= BASE + #endif + + /* ========================================================================= */ + uLong ZEXPORT adler32(adler, buf, len) + uLong adler; + const Bytef *buf; + uInt len; + { + unsigned long s1 = adler & 0xffff; + unsigned long s2 = (adler >> 16) & 0xffff; + int k; + + if (buf == Z_NULL) return 1L; + + while (len > 0) { + k = len < NMAX ? (int)len : NMAX; + len -= k; + while (k >= 16) { + DO16(buf); + buf += 16; + k -= 16; + } + if (k != 0) do { + s1 += *buf++; + s2 += s1; + } while (--k); + MOD(s1); + MOD(s2); + } + return (s2 << 16) | s1; + } Index: llvm-test/Runtime/zlib/algorithm.txt diff -c /dev/null llvm-test/Runtime/zlib/algorithm.txt:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/algorithm.txt Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,209 ---- + 1. Compression algorithm (deflate) + + The deflation algorithm used by gzip (also zip and zlib) is a variation of + LZ77 (Lempel-Ziv 1977, see reference below). It finds duplicated strings in + the input data. The second occurrence of a string is replaced by a + pointer to the previous string, in the form of a pair (distance, + length). Distances are limited to 32K bytes, and lengths are limited + to 258 bytes. When a string does not occur anywhere in the previous + 32K bytes, it is emitted as a sequence of literal bytes. (In this + description, `string' must be taken as an arbitrary sequence of bytes, + and is not restricted to printable characters.) + + Literals or match lengths are compressed with one Huffman tree, and + match distances are compressed with another tree. The trees are stored + in a compact form at the start of each block. The blocks can have any + size (except that the compressed data for one block must fit in + available memory). A block is terminated when deflate() determines that + it would be useful to start another block with fresh trees. (This is + somewhat similar to the behavior of LZW-based _compress_.) + + Duplicated strings are found using a hash table. All input strings of + length 3 are inserted in the hash table. A hash index is computed for + the next 3 bytes. If the hash chain for this index is not empty, all + strings in the chain are compared with the current input string, and + the longest match is selected. + + The hash chains are searched starting with the most recent strings, to + favor small distances and thus take advantage of the Huffman encoding. + The hash chains are singly linked. There are no deletions from the + hash chains, the algorithm simply discards matches that are too old. + + To avoid a worst-case situation, very long hash chains are arbitrarily + truncated at a certain length, determined by a runtime option (level + parameter of deflateInit). So deflate() does not always find the longest + possible match but generally finds a match which is long enough. + + deflate() also defers the selection of matches with a lazy evaluation + mechanism. After a match of length N has been found, deflate() searches for + a longer match at the next input byte. If a longer match is found, the + previous match is truncated to a length of one (thus producing a single + literal byte) and the process of lazy evaluation begins again. Otherwise, + the original match is kept, and the next match search is attempted only N + steps later. + + The lazy match evaluation is also subject to a runtime parameter. If + the current match is long enough, deflate() reduces the search for a longer + match, thus speeding up the whole process. If compression ratio is more + important than speed, deflate() attempts a complete second search even if + the first match is already long enough. + + The lazy match evaluation is not performed for the fastest compression + modes (level parameter 1 to 3). For these fast modes, new strings + are inserted in the hash table only when no match was found, or + when the match is not too long. This degrades the compression ratio + but saves time since there are both fewer insertions and fewer searches. + + + 2. Decompression algorithm (inflate) + + 2.1 Introduction + + The key question is how to represent a Huffman code (or any prefix code) so + that you can decode fast. The most important characteristic is that shorter + codes are much more common than longer codes, so pay attention to decoding the + short codes fast, and let the long codes take longer to decode. + + inflate() sets up a first level table that covers some number of bits of + input less than the length of longest code. It gets that many bits from the + stream, and looks it up in the table. The table will tell if the next + code is that many bits or less and how many, and if it is, it will tell + the value, else it will point to the next level table for which inflate() + grabs more bits and tries to decode a longer code. + + How many bits to make the first lookup is a tradeoff between the time it + takes to decode and the time it takes to build the table. If building the + table took no time (and if you had infinite memory), then there would only + be a first level table to cover all the way to the longest code. However, + building the table ends up taking a lot longer for more bits since short + codes are replicated many times in such a table. What inflate() does is + simply to make the number of bits in the first table a variable, and then + to set that variable for the maximum speed. + + For inflate, which has 286 possible codes for the literal/length tree, the size + of the first table is nine bits. Also the distance trees have 30 possible + values, and the size of the first table is six bits. Note that for each of + those cases, the table ended up one bit longer than the ``average'' code + length, i.e. the code length of an approximately flat code which would be a + little more than eight bits for 286 symbols and a little less than five bits + for 30 symbols. + + + 2.2 More details on the inflate table lookup + + Ok, you want to know what this cleverly obfuscated inflate tree actually + looks like. You are correct that it's not a Huffman tree. It is simply a + lookup table for the first, let's say, nine bits of a Huffman symbol. The + symbol could be as short as one bit or as long as 15 bits. If a particular + symbol is shorter than nine bits, then that symbol's translation is duplicated + in all those entries that start with that symbol's bits. For example, if the + symbol is four bits, then it's duplicated 32 times in a nine-bit table. If a + symbol is nine bits long, it appears in the table once. + + If the symbol is longer than nine bits, then that entry in the table points + to another similar table for the remaining bits. Again, there are duplicated + entries as needed. The idea is that most of the time the symbol will be short + and there will only be one table look up. (That's whole idea behind data + compression in the first place.) For the less frequent long symbols, there + will be two lookups. If you had a compression method with really long + symbols, you could have as many levels of lookups as is efficient. For + inflate, two is enough. + + So a table entry either points to another table (in which case nine bits in + the above example are gobbled), or it contains the translation for the symbol + and the number of bits to gobble. Then you start again with the next + ungobbled bit. + + You may wonder: why not just have one lookup table for how ever many bits the + longest symbol is? The reason is that if you do that, you end up spending + more time filling in duplicate symbol entries than you do actually decoding. + At least for deflate's output that generates new trees every several 10's of + kbytes. You can imagine that filling in a 2^15 entry table for a 15-bit code + would take too long if you're only decoding several thousand symbols. At the + other extreme, you could make a new table for every bit in the code. In fact, + that's essentially a Huffman tree. But then you spend two much time + traversing the tree while decoding, even for short symbols. + + So the number of bits for the first lookup table is a trade of the time to + fill out the table vs. the time spent looking at the second level and above of + the table. + + Here is an example, scaled down: + + The code being decoded, with 10 symbols, from 1 to 6 bits long: + + A: 0 + B: 10 + C: 1100 + D: 11010 + E: 11011 + F: 11100 + G: 11101 + H: 11110 + I: 111110 + J: 111111 + + Let's make the first table three bits long (eight entries): + + 000: A,1 + 001: A,1 + 010: A,1 + 011: A,1 + 100: B,2 + 101: B,2 + 110: -> table X (gobble 3 bits) + 111: -> table Y (gobble 3 bits) + + Each entry is what the bits decode as and how many bits that is, i.e. how + many bits to gobble. Or the entry points to another table, with the number of + bits to gobble implicit in the size of the table. + + Table X is two bits long since the longest code starting with 110 is five bits + long: + + 00: C,1 + 01: C,1 + 10: D,2 + 11: E,2 + + Table Y is three bits long since the longest code starting with 111 is six + bits long: + + 000: F,2 + 001: F,2 + 010: G,2 + 011: G,2 + 100: H,2 + 101: H,2 + 110: I,3 + 111: J,3 + + So what we have here are three tables with a total of 20 entries that had to + be constructed. That's compared to 64 entries for a single table. Or + compared to 16 entries for a Huffman tree (six two entry tables and one four + entry table). Assuming that the code ideally represents the probability of + the symbols, it takes on the average 1.25 lookups per symbol. That's compared + to one lookup for the single table, or 1.66 lookups per symbol for the + Huffman tree. + + There, I think that gives you a picture of what's going on. For inflate, the + meaning of a particular symbol is often more than just a letter. It can be a + byte (a "literal"), or it can be either a length or a distance which + indicates a base value and a number of bits to fetch after the code that is + added to the base value. Or it might be the special end-of-block code. The + data structures created in inftrees.c try to encode all that information + compactly in the tables. + + + Jean-loup Gailly Mark Adler + jloup at gzip.org madler at alumni.caltech.edu + + + References: + + [LZ77] Ziv J., Lempel A., ``A Universal Algorithm for Sequential Data + Compression,'' IEEE Transactions on Information Theory, Vol. 23, No. 3, + pp. 337-343. + + ``DEFLATE Compressed Data Format Specification'' available in + http://www.ietf.org/rfc/rfc1951.txt Index: llvm-test/Runtime/zlib/compress.c diff -c /dev/null llvm-test/Runtime/zlib/compress.c:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/compress.c Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,79 ---- + /* compress.c -- compress a memory buffer + * Copyright (C) 1995-2002 Jean-loup Gailly. + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* @(#) $Id: compress.c,v 1.1 2004/12/06 21:19:39 criswell Exp $ */ + + #define ZLIB_INTERNAL + #include "zlib.h" + + /* =========================================================================== + Compresses the source buffer into the destination buffer. The level + parameter has the same meaning as in deflateInit. sourceLen is the byte + length of the source buffer. Upon entry, destLen is the total size of the + destination buffer, which must be at least 0.1% larger than sourceLen plus + 12 bytes. Upon exit, destLen is the actual size of the compressed buffer. + + compress2 returns Z_OK if success, Z_MEM_ERROR if there was not enough + memory, Z_BUF_ERROR if there was not enough room in the output buffer, + Z_STREAM_ERROR if the level parameter is invalid. + */ + int ZEXPORT compress2 (dest, destLen, source, sourceLen, level) + Bytef *dest; + uLongf *destLen; + const Bytef *source; + uLong sourceLen; + int level; + { + z_stream stream; + int err; + + stream.next_in = (Bytef*)source; + stream.avail_in = (uInt)sourceLen; + #ifdef MAXSEG_64K + /* Check for source > 64K on 16-bit machine: */ + if ((uLong)stream.avail_in != sourceLen) return Z_BUF_ERROR; + #endif + stream.next_out = dest; + stream.avail_out = (uInt)*destLen; + if ((uLong)stream.avail_out != *destLen) return Z_BUF_ERROR; + + stream.zalloc = (alloc_func)0; + stream.zfree = (free_func)0; + stream.opaque = (voidpf)0; + + err = deflateInit(&stream, level); + if (err != Z_OK) return err; + + err = deflate(&stream, Z_FINISH); + if (err != Z_STREAM_END) { + deflateEnd(&stream); + return err == Z_OK ? Z_BUF_ERROR : err; + } + *destLen = stream.total_out; + + err = deflateEnd(&stream); + return err; + } + + /* =========================================================================== + */ + int ZEXPORT compress (dest, destLen, source, sourceLen) + Bytef *dest; + uLongf *destLen; + const Bytef *source; + uLong sourceLen; + { + return compress2(dest, destLen, source, sourceLen, Z_DEFAULT_COMPRESSION); + } + + /* =========================================================================== + If the default memLevel or windowBits for deflateInit() is changed, then + this function needs to be updated. + */ + uLong ZEXPORT compressBound (sourceLen) + uLong sourceLen; + { + return sourceLen + (sourceLen >> 12) + (sourceLen >> 14) + 11; + } Index: llvm-test/Runtime/zlib/configure diff -c /dev/null llvm-test/Runtime/zlib/configure:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/configure Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,445 ---- + #!/bin/sh + # configure script for zlib. This script is needed only if + # you wish to build a shared library and your system supports them, + # of if you need special compiler, flags or install directory. + # Otherwise, you can just use directly "make test; make install" + # + # To create a shared library, use "configure --shared"; by default a static + # library is created. If the primitive shared library support provided here + # does not work, use ftp://prep.ai.mit.edu/pub/gnu/libtool-*.tar.gz + # + # To impose specific compiler or flags or install directory, use for example: + # prefix=$HOME CC=cc CFLAGS="-O4" ./configure + # or for csh/tcsh users: + # (setenv prefix $HOME; setenv CC cc; setenv CFLAGS "-O4"; ./configure) + # LDSHARED is the command to be used to create a shared library + + # Incorrect settings of CC or CFLAGS may prevent creating a shared library. + # If you have problems, try without defining CC and CFLAGS before reporting + # an error. + + LIBS=libz.a + LDFLAGS="-L. ${LIBS}" + VER=`sed -n -e '/VERSION "/s/.*"\(.*\)".*/\1/p' < zlib.h` + VER2=`sed -n -e '/VERSION "/s/.*"\([0-9]*\\.[0-9]*\)\\..*/\1/p' < zlib.h` + VER1=`sed -n -e '/VERSION "/s/.*"\([0-9]*\)\\..*/\1/p' < zlib.h` + AR=${AR-"ar rc"} + RANLIB=${RANLIB-"ranlib"} + prefix=${prefix-/usr/local} + exec_prefix=${exec_prefix-'${prefix}'} + libdir=${libdir-'${exec_prefix}/lib'} + includedir=${includedir-'${prefix}/include'} + mandir=${mandir-'${prefix}/share/man'} + shared_ext='.so' + shared=0 + gcc=0 + old_cc="$CC" + old_cflags="$CFLAGS" + + while test $# -ge 1 + do + case "$1" in + -h* | --h*) + echo 'usage:' + echo ' configure [--shared] [--prefix=PREFIX] [--exec_prefix=EXPREFIX]' + echo ' [--libdir=LIBDIR] [--includedir=INCLUDEDIR]' + exit 0;; + -p*=* | --p*=*) prefix=`echo $1 | sed 's/[-a-z_]*=//'`; shift;; + -e*=* | --e*=*) exec_prefix=`echo $1 | sed 's/[-a-z_]*=//'`; shift;; + -l*=* | --libdir=*) libdir=`echo $1 | sed 's/[-a-z_]*=//'`; shift;; + -i*=* | --includedir=*) includedir=`echo $1 | sed 's/[-a-z_]*=//'`;shift;; + -p* | --p*) prefix="$2"; shift; shift;; + -e* | --e*) exec_prefix="$2"; shift; shift;; + -l* | --l*) libdir="$2"; shift; shift;; + -i* | --i*) includedir="$2"; shift; shift;; + -s* | --s*) shared=1; shift;; + *) echo "unknown option: $1"; echo "$0 --help for help"; exit 1;; + esac + done + + test=ztest$$ + cat > $test.c </dev/null; then + CC="$cc" + SFLAGS=${CFLAGS-"-fPIC -O3"} + CFLAGS="$cflags" + case `(uname -s || echo unknown) 2>/dev/null` in + Linux | linux | GNU | GNU/*) LDSHARED=${LDSHARED-"$cc -shared -Wl,-soname,libz.so.1"};; + CYGWIN* | Cygwin* | cygwin* ) + EXE='.exe';; + QNX*) # This is for QNX6. I suppose that the QNX rule below is for QNX2,QNX4 + # (alain.bonnefoy at icbt.com) + LDSHARED=${LDSHARED-"$cc -shared -Wl,-hlibz.so.1"};; + HP-UX*) LDSHARED=${LDSHARED-"$cc -shared $SFLAGS"} + shared_ext='.sl' + SHAREDLIB='libz.sl';; + Darwin*) shared_ext='.dylib' + SHAREDLIB=libz$shared_ext + SHAREDLIBV=libz.$VER$shared_ext + SHAREDLIBM=libz.$VER1$shared_ext + LDSHARED=${LDSHARED-"$cc -dynamiclib -install_name /usr/lib/$SHAREDLIBV -compatibility_version $VER2 -current_version $VER"} + libdir='/usr/lib' + includedir='/usr/include';; + *) LDSHARED=${LDSHARED-"$cc -shared"};; + esac + else + # find system name and corresponding cc options + CC=${CC-cc} + case `(uname -sr || echo unknown) 2>/dev/null` in + HP-UX*) SFLAGS=${CFLAGS-"-O +z"} + CFLAGS=${CFLAGS-"-O"} + # LDSHARED=${LDSHARED-"ld -b +vnocompatwarnings"} + LDSHARED=${LDSHARED-"ld -b"} + shared_ext='.sl' + SHAREDLIB='libz.sl';; + IRIX*) SFLAGS=${CFLAGS-"-ansi -O2 -rpath ."} + CFLAGS=${CFLAGS-"-ansi -O2"} + LDSHARED=${LDSHARED-"cc -shared"};; + OSF1\ V4*) SFLAGS=${CFLAGS-"-O -std1"} + CFLAGS=${CFLAGS-"-O -std1"} + LDSHARED=${LDSHARED-"cc -shared -Wl,-soname,libz.so -Wl,-msym -Wl,-rpath,$(libdir) -Wl,-set_version,${VER}:1.0"};; + OSF1*) SFLAGS=${CFLAGS-"-O -std1"} + CFLAGS=${CFLAGS-"-O -std1"} + LDSHARED=${LDSHARED-"cc -shared"};; + QNX*) SFLAGS=${CFLAGS-"-4 -O"} + CFLAGS=${CFLAGS-"-4 -O"} + LDSHARED=${LDSHARED-"cc"} + RANLIB=${RANLIB-"true"} + AR="cc -A";; + SCO_SV\ 3.2*) SFLAGS=${CFLAGS-"-O3 -dy -KPIC "} + CFLAGS=${CFLAGS-"-O3"} + LDSHARED=${LDSHARED-"cc -dy -KPIC -G"};; + SunOS\ 5*) SFLAGS=${CFLAGS-"-fast -xcg89 -KPIC -R."} + CFLAGS=${CFLAGS-"-fast -xcg89"} + LDSHARED=${LDSHARED-"cc -G"};; + SunOS\ 4*) SFLAGS=${CFLAGS-"-O2 -PIC"} + CFLAGS=${CFLAGS-"-O2"} + LDSHARED=${LDSHARED-"ld"};; + UNIX_System_V\ 4.2.0) + SFLAGS=${CFLAGS-"-KPIC -O"} + CFLAGS=${CFLAGS-"-O"} + LDSHARED=${LDSHARED-"cc -G"};; + UNIX_SV\ 4.2MP) + SFLAGS=${CFLAGS-"-Kconform_pic -O"} + CFLAGS=${CFLAGS-"-O"} + LDSHARED=${LDSHARED-"cc -G"};; + OpenUNIX\ 5) + SFLAGS=${CFLAGS-"-KPIC -O"} + CFLAGS=${CFLAGS-"-O"} + LDSHARED=${LDSHARED-"cc -G"};; + AIX*) # Courtesy of dbakker at arrayasolutions.com + SFLAGS=${CFLAGS-"-O -qmaxmem=8192"} + CFLAGS=${CFLAGS-"-O -qmaxmem=8192"} + LDSHARED=${LDSHARED-"xlc -G"};; + # send working options for other systems to support at gzip.org + *) SFLAGS=${CFLAGS-"-O"} + CFLAGS=${CFLAGS-"-O"} + LDSHARED=${LDSHARED-"cc -shared"};; + esac + fi + + SHAREDLIB=${SHAREDLIB-"libz$shared_ext"} + SHAREDLIBV=${SHAREDLIBV-"libz$shared_ext.$VER"} + SHAREDLIBM=${SHAREDLIBM-"libz$shared_ext.$VER1"} + + if test $shared -eq 1; then + echo Checking for shared library support... + # we must test in two steps (cc then ld), required at least on SunOS 4.x + if test "`($CC -c $SFLAGS $test.c) 2>&1`" = "" && + test "`($LDSHARED -o $test$shared_ext $test.o) 2>&1`" = ""; then + CFLAGS="$SFLAGS" + LIBS="$SHAREDLIBV" + echo Building shared library $SHAREDLIBV with $CC. + elif test -z "$old_cc" -a -z "$old_cflags"; then + echo No shared library support. + shared=0; + else + echo 'No shared library support; try without defining CC and CFLAGS' + shared=0; + fi + fi + if test $shared -eq 0; then + LDSHARED="$CC" + echo Building static library $LIBS version $VER with $CC. + else + LDFLAGS="-L. ${SHAREDLIBV}" + fi + + cat > $test.c < + int main() { return 0; } + EOF + if test "`($CC -c $CFLAGS $test.c) 2>&1`" = ""; then + sed < zconf.in.h "/HAVE_UNISTD_H/s%0%1%" > zconf.h + echo "Checking for unistd.h... Yes." + else + cp -p zconf.in.h zconf.h + echo "Checking for unistd.h... No." + fi + + cat > $test.c < + #include + #include "zconf.h" + + int main() + { + #ifndef STDC + choke me + #endif + + return 0; + } + EOF + + if test "`($CC -c $CFLAGS $test.c) 2>&1`" = ""; then + echo "Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf()" + + cat > $test.c < + #include + + int mytest(char *fmt, ...) + { + char buf[20]; + va_list ap; + + va_start(ap, fmt); + vsnprintf(buf, sizeof(buf), fmt, ap); + va_end(ap); + return 0; + } + + int main() + { + return (mytest("Hello%d\n", 1)); + } + EOF + + if test "`($CC $CFLAGS -o $test $test.c) 2>&1`" = ""; then + echo "Checking for vsnprintf() in stdio.h... Yes." + + cat >$test.c < + #include + + int mytest(char *fmt, ...) + { + int n; + char buf[20]; + va_list ap; + + va_start(ap, fmt); + n = vsnprintf(buf, sizeof(buf), fmt, ap); + va_end(ap); + return n; + } + + int main() + { + return (mytest("Hello%d\n", 1)); + } + EOF + + if test "`($CC -c $CFLAGS $test.c) 2>&1`" = ""; then + echo "Checking for return value of vsnprintf()... Yes." + else + CFLAGS="$CFLAGS -DHAS_vsnprintf_void" + echo "Checking for return value of vsnprintf()... No." + echo " WARNING: apparently vsnprintf() does not return a value. zlib" + echo " can build but will be open to possible string-format security" + echo " vulnerabilities." + fi + else + CFLAGS="$CFLAGS -DNO_vsnprintf" + echo "Checking for vsnprintf() in stdio.h... No." + echo " WARNING: vsnprintf() not found, falling back to vsprintf(). zlib" + echo " can build but will be open to possible buffer-overflow security" + echo " vulnerabilities." + + cat >$test.c < + #include + + int mytest(char *fmt, ...) + { + int n; + char buf[20]; + va_list ap; + + va_start(ap, fmt); + n = vsprintf(buf, fmt, ap); + va_end(ap); + return n; + } + + int main() + { + return (mytest("Hello%d\n", 1)); + } + EOF + + if test "`($CC -c $CFLAGS $test.c) 2>&1`" = ""; then + echo "Checking for return value of vsprintf()... Yes." + else + CFLAGS="$CFLAGS -DHAS_vsprintf_void" + echo "Checking for return value of vsprintf()... No." + echo " WARNING: apparently vsprintf() does not return a value. zlib" + echo " can build but will be open to possible string-format security" + echo " vulnerabilities." + fi + fi + else + echo "Checking whether to use vs[n]printf() or s[n]printf()... using s[n]printf()" + + cat >$test.c < + + int mytest() + { + char buf[20]; + + snprintf(buf, sizeof(buf), "%s", "foo"); + return 0; + } + + int main() + { + return (mytest()); + } + EOF + + if test "`($CC $CFLAGS -o $test $test.c) 2>&1`" = ""; then + echo "Checking for snprintf() in stdio.h... Yes." + + cat >$test.c < + + int mytest() + { + char buf[20]; + + return snprintf(buf, sizeof(buf), "%s", "foo"); + } + + int main() + { + return (mytest()); + } + EOF + + if test "`($CC -c $CFLAGS $test.c) 2>&1`" = ""; then + echo "Checking for return value of snprintf()... Yes." + else + CFLAGS="$CFLAGS -DHAS_snprintf_void" + echo "Checking for return value of snprintf()... No." + echo " WARNING: apparently snprintf() does not return a value. zlib" + echo " can build but will be open to possible string-format security" + echo " vulnerabilities." + fi + else + CFLAGS="$CFLAGS -DNO_snprintf" + echo "Checking for snprintf() in stdio.h... No." + echo " WARNING: snprintf() not found, falling back to sprintf(). zlib" + echo " can build but will be open to possible buffer-overflow security" + echo " vulnerabilities." + + cat >$test.c < + + int mytest() + { + char buf[20]; + + return sprintf(buf, "%s", "foo"); + } + + int main() + { + return (mytest()); + } + EOF + + if test "`($CC -c $CFLAGS $test.c) 2>&1`" = ""; then + echo "Checking for return value of sprintf()... Yes." + else + CFLAGS="$CFLAGS -DHAS_sprintf_void" + echo "Checking for return value of sprintf()... No." + echo " WARNING: apparently sprintf() does not return a value. zlib" + echo " can build but will be open to possible string-format security" + echo " vulnerabilities." + fi + fi + fi + + cat >$test.c < + int main() { return 0; } + EOF + if test "`($CC -c $CFLAGS $test.c) 2>&1`" = ""; then + echo "Checking for errno.h... Yes." + else + echo "Checking for errno.h... No." + CFLAGS="$CFLAGS -DNO_ERRNO_H" + fi + + cat > $test.c < + #include + #include + caddr_t hello() { + return mmap((caddr_t)0, (off_t)0, PROT_READ, MAP_SHARED, 0, (off_t)0); + } + EOF + if test "`($CC -c $CFLAGS $test.c) 2>&1`" = ""; then + CFLAGS="$CFLAGS -DUSE_MMAP" + echo Checking for mmap support... Yes. + else + echo Checking for mmap support... No. + fi + + CPP=${CPP-"$CC -E"} + case $CFLAGS in + *ASMV*) + if test "`nm $test.o | grep _hello`" = ""; then + CPP="$CPP -DNO_UNDERLINE" + echo Checking for underline in external names... No. + else + echo Checking for underline in external names... Yes. + fi;; + esac + + rm -f $test.[co] $test $test$shared_ext + + # udpate Makefile + sed < Makefile.in " + /^CC *=/s#=.*#=$CC# + /^CFLAGS *=/s#=.*#=$CFLAGS# + /^CPP *=/s#=.*#=$CPP# + /^LDSHARED *=/s#=.*#=$LDSHARED# + /^LIBS *=/s#=.*#=$LIBS# + /^SHAREDLIB *=/s#=.*#=$SHAREDLIB# + /^SHAREDLIBV *=/s#=.*#=$SHAREDLIBV# + /^SHAREDLIBM *=/s#=.*#=$SHAREDLIBM# + /^AR *=/s#=.*#=$AR# + /^RANLIB *=/s#=.*#=$RANLIB# + /^EXE *=/s#=.*#=$EXE# + /^prefix *=/s#=.*#=$prefix# + /^exec_prefix *=/s#=.*#=$exec_prefix# + /^libdir *=/s#=.*#=$libdir# + /^includedir *=/s#=.*#=$includedir# + /^mandir *=/s#=.*#=$mandir# + /^LDFLAGS *=/s#=.*#=$LDFLAGS# + " > Makefile Index: llvm-test/Runtime/zlib/crc32.c diff -c /dev/null llvm-test/Runtime/zlib/crc32.c:1.1 *** /dev/null Mon Dec 6 15:19:55 2004 --- llvm-test/Runtime/zlib/crc32.c Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,311 ---- + /* crc32.c -- compute the CRC-32 of a data stream + * Copyright (C) 1995-2003 Mark Adler + * For conditions of distribution and use, see copyright notice in zlib.h + * + * Thanks to Rodney Brown for his contribution of faster + * CRC methods: exclusive-oring 32 bits of data at a time, and pre-computing + * tables for updating the shift register in one step with three exclusive-ors + * instead of four steps with four exclusive-ors. This results about a factor + * of two increase in speed on a Power PC G4 (PPC7455) using gcc -O3. + */ + + /* @(#) $Id: crc32.c,v 1.1 2004/12/06 21:19:39 criswell Exp $ */ + + #ifdef MAKECRCH + # include + # ifndef DYNAMIC_CRC_TABLE + # define DYNAMIC_CRC_TABLE + # endif /* !DYNAMIC_CRC_TABLE */ + #endif /* MAKECRCH */ + + #include "zutil.h" /* for STDC and FAR definitions */ + + #define local static + + /* Find a four-byte integer type for crc32_little() and crc32_big(). */ + #ifndef NOBYFOUR + # ifdef STDC /* need ANSI C limits.h to determine sizes */ + # include + # define BYFOUR + # if (UINT_MAX == 0xffffffffUL) + typedef unsigned int u4; + # else + # if (ULONG_MAX == 0xffffffffUL) + typedef unsigned long u4; + # else + # if (USHRT_MAX == 0xffffffffUL) + typedef unsigned short u4; + # else + # undef BYFOUR /* can't find a four-byte integer type! */ + # endif + # endif + # endif + # endif /* STDC */ + #endif /* !NOBYFOUR */ + + /* Definitions for doing the crc four data bytes at a time. */ + #ifdef BYFOUR + # define REV(w) (((w)>>24)+(((w)>>8)&0xff00)+ \ + (((w)&0xff00)<<8)+(((w)&0xff)<<24)) + local unsigned long crc32_little OF((unsigned long, + const unsigned char FAR *, unsigned)); + local unsigned long crc32_big OF((unsigned long, + const unsigned char FAR *, unsigned)); + # define TBLS 8 + #else + # define TBLS 1 + #endif /* BYFOUR */ + + #ifdef DYNAMIC_CRC_TABLE + + local int crc_table_empty = 1; + local unsigned long FAR crc_table[TBLS][256]; + local void make_crc_table OF((void)); + #ifdef MAKECRCH + local void write_table OF((FILE *, const unsigned long FAR *)); + #endif /* MAKECRCH */ + + /* + Generate tables for a byte-wise 32-bit CRC calculation on the polynomial: + x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1. + + Polynomials over GF(2) are represented in binary, one bit per coefficient, + with the lowest powers in the most significant bit. Then adding polynomials + is just exclusive-or, and multiplying a polynomial by x is a right shift by + one. If we call the above polynomial p, and represent a byte as the + polynomial q, also with the lowest power in the most significant bit (so the + byte 0xb1 is the polynomial x^7+x^3+x+1), then the CRC is (q*x^32) mod p, + where a mod b means the remainder after dividing a by b. + + This calculation is done using the shift-register method of multiplying and + taking the remainder. The register is initialized to zero, and for each + incoming bit, x^32 is added mod p to the register if the bit is a one (where + x^32 mod p is p+x^32 = x^26+...+1), and the register is multiplied mod p by + x (which is shifting right by one and adding x^32 mod p if the bit shifted + out is a one). We start with the highest power (least significant bit) of + q and repeat for all eight bits of q. + + The first table is simply the CRC of all possible eight bit values. This is + all the information needed to generate CRCs on data a byte at a time for all + combinations of CRC register values and incoming bytes. The remaining tables + allow for word-at-a-time CRC calculation for both big-endian and little- + endian machines, where a word is four bytes. + */ + local void make_crc_table() + { + unsigned long c; + int n, k; + unsigned long poly; /* polynomial exclusive-or pattern */ + /* terms of polynomial defining this crc (except x^32): */ + static const unsigned char p[] = {0,1,2,4,5,7,8,10,11,12,16,22,23,26}; + + /* make exclusive-or pattern from polynomial (0xedb88320UL) */ + poly = 0UL; + for (n = 0; n < sizeof(p)/sizeof(unsigned char); n++) + poly |= 1UL << (31 - p[n]); + + /* generate a crc for every 8-bit value */ + for (n = 0; n < 256; n++) { + c = (unsigned long)n; + for (k = 0; k < 8; k++) + c = c & 1 ? poly ^ (c >> 1) : c >> 1; + crc_table[0][n] = c; + } + + #ifdef BYFOUR + /* generate crc for each value followed by one, two, and three zeros, and + then the byte reversal of those as well as the first table */ + for (n = 0; n < 256; n++) { + c = crc_table[0][n]; + crc_table[4][n] = REV(c); + for (k = 1; k < 4; k++) { + c = crc_table[0][c & 0xff] ^ (c >> 8); + crc_table[k][n] = c; + crc_table[k + 4][n] = REV(c); + } + } + #endif /* BYFOUR */ + + crc_table_empty = 0; + + #ifdef MAKECRCH + /* write out CRC tables to crc32.h */ + { + FILE *out; + + out = fopen("crc32.h", "w"); + if (out == NULL) return; + fprintf(out, "/* crc32.h -- tables for rapid CRC calculation\n"); + fprintf(out, " * Generated automatically by crc32.c\n */\n\n"); + fprintf(out, "local const unsigned long FAR "); + fprintf(out, "crc_table[TBLS][256] =\n{\n {\n"); + write_table(out, crc_table[0]); + # ifdef BYFOUR + fprintf(out, "#ifdef BYFOUR\n"); + for (k = 1; k < 8; k++) { + fprintf(out, " },\n {\n"); + write_table(out, crc_table[k]); + } + fprintf(out, "#endif\n"); + # endif /* BYFOUR */ + fprintf(out, " }\n};\n"); + fclose(out); + } + #endif /* MAKECRCH */ + } + + #ifdef MAKECRCH + local void write_table(out, table) + FILE *out; + const unsigned long FAR *table; + { + int n; + + for (n = 0; n < 256; n++) + fprintf(out, "%s0x%08lxUL%s", n % 5 ? "" : " ", table[n], + n == 255 ? "\n" : (n % 5 == 4 ? ",\n" : ", ")); + } + #endif /* MAKECRCH */ + + #else /* !DYNAMIC_CRC_TABLE */ + /* ======================================================================== + * Tables of CRC-32s of all single-byte values, made by make_crc_table(). + */ + #include "crc32.h" + #endif /* DYNAMIC_CRC_TABLE */ + + /* ========================================================================= + * This function can be used by asm versions of crc32() + */ + const unsigned long FAR * ZEXPORT get_crc_table() + { + #ifdef DYNAMIC_CRC_TABLE + if (crc_table_empty) make_crc_table(); + #endif /* DYNAMIC_CRC_TABLE */ + return (const unsigned long FAR *)crc_table; + } + + /* ========================================================================= */ + #define DO1 crc = crc_table[0][((int)crc ^ (*buf++)) & 0xff] ^ (crc >> 8) + #define DO8 DO1; DO1; DO1; DO1; DO1; DO1; DO1; DO1 + + /* ========================================================================= */ + unsigned long ZEXPORT crc32(crc, buf, len) + unsigned long crc; + const unsigned char FAR *buf; + unsigned len; + { + if (buf == Z_NULL) return 0UL; + + #ifdef DYNAMIC_CRC_TABLE + if (crc_table_empty) + make_crc_table(); + #endif /* DYNAMIC_CRC_TABLE */ + + #ifdef BYFOUR + if (sizeof(void *) == sizeof(ptrdiff_t)) { + u4 endian; + + endian = 1; + if (*((unsigned char *)(&endian))) + return crc32_little(crc, buf, len); + else + return crc32_big(crc, buf, len); + } + #endif /* BYFOUR */ + crc = crc ^ 0xffffffffUL; + while (len >= 8) { + DO8; + len -= 8; + } + if (len) do { + DO1; + } while (--len); + return crc ^ 0xffffffffUL; + } + + #ifdef BYFOUR + + /* ========================================================================= */ + #define DOLIT4 c ^= *buf4++; \ + c = crc_table[3][c & 0xff] ^ crc_table[2][(c >> 8) & 0xff] ^ \ + crc_table[1][(c >> 16) & 0xff] ^ crc_table[0][c >> 24] + #define DOLIT32 DOLIT4; DOLIT4; DOLIT4; DOLIT4; DOLIT4; DOLIT4; DOLIT4; DOLIT4 + + /* ========================================================================= */ + local unsigned long crc32_little(crc, buf, len) + unsigned long crc; + const unsigned char FAR *buf; + unsigned len; + { + register u4 c; + register const u4 FAR *buf4; + + c = (u4)crc; + c = ~c; + while (len && ((ptrdiff_t)buf & 3)) { + c = crc_table[0][(c ^ *buf++) & 0xff] ^ (c >> 8); + len--; + } + + buf4 = (const u4 FAR *)buf; + while (len >= 32) { + DOLIT32; + len -= 32; + } + while (len >= 4) { + DOLIT4; + len -= 4; + } + buf = (const unsigned char FAR *)buf4; + + if (len) do { + c = crc_table[0][(c ^ *buf++) & 0xff] ^ (c >> 8); + } while (--len); + c = ~c; + return (unsigned long)c; + } + + /* ========================================================================= */ + #define DOBIG4 c ^= *++buf4; \ + c = crc_table[4][c & 0xff] ^ crc_table[5][(c >> 8) & 0xff] ^ \ + crc_table[6][(c >> 16) & 0xff] ^ crc_table[7][c >> 24] + #define DOBIG32 DOBIG4; DOBIG4; DOBIG4; DOBIG4; DOBIG4; DOBIG4; DOBIG4; DOBIG4 + + /* ========================================================================= */ + local unsigned long crc32_big(crc, buf, len) + unsigned long crc; + const unsigned char FAR *buf; + unsigned len; + { + register u4 c; + register const u4 FAR *buf4; + + c = REV((u4)crc); + c = ~c; + while (len && ((ptrdiff_t)buf & 3)) { + c = crc_table[4][(c >> 24) ^ *buf++] ^ (c << 8); + len--; + } + + buf4 = (const u4 FAR *)buf; + buf4--; + while (len >= 32) { + DOBIG32; + len -= 32; + } + while (len >= 4) { + DOBIG4; + len -= 4; + } + buf4++; + buf = (const unsigned char FAR *)buf4; + + if (len) do { + c = crc_table[4][(c >> 24) ^ *buf++] ^ (c << 8); + } while (--len); + c = ~c; + return (unsigned long)(REV(c)); + } + + #endif /* BYFOUR */ Index: llvm-test/Runtime/zlib/crc32.h diff -c /dev/null llvm-test/Runtime/zlib/crc32.h:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/crc32.h Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,441 ---- + /* crc32.h -- tables for rapid CRC calculation + * Generated automatically by crc32.c + */ + + local const unsigned long FAR crc_table[TBLS][256] = + { + { + 0x00000000UL, 0x77073096UL, 0xee0e612cUL, 0x990951baUL, 0x076dc419UL, + 0x706af48fUL, 0xe963a535UL, 0x9e6495a3UL, 0x0edb8832UL, 0x79dcb8a4UL, + 0xe0d5e91eUL, 0x97d2d988UL, 0x09b64c2bUL, 0x7eb17cbdUL, 0xe7b82d07UL, + 0x90bf1d91UL, 0x1db71064UL, 0x6ab020f2UL, 0xf3b97148UL, 0x84be41deUL, + 0x1adad47dUL, 0x6ddde4ebUL, 0xf4d4b551UL, 0x83d385c7UL, 0x136c9856UL, + 0x646ba8c0UL, 0xfd62f97aUL, 0x8a65c9ecUL, 0x14015c4fUL, 0x63066cd9UL, + 0xfa0f3d63UL, 0x8d080df5UL, 0x3b6e20c8UL, 0x4c69105eUL, 0xd56041e4UL, + 0xa2677172UL, 0x3c03e4d1UL, 0x4b04d447UL, 0xd20d85fdUL, 0xa50ab56bUL, + 0x35b5a8faUL, 0x42b2986cUL, 0xdbbbc9d6UL, 0xacbcf940UL, 0x32d86ce3UL, + 0x45df5c75UL, 0xdcd60dcfUL, 0xabd13d59UL, 0x26d930acUL, 0x51de003aUL, + 0xc8d75180UL, 0xbfd06116UL, 0x21b4f4b5UL, 0x56b3c423UL, 0xcfba9599UL, + 0xb8bda50fUL, 0x2802b89eUL, 0x5f058808UL, 0xc60cd9b2UL, 0xb10be924UL, + 0x2f6f7c87UL, 0x58684c11UL, 0xc1611dabUL, 0xb6662d3dUL, 0x76dc4190UL, + 0x01db7106UL, 0x98d220bcUL, 0xefd5102aUL, 0x71b18589UL, 0x06b6b51fUL, + 0x9fbfe4a5UL, 0xe8b8d433UL, 0x7807c9a2UL, 0x0f00f934UL, 0x9609a88eUL, + 0xe10e9818UL, 0x7f6a0dbbUL, 0x086d3d2dUL, 0x91646c97UL, 0xe6635c01UL, + 0x6b6b51f4UL, 0x1c6c6162UL, 0x856530d8UL, 0xf262004eUL, 0x6c0695edUL, + 0x1b01a57bUL, 0x8208f4c1UL, 0xf50fc457UL, 0x65b0d9c6UL, 0x12b7e950UL, + 0x8bbeb8eaUL, 0xfcb9887cUL, 0x62dd1ddfUL, 0x15da2d49UL, 0x8cd37cf3UL, + 0xfbd44c65UL, 0x4db26158UL, 0x3ab551ceUL, 0xa3bc0074UL, 0xd4bb30e2UL, + 0x4adfa541UL, 0x3dd895d7UL, 0xa4d1c46dUL, 0xd3d6f4fbUL, 0x4369e96aUL, + 0x346ed9fcUL, 0xad678846UL, 0xda60b8d0UL, 0x44042d73UL, 0x33031de5UL, + 0xaa0a4c5fUL, 0xdd0d7cc9UL, 0x5005713cUL, 0x270241aaUL, 0xbe0b1010UL, + 0xc90c2086UL, 0x5768b525UL, 0x206f85b3UL, 0xb966d409UL, 0xce61e49fUL, + 0x5edef90eUL, 0x29d9c998UL, 0xb0d09822UL, 0xc7d7a8b4UL, 0x59b33d17UL, + 0x2eb40d81UL, 0xb7bd5c3bUL, 0xc0ba6cadUL, 0xedb88320UL, 0x9abfb3b6UL, + 0x03b6e20cUL, 0x74b1d29aUL, 0xead54739UL, 0x9dd277afUL, 0x04db2615UL, + 0x73dc1683UL, 0xe3630b12UL, 0x94643b84UL, 0x0d6d6a3eUL, 0x7a6a5aa8UL, + 0xe40ecf0bUL, 0x9309ff9dUL, 0x0a00ae27UL, 0x7d079eb1UL, 0xf00f9344UL, + 0x8708a3d2UL, 0x1e01f268UL, 0x6906c2feUL, 0xf762575dUL, 0x806567cbUL, + 0x196c3671UL, 0x6e6b06e7UL, 0xfed41b76UL, 0x89d32be0UL, 0x10da7a5aUL, + 0x67dd4accUL, 0xf9b9df6fUL, 0x8ebeeff9UL, 0x17b7be43UL, 0x60b08ed5UL, + 0xd6d6a3e8UL, 0xa1d1937eUL, 0x38d8c2c4UL, 0x4fdff252UL, 0xd1bb67f1UL, + 0xa6bc5767UL, 0x3fb506ddUL, 0x48b2364bUL, 0xd80d2bdaUL, 0xaf0a1b4cUL, + 0x36034af6UL, 0x41047a60UL, 0xdf60efc3UL, 0xa867df55UL, 0x316e8eefUL, + 0x4669be79UL, 0xcb61b38cUL, 0xbc66831aUL, 0x256fd2a0UL, 0x5268e236UL, + 0xcc0c7795UL, 0xbb0b4703UL, 0x220216b9UL, 0x5505262fUL, 0xc5ba3bbeUL, + 0xb2bd0b28UL, 0x2bb45a92UL, 0x5cb36a04UL, 0xc2d7ffa7UL, 0xb5d0cf31UL, + 0x2cd99e8bUL, 0x5bdeae1dUL, 0x9b64c2b0UL, 0xec63f226UL, 0x756aa39cUL, + 0x026d930aUL, 0x9c0906a9UL, 0xeb0e363fUL, 0x72076785UL, 0x05005713UL, + 0x95bf4a82UL, 0xe2b87a14UL, 0x7bb12baeUL, 0x0cb61b38UL, 0x92d28e9bUL, + 0xe5d5be0dUL, 0x7cdcefb7UL, 0x0bdbdf21UL, 0x86d3d2d4UL, 0xf1d4e242UL, + 0x68ddb3f8UL, 0x1fda836eUL, 0x81be16cdUL, 0xf6b9265bUL, 0x6fb077e1UL, + 0x18b74777UL, 0x88085ae6UL, 0xff0f6a70UL, 0x66063bcaUL, 0x11010b5cUL, + 0x8f659effUL, 0xf862ae69UL, 0x616bffd3UL, 0x166ccf45UL, 0xa00ae278UL, + 0xd70dd2eeUL, 0x4e048354UL, 0x3903b3c2UL, 0xa7672661UL, 0xd06016f7UL, + 0x4969474dUL, 0x3e6e77dbUL, 0xaed16a4aUL, 0xd9d65adcUL, 0x40df0b66UL, + 0x37d83bf0UL, 0xa9bcae53UL, 0xdebb9ec5UL, 0x47b2cf7fUL, 0x30b5ffe9UL, + 0xbdbdf21cUL, 0xcabac28aUL, 0x53b39330UL, 0x24b4a3a6UL, 0xbad03605UL, + 0xcdd70693UL, 0x54de5729UL, 0x23d967bfUL, 0xb3667a2eUL, 0xc4614ab8UL, + 0x5d681b02UL, 0x2a6f2b94UL, 0xb40bbe37UL, 0xc30c8ea1UL, 0x5a05df1bUL, + 0x2d02ef8dUL + #ifdef BYFOUR + }, + { + 0x00000000UL, 0x191b3141UL, 0x32366282UL, 0x2b2d53c3UL, 0x646cc504UL, + 0x7d77f445UL, 0x565aa786UL, 0x4f4196c7UL, 0xc8d98a08UL, 0xd1c2bb49UL, + 0xfaefe88aUL, 0xe3f4d9cbUL, 0xacb54f0cUL, 0xb5ae7e4dUL, 0x9e832d8eUL, + 0x87981ccfUL, 0x4ac21251UL, 0x53d92310UL, 0x78f470d3UL, 0x61ef4192UL, + 0x2eaed755UL, 0x37b5e614UL, 0x1c98b5d7UL, 0x05838496UL, 0x821b9859UL, + 0x9b00a918UL, 0xb02dfadbUL, 0xa936cb9aUL, 0xe6775d5dUL, 0xff6c6c1cUL, + 0xd4413fdfUL, 0xcd5a0e9eUL, 0x958424a2UL, 0x8c9f15e3UL, 0xa7b24620UL, + 0xbea97761UL, 0xf1e8e1a6UL, 0xe8f3d0e7UL, 0xc3de8324UL, 0xdac5b265UL, + 0x5d5daeaaUL, 0x44469febUL, 0x6f6bcc28UL, 0x7670fd69UL, 0x39316baeUL, + 0x202a5aefUL, 0x0b07092cUL, 0x121c386dUL, 0xdf4636f3UL, 0xc65d07b2UL, + 0xed705471UL, 0xf46b6530UL, 0xbb2af3f7UL, 0xa231c2b6UL, 0x891c9175UL, + 0x9007a034UL, 0x179fbcfbUL, 0x0e848dbaUL, 0x25a9de79UL, 0x3cb2ef38UL, + 0x73f379ffUL, 0x6ae848beUL, 0x41c51b7dUL, 0x58de2a3cUL, 0xf0794f05UL, + 0xe9627e44UL, 0xc24f2d87UL, 0xdb541cc6UL, 0x94158a01UL, 0x8d0ebb40UL, + 0xa623e883UL, 0xbf38d9c2UL, 0x38a0c50dUL, 0x21bbf44cUL, 0x0a96a78fUL, + 0x138d96ceUL, 0x5ccc0009UL, 0x45d73148UL, 0x6efa628bUL, 0x77e153caUL, + 0xbabb5d54UL, 0xa3a06c15UL, 0x888d3fd6UL, 0x91960e97UL, 0xded79850UL, + 0xc7cca911UL, 0xece1fad2UL, 0xf5facb93UL, 0x7262d75cUL, 0x6b79e61dUL, + 0x4054b5deUL, 0x594f849fUL, 0x160e1258UL, 0x0f152319UL, 0x243870daUL, + 0x3d23419bUL, 0x65fd6ba7UL, 0x7ce65ae6UL, 0x57cb0925UL, 0x4ed03864UL, + 0x0191aea3UL, 0x188a9fe2UL, 0x33a7cc21UL, 0x2abcfd60UL, 0xad24e1afUL, + 0xb43fd0eeUL, 0x9f12832dUL, 0x8609b26cUL, 0xc94824abUL, 0xd05315eaUL, + 0xfb7e4629UL, 0xe2657768UL, 0x2f3f79f6UL, 0x362448b7UL, 0x1d091b74UL, + 0x04122a35UL, 0x4b53bcf2UL, 0x52488db3UL, 0x7965de70UL, 0x607eef31UL, + 0xe7e6f3feUL, 0xfefdc2bfUL, 0xd5d0917cUL, 0xcccba03dUL, 0x838a36faUL, + 0x9a9107bbUL, 0xb1bc5478UL, 0xa8a76539UL, 0x3b83984bUL, 0x2298a90aUL, + 0x09b5fac9UL, 0x10aecb88UL, 0x5fef5d4fUL, 0x46f46c0eUL, 0x6dd93fcdUL, + 0x74c20e8cUL, 0xf35a1243UL, 0xea412302UL, 0xc16c70c1UL, 0xd8774180UL, + 0x9736d747UL, 0x8e2de606UL, 0xa500b5c5UL, 0xbc1b8484UL, 0x71418a1aUL, + 0x685abb5bUL, 0x4377e898UL, 0x5a6cd9d9UL, 0x152d4f1eUL, 0x0c367e5fUL, + 0x271b2d9cUL, 0x3e001cddUL, 0xb9980012UL, 0xa0833153UL, 0x8bae6290UL, + 0x92b553d1UL, 0xddf4c516UL, 0xc4eff457UL, 0xefc2a794UL, 0xf6d996d5UL, + 0xae07bce9UL, 0xb71c8da8UL, 0x9c31de6bUL, 0x852aef2aUL, 0xca6b79edUL, + 0xd37048acUL, 0xf85d1b6fUL, 0xe1462a2eUL, 0x66de36e1UL, 0x7fc507a0UL, + 0x54e85463UL, 0x4df36522UL, 0x02b2f3e5UL, 0x1ba9c2a4UL, 0x30849167UL, + 0x299fa026UL, 0xe4c5aeb8UL, 0xfdde9ff9UL, 0xd6f3cc3aUL, 0xcfe8fd7bUL, + 0x80a96bbcUL, 0x99b25afdUL, 0xb29f093eUL, 0xab84387fUL, 0x2c1c24b0UL, + 0x350715f1UL, 0x1e2a4632UL, 0x07317773UL, 0x4870e1b4UL, 0x516bd0f5UL, + 0x7a468336UL, 0x635db277UL, 0xcbfad74eUL, 0xd2e1e60fUL, 0xf9ccb5ccUL, + 0xe0d7848dUL, 0xaf96124aUL, 0xb68d230bUL, 0x9da070c8UL, 0x84bb4189UL, + 0x03235d46UL, 0x1a386c07UL, 0x31153fc4UL, 0x280e0e85UL, 0x674f9842UL, + 0x7e54a903UL, 0x5579fac0UL, 0x4c62cb81UL, 0x8138c51fUL, 0x9823f45eUL, + 0xb30ea79dUL, 0xaa1596dcUL, 0xe554001bUL, 0xfc4f315aUL, 0xd7626299UL, + 0xce7953d8UL, 0x49e14f17UL, 0x50fa7e56UL, 0x7bd72d95UL, 0x62cc1cd4UL, + 0x2d8d8a13UL, 0x3496bb52UL, 0x1fbbe891UL, 0x06a0d9d0UL, 0x5e7ef3ecUL, + 0x4765c2adUL, 0x6c48916eUL, 0x7553a02fUL, 0x3a1236e8UL, 0x230907a9UL, + 0x0824546aUL, 0x113f652bUL, 0x96a779e4UL, 0x8fbc48a5UL, 0xa4911b66UL, + 0xbd8a2a27UL, 0xf2cbbce0UL, 0xebd08da1UL, 0xc0fdde62UL, 0xd9e6ef23UL, + 0x14bce1bdUL, 0x0da7d0fcUL, 0x268a833fUL, 0x3f91b27eUL, 0x70d024b9UL, + 0x69cb15f8UL, 0x42e6463bUL, 0x5bfd777aUL, 0xdc656bb5UL, 0xc57e5af4UL, + 0xee530937UL, 0xf7483876UL, 0xb809aeb1UL, 0xa1129ff0UL, 0x8a3fcc33UL, + 0x9324fd72UL + }, + { + 0x00000000UL, 0x01c26a37UL, 0x0384d46eUL, 0x0246be59UL, 0x0709a8dcUL, + 0x06cbc2ebUL, 0x048d7cb2UL, 0x054f1685UL, 0x0e1351b8UL, 0x0fd13b8fUL, + 0x0d9785d6UL, 0x0c55efe1UL, 0x091af964UL, 0x08d89353UL, 0x0a9e2d0aUL, + 0x0b5c473dUL, 0x1c26a370UL, 0x1de4c947UL, 0x1fa2771eUL, 0x1e601d29UL, + 0x1b2f0bacUL, 0x1aed619bUL, 0x18abdfc2UL, 0x1969b5f5UL, 0x1235f2c8UL, + 0x13f798ffUL, 0x11b126a6UL, 0x10734c91UL, 0x153c5a14UL, 0x14fe3023UL, + 0x16b88e7aUL, 0x177ae44dUL, 0x384d46e0UL, 0x398f2cd7UL, 0x3bc9928eUL, + 0x3a0bf8b9UL, 0x3f44ee3cUL, 0x3e86840bUL, 0x3cc03a52UL, 0x3d025065UL, + 0x365e1758UL, 0x379c7d6fUL, 0x35dac336UL, 0x3418a901UL, 0x3157bf84UL, + 0x3095d5b3UL, 0x32d36beaUL, 0x331101ddUL, 0x246be590UL, 0x25a98fa7UL, + 0x27ef31feUL, 0x262d5bc9UL, 0x23624d4cUL, 0x22a0277bUL, 0x20e69922UL, + 0x2124f315UL, 0x2a78b428UL, 0x2bbade1fUL, 0x29fc6046UL, 0x283e0a71UL, + 0x2d711cf4UL, 0x2cb376c3UL, 0x2ef5c89aUL, 0x2f37a2adUL, 0x709a8dc0UL, + 0x7158e7f7UL, 0x731e59aeUL, 0x72dc3399UL, 0x7793251cUL, 0x76514f2bUL, + 0x7417f172UL, 0x75d59b45UL, 0x7e89dc78UL, 0x7f4bb64fUL, 0x7d0d0816UL, + 0x7ccf6221UL, 0x798074a4UL, 0x78421e93UL, 0x7a04a0caUL, 0x7bc6cafdUL, + 0x6cbc2eb0UL, 0x6d7e4487UL, 0x6f38fadeUL, 0x6efa90e9UL, 0x6bb5866cUL, + 0x6a77ec5bUL, 0x68315202UL, 0x69f33835UL, 0x62af7f08UL, 0x636d153fUL, + 0x612bab66UL, 0x60e9c151UL, 0x65a6d7d4UL, 0x6464bde3UL, 0x662203baUL, + 0x67e0698dUL, 0x48d7cb20UL, 0x4915a117UL, 0x4b531f4eUL, 0x4a917579UL, + 0x4fde63fcUL, 0x4e1c09cbUL, 0x4c5ab792UL, 0x4d98dda5UL, 0x46c49a98UL, + 0x4706f0afUL, 0x45404ef6UL, 0x448224c1UL, 0x41cd3244UL, 0x400f5873UL, + 0x4249e62aUL, 0x438b8c1dUL, 0x54f16850UL, 0x55330267UL, 0x5775bc3eUL, + 0x56b7d609UL, 0x53f8c08cUL, 0x523aaabbUL, 0x507c14e2UL, 0x51be7ed5UL, + 0x5ae239e8UL, 0x5b2053dfUL, 0x5966ed86UL, 0x58a487b1UL, 0x5deb9134UL, + 0x5c29fb03UL, 0x5e6f455aUL, 0x5fad2f6dUL, 0xe1351b80UL, 0xe0f771b7UL, + 0xe2b1cfeeUL, 0xe373a5d9UL, 0xe63cb35cUL, 0xe7fed96bUL, 0xe5b86732UL, + 0xe47a0d05UL, 0xef264a38UL, 0xeee4200fUL, 0xeca29e56UL, 0xed60f461UL, + 0xe82fe2e4UL, 0xe9ed88d3UL, 0xebab368aUL, 0xea695cbdUL, 0xfd13b8f0UL, + 0xfcd1d2c7UL, 0xfe976c9eUL, 0xff5506a9UL, 0xfa1a102cUL, 0xfbd87a1bUL, + 0xf99ec442UL, 0xf85cae75UL, 0xf300e948UL, 0xf2c2837fUL, 0xf0843d26UL, + 0xf1465711UL, 0xf4094194UL, 0xf5cb2ba3UL, 0xf78d95faUL, 0xf64fffcdUL, + 0xd9785d60UL, 0xd8ba3757UL, 0xdafc890eUL, 0xdb3ee339UL, 0xde71f5bcUL, + 0xdfb39f8bUL, 0xddf521d2UL, 0xdc374be5UL, 0xd76b0cd8UL, 0xd6a966efUL, + 0xd4efd8b6UL, 0xd52db281UL, 0xd062a404UL, 0xd1a0ce33UL, 0xd3e6706aUL, + 0xd2241a5dUL, 0xc55efe10UL, 0xc49c9427UL, 0xc6da2a7eUL, 0xc7184049UL, + 0xc25756ccUL, 0xc3953cfbUL, 0xc1d382a2UL, 0xc011e895UL, 0xcb4dafa8UL, + 0xca8fc59fUL, 0xc8c97bc6UL, 0xc90b11f1UL, 0xcc440774UL, 0xcd866d43UL, + 0xcfc0d31aUL, 0xce02b92dUL, 0x91af9640UL, 0x906dfc77UL, 0x922b422eUL, + 0x93e92819UL, 0x96a63e9cUL, 0x976454abUL, 0x9522eaf2UL, 0x94e080c5UL, + 0x9fbcc7f8UL, 0x9e7eadcfUL, 0x9c381396UL, 0x9dfa79a1UL, 0x98b56f24UL, + 0x99770513UL, 0x9b31bb4aUL, 0x9af3d17dUL, 0x8d893530UL, 0x8c4b5f07UL, + 0x8e0de15eUL, 0x8fcf8b69UL, 0x8a809decUL, 0x8b42f7dbUL, 0x89044982UL, + 0x88c623b5UL, 0x839a6488UL, 0x82580ebfUL, 0x801eb0e6UL, 0x81dcdad1UL, + 0x8493cc54UL, 0x8551a663UL, 0x8717183aUL, 0x86d5720dUL, 0xa9e2d0a0UL, + 0xa820ba97UL, 0xaa6604ceUL, 0xaba46ef9UL, 0xaeeb787cUL, 0xaf29124bUL, + 0xad6fac12UL, 0xacadc625UL, 0xa7f18118UL, 0xa633eb2fUL, 0xa4755576UL, + 0xa5b73f41UL, 0xa0f829c4UL, 0xa13a43f3UL, 0xa37cfdaaUL, 0xa2be979dUL, + 0xb5c473d0UL, 0xb40619e7UL, 0xb640a7beUL, 0xb782cd89UL, 0xb2cddb0cUL, + 0xb30fb13bUL, 0xb1490f62UL, 0xb08b6555UL, 0xbbd72268UL, 0xba15485fUL, + 0xb853f606UL, 0xb9919c31UL, 0xbcde8ab4UL, 0xbd1ce083UL, 0xbf5a5edaUL, + 0xbe9834edUL + }, + { + 0x00000000UL, 0xb8bc6765UL, 0xaa09c88bUL, 0x12b5afeeUL, 0x8f629757UL, + 0x37def032UL, 0x256b5fdcUL, 0x9dd738b9UL, 0xc5b428efUL, 0x7d084f8aUL, + 0x6fbde064UL, 0xd7018701UL, 0x4ad6bfb8UL, 0xf26ad8ddUL, 0xe0df7733UL, + 0x58631056UL, 0x5019579fUL, 0xe8a530faUL, 0xfa109f14UL, 0x42acf871UL, + 0xdf7bc0c8UL, 0x67c7a7adUL, 0x75720843UL, 0xcdce6f26UL, 0x95ad7f70UL, + 0x2d111815UL, 0x3fa4b7fbUL, 0x8718d09eUL, 0x1acfe827UL, 0xa2738f42UL, + 0xb0c620acUL, 0x087a47c9UL, 0xa032af3eUL, 0x188ec85bUL, 0x0a3b67b5UL, + 0xb28700d0UL, 0x2f503869UL, 0x97ec5f0cUL, 0x8559f0e2UL, 0x3de59787UL, + 0x658687d1UL, 0xdd3ae0b4UL, 0xcf8f4f5aUL, 0x7733283fUL, 0xeae41086UL, + 0x525877e3UL, 0x40edd80dUL, 0xf851bf68UL, 0xf02bf8a1UL, 0x48979fc4UL, + 0x5a22302aUL, 0xe29e574fUL, 0x7f496ff6UL, 0xc7f50893UL, 0xd540a77dUL, + 0x6dfcc018UL, 0x359fd04eUL, 0x8d23b72bUL, 0x9f9618c5UL, 0x272a7fa0UL, + 0xbafd4719UL, 0x0241207cUL, 0x10f48f92UL, 0xa848e8f7UL, 0x9b14583dUL, + 0x23a83f58UL, 0x311d90b6UL, 0x89a1f7d3UL, 0x1476cf6aUL, 0xaccaa80fUL, + 0xbe7f07e1UL, 0x06c36084UL, 0x5ea070d2UL, 0xe61c17b7UL, 0xf4a9b859UL, + 0x4c15df3cUL, 0xd1c2e785UL, 0x697e80e0UL, 0x7bcb2f0eUL, 0xc377486bUL, + 0xcb0d0fa2UL, 0x73b168c7UL, 0x6104c729UL, 0xd9b8a04cUL, 0x446f98f5UL, + 0xfcd3ff90UL, 0xee66507eUL, 0x56da371bUL, 0x0eb9274dUL, 0xb6054028UL, + 0xa4b0efc6UL, 0x1c0c88a3UL, 0x81dbb01aUL, 0x3967d77fUL, 0x2bd27891UL, + 0x936e1ff4UL, 0x3b26f703UL, 0x839a9066UL, 0x912f3f88UL, 0x299358edUL, + 0xb4446054UL, 0x0cf80731UL, 0x1e4da8dfUL, 0xa6f1cfbaUL, 0xfe92dfecUL, + 0x462eb889UL, 0x549b1767UL, 0xec277002UL, 0x71f048bbUL, 0xc94c2fdeUL, + 0xdbf98030UL, 0x6345e755UL, 0x6b3fa09cUL, 0xd383c7f9UL, 0xc1366817UL, + 0x798a0f72UL, 0xe45d37cbUL, 0x5ce150aeUL, 0x4e54ff40UL, 0xf6e89825UL, + 0xae8b8873UL, 0x1637ef16UL, 0x048240f8UL, 0xbc3e279dUL, 0x21e91f24UL, + 0x99557841UL, 0x8be0d7afUL, 0x335cb0caUL, 0xed59b63bUL, 0x55e5d15eUL, + 0x47507eb0UL, 0xffec19d5UL, 0x623b216cUL, 0xda874609UL, 0xc832e9e7UL, + 0x708e8e82UL, 0x28ed9ed4UL, 0x9051f9b1UL, 0x82e4565fUL, 0x3a58313aUL, + 0xa78f0983UL, 0x1f336ee6UL, 0x0d86c108UL, 0xb53aa66dUL, 0xbd40e1a4UL, + 0x05fc86c1UL, 0x1749292fUL, 0xaff54e4aUL, 0x322276f3UL, 0x8a9e1196UL, + 0x982bbe78UL, 0x2097d91dUL, 0x78f4c94bUL, 0xc048ae2eUL, 0xd2fd01c0UL, + 0x6a4166a5UL, 0xf7965e1cUL, 0x4f2a3979UL, 0x5d9f9697UL, 0xe523f1f2UL, + 0x4d6b1905UL, 0xf5d77e60UL, 0xe762d18eUL, 0x5fdeb6ebUL, 0xc2098e52UL, + 0x7ab5e937UL, 0x680046d9UL, 0xd0bc21bcUL, 0x88df31eaUL, 0x3063568fUL, + 0x22d6f961UL, 0x9a6a9e04UL, 0x07bda6bdUL, 0xbf01c1d8UL, 0xadb46e36UL, + 0x15080953UL, 0x1d724e9aUL, 0xa5ce29ffUL, 0xb77b8611UL, 0x0fc7e174UL, + 0x9210d9cdUL, 0x2aacbea8UL, 0x38191146UL, 0x80a57623UL, 0xd8c66675UL, + 0x607a0110UL, 0x72cfaefeUL, 0xca73c99bUL, 0x57a4f122UL, 0xef189647UL, + 0xfdad39a9UL, 0x45115eccUL, 0x764dee06UL, 0xcef18963UL, 0xdc44268dUL, + 0x64f841e8UL, 0xf92f7951UL, 0x41931e34UL, 0x5326b1daUL, 0xeb9ad6bfUL, + 0xb3f9c6e9UL, 0x0b45a18cUL, 0x19f00e62UL, 0xa14c6907UL, 0x3c9b51beUL, + 0x842736dbUL, 0x96929935UL, 0x2e2efe50UL, 0x2654b999UL, 0x9ee8defcUL, + 0x8c5d7112UL, 0x34e11677UL, 0xa9362eceUL, 0x118a49abUL, 0x033fe645UL, + 0xbb838120UL, 0xe3e09176UL, 0x5b5cf613UL, 0x49e959fdUL, 0xf1553e98UL, + 0x6c820621UL, 0xd43e6144UL, 0xc68bceaaUL, 0x7e37a9cfUL, 0xd67f4138UL, + 0x6ec3265dUL, 0x7c7689b3UL, 0xc4caeed6UL, 0x591dd66fUL, 0xe1a1b10aUL, + 0xf3141ee4UL, 0x4ba87981UL, 0x13cb69d7UL, 0xab770eb2UL, 0xb9c2a15cUL, + 0x017ec639UL, 0x9ca9fe80UL, 0x241599e5UL, 0x36a0360bUL, 0x8e1c516eUL, + 0x866616a7UL, 0x3eda71c2UL, 0x2c6fde2cUL, 0x94d3b949UL, 0x090481f0UL, + 0xb1b8e695UL, 0xa30d497bUL, 0x1bb12e1eUL, 0x43d23e48UL, 0xfb6e592dUL, + 0xe9dbf6c3UL, 0x516791a6UL, 0xccb0a91fUL, 0x740cce7aUL, 0x66b96194UL, + 0xde0506f1UL + }, + { + 0x00000000UL, 0x96300777UL, 0x2c610eeeUL, 0xba510999UL, 0x19c46d07UL, + 0x8ff46a70UL, 0x35a563e9UL, 0xa395649eUL, 0x3288db0eUL, 0xa4b8dc79UL, + 0x1ee9d5e0UL, 0x88d9d297UL, 0x2b4cb609UL, 0xbd7cb17eUL, 0x072db8e7UL, + 0x911dbf90UL, 0x6410b71dUL, 0xf220b06aUL, 0x4871b9f3UL, 0xde41be84UL, + 0x7dd4da1aUL, 0xebe4dd6dUL, 0x51b5d4f4UL, 0xc785d383UL, 0x56986c13UL, + 0xc0a86b64UL, 0x7af962fdUL, 0xecc9658aUL, 0x4f5c0114UL, 0xd96c0663UL, + 0x633d0ffaUL, 0xf50d088dUL, 0xc8206e3bUL, 0x5e10694cUL, 0xe44160d5UL, + 0x727167a2UL, 0xd1e4033cUL, 0x47d4044bUL, 0xfd850dd2UL, 0x6bb50aa5UL, + 0xfaa8b535UL, 0x6c98b242UL, 0xd6c9bbdbUL, 0x40f9bcacUL, 0xe36cd832UL, + 0x755cdf45UL, 0xcf0dd6dcUL, 0x593dd1abUL, 0xac30d926UL, 0x3a00de51UL, + 0x8051d7c8UL, 0x1661d0bfUL, 0xb5f4b421UL, 0x23c4b356UL, 0x9995bacfUL, + 0x0fa5bdb8UL, 0x9eb80228UL, 0x0888055fUL, 0xb2d90cc6UL, 0x24e90bb1UL, + 0x877c6f2fUL, 0x114c6858UL, 0xab1d61c1UL, 0x3d2d66b6UL, 0x9041dc76UL, + 0x0671db01UL, 0xbc20d298UL, 0x2a10d5efUL, 0x8985b171UL, 0x1fb5b606UL, + 0xa5e4bf9fUL, 0x33d4b8e8UL, 0xa2c90778UL, 0x34f9000fUL, 0x8ea80996UL, + 0x18980ee1UL, 0xbb0d6a7fUL, 0x2d3d6d08UL, 0x976c6491UL, 0x015c63e6UL, + 0xf4516b6bUL, 0x62616c1cUL, 0xd8306585UL, 0x4e0062f2UL, 0xed95066cUL, + 0x7ba5011bUL, 0xc1f40882UL, 0x57c40ff5UL, 0xc6d9b065UL, 0x50e9b712UL, + 0xeab8be8bUL, 0x7c88b9fcUL, 0xdf1ddd62UL, 0x492dda15UL, 0xf37cd38cUL, + 0x654cd4fbUL, 0x5861b24dUL, 0xce51b53aUL, 0x7400bca3UL, 0xe230bbd4UL, + 0x41a5df4aUL, 0xd795d83dUL, 0x6dc4d1a4UL, 0xfbf4d6d3UL, 0x6ae96943UL, + 0xfcd96e34UL, 0x468867adUL, 0xd0b860daUL, 0x732d0444UL, 0xe51d0333UL, + 0x5f4c0aaaUL, 0xc97c0dddUL, 0x3c710550UL, 0xaa410227UL, 0x10100bbeUL, + 0x86200cc9UL, 0x25b56857UL, 0xb3856f20UL, 0x09d466b9UL, 0x9fe461ceUL, + 0x0ef9de5eUL, 0x98c9d929UL, 0x2298d0b0UL, 0xb4a8d7c7UL, 0x173db359UL, + 0x810db42eUL, 0x3b5cbdb7UL, 0xad6cbac0UL, 0x2083b8edUL, 0xb6b3bf9aUL, + 0x0ce2b603UL, 0x9ad2b174UL, 0x3947d5eaUL, 0xaf77d29dUL, 0x1526db04UL, + 0x8316dc73UL, 0x120b63e3UL, 0x843b6494UL, 0x3e6a6d0dUL, 0xa85a6a7aUL, + 0x0bcf0ee4UL, 0x9dff0993UL, 0x27ae000aUL, 0xb19e077dUL, 0x44930ff0UL, + 0xd2a30887UL, 0x68f2011eUL, 0xfec20669UL, 0x5d5762f7UL, 0xcb676580UL, + 0x71366c19UL, 0xe7066b6eUL, 0x761bd4feUL, 0xe02bd389UL, 0x5a7ada10UL, + 0xcc4add67UL, 0x6fdfb9f9UL, 0xf9efbe8eUL, 0x43beb717UL, 0xd58eb060UL, + 0xe8a3d6d6UL, 0x7e93d1a1UL, 0xc4c2d838UL, 0x52f2df4fUL, 0xf167bbd1UL, + 0x6757bca6UL, 0xdd06b53fUL, 0x4b36b248UL, 0xda2b0dd8UL, 0x4c1b0aafUL, + 0xf64a0336UL, 0x607a0441UL, 0xc3ef60dfUL, 0x55df67a8UL, 0xef8e6e31UL, + 0x79be6946UL, 0x8cb361cbUL, 0x1a8366bcUL, 0xa0d26f25UL, 0x36e26852UL, + 0x95770cccUL, 0x03470bbbUL, 0xb9160222UL, 0x2f260555UL, 0xbe3bbac5UL, + 0x280bbdb2UL, 0x925ab42bUL, 0x046ab35cUL, 0xa7ffd7c2UL, 0x31cfd0b5UL, + 0x8b9ed92cUL, 0x1daede5bUL, 0xb0c2649bUL, 0x26f263ecUL, 0x9ca36a75UL, + 0x0a936d02UL, 0xa906099cUL, 0x3f360eebUL, 0x85670772UL, 0x13570005UL, + 0x824abf95UL, 0x147ab8e2UL, 0xae2bb17bUL, 0x381bb60cUL, 0x9b8ed292UL, + 0x0dbed5e5UL, 0xb7efdc7cUL, 0x21dfdb0bUL, 0xd4d2d386UL, 0x42e2d4f1UL, + 0xf8b3dd68UL, 0x6e83da1fUL, 0xcd16be81UL, 0x5b26b9f6UL, 0xe177b06fUL, + 0x7747b718UL, 0xe65a0888UL, 0x706a0fffUL, 0xca3b0666UL, 0x5c0b0111UL, + 0xff9e658fUL, 0x69ae62f8UL, 0xd3ff6b61UL, 0x45cf6c16UL, 0x78e20aa0UL, + 0xeed20dd7UL, 0x5483044eUL, 0xc2b30339UL, 0x612667a7UL, 0xf71660d0UL, + 0x4d476949UL, 0xdb776e3eUL, 0x4a6ad1aeUL, 0xdc5ad6d9UL, 0x660bdf40UL, + 0xf03bd837UL, 0x53aebca9UL, 0xc59ebbdeUL, 0x7fcfb247UL, 0xe9ffb530UL, + 0x1cf2bdbdUL, 0x8ac2bacaUL, 0x3093b353UL, 0xa6a3b424UL, 0x0536d0baUL, + 0x9306d7cdUL, 0x2957de54UL, 0xbf67d923UL, 0x2e7a66b3UL, 0xb84a61c4UL, + 0x021b685dUL, 0x942b6f2aUL, 0x37be0bb4UL, 0xa18e0cc3UL, 0x1bdf055aUL, + 0x8def022dUL + }, + { + 0x00000000UL, 0x41311b19UL, 0x82623632UL, 0xc3532d2bUL, 0x04c56c64UL, + 0x45f4777dUL, 0x86a75a56UL, 0xc796414fUL, 0x088ad9c8UL, 0x49bbc2d1UL, + 0x8ae8effaUL, 0xcbd9f4e3UL, 0x0c4fb5acUL, 0x4d7eaeb5UL, 0x8e2d839eUL, + 0xcf1c9887UL, 0x5112c24aUL, 0x1023d953UL, 0xd370f478UL, 0x9241ef61UL, + 0x55d7ae2eUL, 0x14e6b537UL, 0xd7b5981cUL, 0x96848305UL, 0x59981b82UL, + 0x18a9009bUL, 0xdbfa2db0UL, 0x9acb36a9UL, 0x5d5d77e6UL, 0x1c6c6cffUL, + 0xdf3f41d4UL, 0x9e0e5acdUL, 0xa2248495UL, 0xe3159f8cUL, 0x2046b2a7UL, + 0x6177a9beUL, 0xa6e1e8f1UL, 0xe7d0f3e8UL, 0x2483dec3UL, 0x65b2c5daUL, + 0xaaae5d5dUL, 0xeb9f4644UL, 0x28cc6b6fUL, 0x69fd7076UL, 0xae6b3139UL, + 0xef5a2a20UL, 0x2c09070bUL, 0x6d381c12UL, 0xf33646dfUL, 0xb2075dc6UL, + 0x715470edUL, 0x30656bf4UL, 0xf7f32abbUL, 0xb6c231a2UL, 0x75911c89UL, + 0x34a00790UL, 0xfbbc9f17UL, 0xba8d840eUL, 0x79dea925UL, 0x38efb23cUL, + 0xff79f373UL, 0xbe48e86aUL, 0x7d1bc541UL, 0x3c2ade58UL, 0x054f79f0UL, + 0x447e62e9UL, 0x872d4fc2UL, 0xc61c54dbUL, 0x018a1594UL, 0x40bb0e8dUL, + 0x83e823a6UL, 0xc2d938bfUL, 0x0dc5a038UL, 0x4cf4bb21UL, 0x8fa7960aUL, + 0xce968d13UL, 0x0900cc5cUL, 0x4831d745UL, 0x8b62fa6eUL, 0xca53e177UL, + 0x545dbbbaUL, 0x156ca0a3UL, 0xd63f8d88UL, 0x970e9691UL, 0x5098d7deUL, + 0x11a9ccc7UL, 0xd2fae1ecUL, 0x93cbfaf5UL, 0x5cd76272UL, 0x1de6796bUL, + 0xdeb55440UL, 0x9f844f59UL, 0x58120e16UL, 0x1923150fUL, 0xda703824UL, + 0x9b41233dUL, 0xa76bfd65UL, 0xe65ae67cUL, 0x2509cb57UL, 0x6438d04eUL, + 0xa3ae9101UL, 0xe29f8a18UL, 0x21cca733UL, 0x60fdbc2aUL, 0xafe124adUL, + 0xeed03fb4UL, 0x2d83129fUL, 0x6cb20986UL, 0xab2448c9UL, 0xea1553d0UL, + 0x29467efbUL, 0x687765e2UL, 0xf6793f2fUL, 0xb7482436UL, 0x741b091dUL, + 0x352a1204UL, 0xf2bc534bUL, 0xb38d4852UL, 0x70de6579UL, 0x31ef7e60UL, + 0xfef3e6e7UL, 0xbfc2fdfeUL, 0x7c91d0d5UL, 0x3da0cbccUL, 0xfa368a83UL, + 0xbb07919aUL, 0x7854bcb1UL, 0x3965a7a8UL, 0x4b98833bUL, 0x0aa99822UL, + 0xc9fab509UL, 0x88cbae10UL, 0x4f5def5fUL, 0x0e6cf446UL, 0xcd3fd96dUL, + 0x8c0ec274UL, 0x43125af3UL, 0x022341eaUL, 0xc1706cc1UL, 0x804177d8UL, + 0x47d73697UL, 0x06e62d8eUL, 0xc5b500a5UL, 0x84841bbcUL, 0x1a8a4171UL, + 0x5bbb5a68UL, 0x98e87743UL, 0xd9d96c5aUL, 0x1e4f2d15UL, 0x5f7e360cUL, + 0x9c2d1b27UL, 0xdd1c003eUL, 0x120098b9UL, 0x533183a0UL, 0x9062ae8bUL, + 0xd153b592UL, 0x16c5f4ddUL, 0x57f4efc4UL, 0x94a7c2efUL, 0xd596d9f6UL, + 0xe9bc07aeUL, 0xa88d1cb7UL, 0x6bde319cUL, 0x2aef2a85UL, 0xed796bcaUL, + 0xac4870d3UL, 0x6f1b5df8UL, 0x2e2a46e1UL, 0xe136de66UL, 0xa007c57fUL, + 0x6354e854UL, 0x2265f34dUL, 0xe5f3b202UL, 0xa4c2a91bUL, 0x67918430UL, + 0x26a09f29UL, 0xb8aec5e4UL, 0xf99fdefdUL, 0x3accf3d6UL, 0x7bfde8cfUL, + 0xbc6ba980UL, 0xfd5ab299UL, 0x3e099fb2UL, 0x7f3884abUL, 0xb0241c2cUL, + 0xf1150735UL, 0x32462a1eUL, 0x73773107UL, 0xb4e17048UL, 0xf5d06b51UL, + 0x3683467aUL, 0x77b25d63UL, 0x4ed7facbUL, 0x0fe6e1d2UL, 0xccb5ccf9UL, + 0x8d84d7e0UL, 0x4a1296afUL, 0x0b238db6UL, 0xc870a09dUL, 0x8941bb84UL, + 0x465d2303UL, 0x076c381aUL, 0xc43f1531UL, 0x850e0e28UL, 0x42984f67UL, + 0x03a9547eUL, 0xc0fa7955UL, 0x81cb624cUL, 0x1fc53881UL, 0x5ef42398UL, + 0x9da70eb3UL, 0xdc9615aaUL, 0x1b0054e5UL, 0x5a314ffcUL, 0x996262d7UL, + 0xd85379ceUL, 0x174fe149UL, 0x567efa50UL, 0x952dd77bUL, 0xd41ccc62UL, + 0x138a8d2dUL, 0x52bb9634UL, 0x91e8bb1fUL, 0xd0d9a006UL, 0xecf37e5eUL, + 0xadc26547UL, 0x6e91486cUL, 0x2fa05375UL, 0xe836123aUL, 0xa9070923UL, + 0x6a542408UL, 0x2b653f11UL, 0xe479a796UL, 0xa548bc8fUL, 0x661b91a4UL, + 0x272a8abdUL, 0xe0bccbf2UL, 0xa18dd0ebUL, 0x62defdc0UL, 0x23efe6d9UL, + 0xbde1bc14UL, 0xfcd0a70dUL, 0x3f838a26UL, 0x7eb2913fUL, 0xb924d070UL, + 0xf815cb69UL, 0x3b46e642UL, 0x7a77fd5bUL, 0xb56b65dcUL, 0xf45a7ec5UL, + 0x370953eeUL, 0x763848f7UL, 0xb1ae09b8UL, 0xf09f12a1UL, 0x33cc3f8aUL, + 0x72fd2493UL + }, + { + 0x00000000UL, 0x376ac201UL, 0x6ed48403UL, 0x59be4602UL, 0xdca80907UL, + 0xebc2cb06UL, 0xb27c8d04UL, 0x85164f05UL, 0xb851130eUL, 0x8f3bd10fUL, + 0xd685970dUL, 0xe1ef550cUL, 0x64f91a09UL, 0x5393d808UL, 0x0a2d9e0aUL, + 0x3d475c0bUL, 0x70a3261cUL, 0x47c9e41dUL, 0x1e77a21fUL, 0x291d601eUL, + 0xac0b2f1bUL, 0x9b61ed1aUL, 0xc2dfab18UL, 0xf5b56919UL, 0xc8f23512UL, + 0xff98f713UL, 0xa626b111UL, 0x914c7310UL, 0x145a3c15UL, 0x2330fe14UL, + 0x7a8eb816UL, 0x4de47a17UL, 0xe0464d38UL, 0xd72c8f39UL, 0x8e92c93bUL, + 0xb9f80b3aUL, 0x3cee443fUL, 0x0b84863eUL, 0x523ac03cUL, 0x6550023dUL, + 0x58175e36UL, 0x6f7d9c37UL, 0x36c3da35UL, 0x01a91834UL, 0x84bf5731UL, + 0xb3d59530UL, 0xea6bd332UL, 0xdd011133UL, 0x90e56b24UL, 0xa78fa925UL, + 0xfe31ef27UL, 0xc95b2d26UL, 0x4c4d6223UL, 0x7b27a022UL, 0x2299e620UL, + 0x15f32421UL, 0x28b4782aUL, 0x1fdeba2bUL, 0x4660fc29UL, 0x710a3e28UL, + 0xf41c712dUL, 0xc376b32cUL, 0x9ac8f52eUL, 0xada2372fUL, 0xc08d9a70UL, + 0xf7e75871UL, 0xae591e73UL, 0x9933dc72UL, 0x1c259377UL, 0x2b4f5176UL, + 0x72f11774UL, 0x459bd575UL, 0x78dc897eUL, 0x4fb64b7fUL, 0x16080d7dUL, + 0x2162cf7cUL, 0xa4748079UL, 0x931e4278UL, 0xcaa0047aUL, 0xfdcac67bUL, + 0xb02ebc6cUL, 0x87447e6dUL, 0xdefa386fUL, 0xe990fa6eUL, 0x6c86b56bUL, + 0x5bec776aUL, 0x02523168UL, 0x3538f369UL, 0x087faf62UL, 0x3f156d63UL, + 0x66ab2b61UL, 0x51c1e960UL, 0xd4d7a665UL, 0xe3bd6464UL, 0xba032266UL, + 0x8d69e067UL, 0x20cbd748UL, 0x17a11549UL, 0x4e1f534bUL, 0x7975914aUL, + 0xfc63de4fUL, 0xcb091c4eUL, 0x92b75a4cUL, 0xa5dd984dUL, 0x989ac446UL, + 0xaff00647UL, 0xf64e4045UL, 0xc1248244UL, 0x4432cd41UL, 0x73580f40UL, + 0x2ae64942UL, 0x1d8c8b43UL, 0x5068f154UL, 0x67023355UL, 0x3ebc7557UL, + 0x09d6b756UL, 0x8cc0f853UL, 0xbbaa3a52UL, 0xe2147c50UL, 0xd57ebe51UL, + 0xe839e25aUL, 0xdf53205bUL, 0x86ed6659UL, 0xb187a458UL, 0x3491eb5dUL, + 0x03fb295cUL, 0x5a456f5eUL, 0x6d2fad5fUL, 0x801b35e1UL, 0xb771f7e0UL, + 0xeecfb1e2UL, 0xd9a573e3UL, 0x5cb33ce6UL, 0x6bd9fee7UL, 0x3267b8e5UL, + 0x050d7ae4UL, 0x384a26efUL, 0x0f20e4eeUL, 0x569ea2ecUL, 0x61f460edUL, + 0xe4e22fe8UL, 0xd388ede9UL, 0x8a36abebUL, 0xbd5c69eaUL, 0xf0b813fdUL, + 0xc7d2d1fcUL, 0x9e6c97feUL, 0xa90655ffUL, 0x2c101afaUL, 0x1b7ad8fbUL, + 0x42c49ef9UL, 0x75ae5cf8UL, 0x48e900f3UL, 0x7f83c2f2UL, 0x263d84f0UL, + 0x115746f1UL, 0x944109f4UL, 0xa32bcbf5UL, 0xfa958df7UL, 0xcdff4ff6UL, + 0x605d78d9UL, 0x5737bad8UL, 0x0e89fcdaUL, 0x39e33edbUL, 0xbcf571deUL, + 0x8b9fb3dfUL, 0xd221f5ddUL, 0xe54b37dcUL, 0xd80c6bd7UL, 0xef66a9d6UL, + 0xb6d8efd4UL, 0x81b22dd5UL, 0x04a462d0UL, 0x33cea0d1UL, 0x6a70e6d3UL, + 0x5d1a24d2UL, 0x10fe5ec5UL, 0x27949cc4UL, 0x7e2adac6UL, 0x494018c7UL, + 0xcc5657c2UL, 0xfb3c95c3UL, 0xa282d3c1UL, 0x95e811c0UL, 0xa8af4dcbUL, + 0x9fc58fcaUL, 0xc67bc9c8UL, 0xf1110bc9UL, 0x740744ccUL, 0x436d86cdUL, + 0x1ad3c0cfUL, 0x2db902ceUL, 0x4096af91UL, 0x77fc6d90UL, 0x2e422b92UL, + 0x1928e993UL, 0x9c3ea696UL, 0xab546497UL, 0xf2ea2295UL, 0xc580e094UL, + 0xf8c7bc9fUL, 0xcfad7e9eUL, 0x9613389cUL, 0xa179fa9dUL, 0x246fb598UL, + 0x13057799UL, 0x4abb319bUL, 0x7dd1f39aUL, 0x3035898dUL, 0x075f4b8cUL, + 0x5ee10d8eUL, 0x698bcf8fUL, 0xec9d808aUL, 0xdbf7428bUL, 0x82490489UL, + 0xb523c688UL, 0x88649a83UL, 0xbf0e5882UL, 0xe6b01e80UL, 0xd1dadc81UL, + 0x54cc9384UL, 0x63a65185UL, 0x3a181787UL, 0x0d72d586UL, 0xa0d0e2a9UL, + 0x97ba20a8UL, 0xce0466aaUL, 0xf96ea4abUL, 0x7c78ebaeUL, 0x4b1229afUL, + 0x12ac6fadUL, 0x25c6adacUL, 0x1881f1a7UL, 0x2feb33a6UL, 0x765575a4UL, + 0x413fb7a5UL, 0xc429f8a0UL, 0xf3433aa1UL, 0xaafd7ca3UL, 0x9d97bea2UL, + 0xd073c4b5UL, 0xe71906b4UL, 0xbea740b6UL, 0x89cd82b7UL, 0x0cdbcdb2UL, + 0x3bb10fb3UL, 0x620f49b1UL, 0x55658bb0UL, 0x6822d7bbUL, 0x5f4815baUL, + 0x06f653b8UL, 0x319c91b9UL, 0xb48adebcUL, 0x83e01cbdUL, 0xda5e5abfUL, + 0xed3498beUL + }, + { + 0x00000000UL, 0x6567bcb8UL, 0x8bc809aaUL, 0xeeafb512UL, 0x5797628fUL, + 0x32f0de37UL, 0xdc5f6b25UL, 0xb938d79dUL, 0xef28b4c5UL, 0x8a4f087dUL, + 0x64e0bd6fUL, 0x018701d7UL, 0xb8bfd64aUL, 0xddd86af2UL, 0x3377dfe0UL, + 0x56106358UL, 0x9f571950UL, 0xfa30a5e8UL, 0x149f10faUL, 0x71f8ac42UL, + 0xc8c07bdfUL, 0xada7c767UL, 0x43087275UL, 0x266fcecdUL, 0x707fad95UL, + 0x1518112dUL, 0xfbb7a43fUL, 0x9ed01887UL, 0x27e8cf1aUL, 0x428f73a2UL, + 0xac20c6b0UL, 0xc9477a08UL, 0x3eaf32a0UL, 0x5bc88e18UL, 0xb5673b0aUL, + 0xd00087b2UL, 0x6938502fUL, 0x0c5fec97UL, 0xe2f05985UL, 0x8797e53dUL, + 0xd1878665UL, 0xb4e03addUL, 0x5a4f8fcfUL, 0x3f283377UL, 0x8610e4eaUL, + 0xe3775852UL, 0x0dd8ed40UL, 0x68bf51f8UL, 0xa1f82bf0UL, 0xc49f9748UL, + 0x2a30225aUL, 0x4f579ee2UL, 0xf66f497fUL, 0x9308f5c7UL, 0x7da740d5UL, + 0x18c0fc6dUL, 0x4ed09f35UL, 0x2bb7238dUL, 0xc518969fUL, 0xa07f2a27UL, + 0x1947fdbaUL, 0x7c204102UL, 0x928ff410UL, 0xf7e848a8UL, 0x3d58149bUL, + 0x583fa823UL, 0xb6901d31UL, 0xd3f7a189UL, 0x6acf7614UL, 0x0fa8caacUL, + 0xe1077fbeUL, 0x8460c306UL, 0xd270a05eUL, 0xb7171ce6UL, 0x59b8a9f4UL, + 0x3cdf154cUL, 0x85e7c2d1UL, 0xe0807e69UL, 0x0e2fcb7bUL, 0x6b4877c3UL, + 0xa20f0dcbUL, 0xc768b173UL, 0x29c70461UL, 0x4ca0b8d9UL, 0xf5986f44UL, + 0x90ffd3fcUL, 0x7e5066eeUL, 0x1b37da56UL, 0x4d27b90eUL, 0x284005b6UL, + 0xc6efb0a4UL, 0xa3880c1cUL, 0x1ab0db81UL, 0x7fd76739UL, 0x9178d22bUL, + 0xf41f6e93UL, 0x03f7263bUL, 0x66909a83UL, 0x883f2f91UL, 0xed589329UL, + 0x546044b4UL, 0x3107f80cUL, 0xdfa84d1eUL, 0xbacff1a6UL, 0xecdf92feUL, + 0x89b82e46UL, 0x67179b54UL, 0x027027ecUL, 0xbb48f071UL, 0xde2f4cc9UL, + 0x3080f9dbUL, 0x55e74563UL, 0x9ca03f6bUL, 0xf9c783d3UL, 0x176836c1UL, + 0x720f8a79UL, 0xcb375de4UL, 0xae50e15cUL, 0x40ff544eUL, 0x2598e8f6UL, + 0x73888baeUL, 0x16ef3716UL, 0xf8408204UL, 0x9d273ebcUL, 0x241fe921UL, + 0x41785599UL, 0xafd7e08bUL, 0xcab05c33UL, 0x3bb659edUL, 0x5ed1e555UL, + 0xb07e5047UL, 0xd519ecffUL, 0x6c213b62UL, 0x094687daUL, 0xe7e932c8UL, + 0x828e8e70UL, 0xd49eed28UL, 0xb1f95190UL, 0x5f56e482UL, 0x3a31583aUL, + 0x83098fa7UL, 0xe66e331fUL, 0x08c1860dUL, 0x6da63ab5UL, 0xa4e140bdUL, + 0xc186fc05UL, 0x2f294917UL, 0x4a4ef5afUL, 0xf3762232UL, 0x96119e8aUL, + 0x78be2b98UL, 0x1dd99720UL, 0x4bc9f478UL, 0x2eae48c0UL, 0xc001fdd2UL, + 0xa566416aUL, 0x1c5e96f7UL, 0x79392a4fUL, 0x97969f5dUL, 0xf2f123e5UL, + 0x05196b4dUL, 0x607ed7f5UL, 0x8ed162e7UL, 0xebb6de5fUL, 0x528e09c2UL, + 0x37e9b57aUL, 0xd9460068UL, 0xbc21bcd0UL, 0xea31df88UL, 0x8f566330UL, + 0x61f9d622UL, 0x049e6a9aUL, 0xbda6bd07UL, 0xd8c101bfUL, 0x366eb4adUL, + 0x53090815UL, 0x9a4e721dUL, 0xff29cea5UL, 0x11867bb7UL, 0x74e1c70fUL, + 0xcdd91092UL, 0xa8beac2aUL, 0x46111938UL, 0x2376a580UL, 0x7566c6d8UL, + 0x10017a60UL, 0xfeaecf72UL, 0x9bc973caUL, 0x22f1a457UL, 0x479618efUL, + 0xa939adfdUL, 0xcc5e1145UL, 0x06ee4d76UL, 0x6389f1ceUL, 0x8d2644dcUL, + 0xe841f864UL, 0x51792ff9UL, 0x341e9341UL, 0xdab12653UL, 0xbfd69aebUL, + 0xe9c6f9b3UL, 0x8ca1450bUL, 0x620ef019UL, 0x07694ca1UL, 0xbe519b3cUL, + 0xdb362784UL, 0x35999296UL, 0x50fe2e2eUL, 0x99b95426UL, 0xfcdee89eUL, + 0x12715d8cUL, 0x7716e134UL, 0xce2e36a9UL, 0xab498a11UL, 0x45e63f03UL, + 0x208183bbUL, 0x7691e0e3UL, 0x13f65c5bUL, 0xfd59e949UL, 0x983e55f1UL, + 0x2106826cUL, 0x44613ed4UL, 0xaace8bc6UL, 0xcfa9377eUL, 0x38417fd6UL, + 0x5d26c36eUL, 0xb389767cUL, 0xd6eecac4UL, 0x6fd61d59UL, 0x0ab1a1e1UL, + 0xe41e14f3UL, 0x8179a84bUL, 0xd769cb13UL, 0xb20e77abUL, 0x5ca1c2b9UL, + 0x39c67e01UL, 0x80fea99cUL, 0xe5991524UL, 0x0b36a036UL, 0x6e511c8eUL, + 0xa7166686UL, 0xc271da3eUL, 0x2cde6f2cUL, 0x49b9d394UL, 0xf0810409UL, + 0x95e6b8b1UL, 0x7b490da3UL, 0x1e2eb11bUL, 0x483ed243UL, 0x2d596efbUL, + 0xc3f6dbe9UL, 0xa6916751UL, 0x1fa9b0ccUL, 0x7ace0c74UL, 0x9461b966UL, + 0xf10605deUL + #endif + } + }; Index: llvm-test/Runtime/zlib/deflate.c diff -c /dev/null llvm-test/Runtime/zlib/deflate.c:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/deflate.c Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,1502 ---- + /* deflate.c -- compress data using the deflation algorithm + * Copyright (C) 1995-2003 Jean-loup Gailly. + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* + * ALGORITHM + * + * The "deflation" process depends on being able to identify portions + * of the input text which are identical to earlier input (within a + * sliding window trailing behind the input currently being processed). + * + * The most straightforward technique turns out to be the fastest for + * most input files: try all possible matches and select the longest. + * The key feature of this algorithm is that insertions into the string + * dictionary are very simple and thus fast, and deletions are avoided + * completely. Insertions are performed at each input character, whereas + * string matches are performed only when the previous match ends. So it + * is preferable to spend more time in matches to allow very fast string + * insertions and avoid deletions. The matching algorithm for small + * strings is inspired from that of Rabin & Karp. A brute force approach + * is used to find longer strings when a small match has been found. + * A similar algorithm is used in comic (by Jan-Mark Wams) and freeze + * (by Leonid Broukhis). + * A previous version of this file used a more sophisticated algorithm + * (by Fiala and Greene) which is guaranteed to run in linear amortized + * time, but has a larger average cost, uses more memory and is patented. + * However the F&G algorithm may be faster for some highly redundant + * files if the parameter max_chain_length (described below) is too large. + * + * ACKNOWLEDGEMENTS + * + * The idea of lazy evaluation of matches is due to Jan-Mark Wams, and + * I found it in 'freeze' written by Leonid Broukhis. + * Thanks to many people for bug reports and testing. + * + * REFERENCES + * + * Deutsch, L.P.,"DEFLATE Compressed Data Format Specification". + * Available in http://www.ietf.org/rfc/rfc1951.txt + * + * A description of the Rabin and Karp algorithm is given in the book + * "Algorithms" by R. Sedgewick, Addison-Wesley, p252. + * + * Fiala,E.R., and Greene,D.H. + * Data Compression with Finite Windows, Comm.ACM, 32,4 (1989) 490-595 + * + */ + + /* @(#) $Id: deflate.c,v 1.1 2004/12/06 21:19:39 criswell Exp $ */ + + #include "deflate.h" + + const char deflate_copyright[] = + " deflate 1.2.1 Copyright 1995-2003 Jean-loup Gailly "; + /* + If you use the zlib library in a product, an acknowledgment is welcome + in the documentation of your product. If for some reason you cannot + include such an acknowledgment, I would appreciate that you keep this + copyright string in the executable of your product. + */ + + /* =========================================================================== + * Function prototypes. + */ + typedef enum { + need_more, /* block not completed, need more input or more output */ + block_done, /* block flush performed */ + finish_started, /* finish started, need only more output at next deflate */ + finish_done /* finish done, accept no more input or output */ + } block_state; + + typedef block_state (*compress_func) OF((deflate_state *s, int flush)); + /* Compression function. Returns the block state after the call. */ + + local void fill_window OF((deflate_state *s)); + local block_state deflate_stored OF((deflate_state *s, int flush)); + local block_state deflate_fast OF((deflate_state *s, int flush)); + #ifndef FASTEST + local block_state deflate_slow OF((deflate_state *s, int flush)); + #endif + local void lm_init OF((deflate_state *s)); + local void putShortMSB OF((deflate_state *s, uInt b)); + local void flush_pending OF((z_streamp strm)); + local int read_buf OF((z_streamp strm, Bytef *buf, unsigned size)); + #ifndef FASTEST + #ifdef ASMV + void match_init OF((void)); /* asm code initialization */ + uInt longest_match OF((deflate_state *s, IPos cur_match)); + #else + local uInt longest_match OF((deflate_state *s, IPos cur_match)); + #endif + #endif + local uInt longest_match_fast OF((deflate_state *s, IPos cur_match)); + + #ifdef DEBUG + local void check_match OF((deflate_state *s, IPos start, IPos match, + int length)); + #endif + + /* =========================================================================== + * Local data + */ + + #define NIL 0 + /* Tail of hash chains */ + + #ifndef TOO_FAR + # define TOO_FAR 4096 + #endif + /* Matches of length 3 are discarded if their distance exceeds TOO_FAR */ + + #define MIN_LOOKAHEAD (MAX_MATCH+MIN_MATCH+1) + /* Minimum amount of lookahead, except at the end of the input file. + * See deflate.c for comments about the MIN_MATCH+1. + */ + + /* Values for max_lazy_match, good_match and max_chain_length, depending on + * the desired pack level (0..9). The values given below have been tuned to + * exclude worst case performance for pathological files. Better values may be + * found for specific files. + */ + typedef struct config_s { + ush good_length; /* reduce lazy search above this match length */ + ush max_lazy; /* do not perform lazy search above this match length */ + ush nice_length; /* quit search above this match length */ + ush max_chain; + compress_func func; + } config; + + #ifdef FASTEST + local const config configuration_table[2] = { + /* good lazy nice chain */ + /* 0 */ {0, 0, 0, 0, deflate_stored}, /* store only */ + /* 1 */ {4, 4, 8, 4, deflate_fast}}; /* max speed, no lazy matches */ + #else + local const config configuration_table[10] = { + /* good lazy nice chain */ + /* 0 */ {0, 0, 0, 0, deflate_stored}, /* store only */ + /* 1 */ {4, 4, 8, 4, deflate_fast}, /* max speed, no lazy matches */ + /* 2 */ {4, 5, 16, 8, deflate_fast}, + /* 3 */ {4, 6, 32, 32, deflate_fast}, + + /* 4 */ {4, 4, 16, 16, deflate_slow}, /* lazy matches */ + /* 5 */ {8, 16, 32, 32, deflate_slow}, + /* 6 */ {8, 16, 128, 128, deflate_slow}, + /* 7 */ {8, 32, 128, 256, deflate_slow}, + /* 8 */ {32, 128, 258, 1024, deflate_slow}, + /* 9 */ {32, 258, 258, 4096, deflate_slow}}; /* max compression */ + #endif + + /* Note: the deflate() code requires max_lazy >= MIN_MATCH and max_chain >= 4 + * For deflate_fast() (levels <= 3) good is ignored and lazy has a different + * meaning. + */ + + #define EQUAL 0 + /* result of memcmp for equal strings */ + + #ifndef NO_DUMMY_DECL + struct static_tree_desc_s {int dummy;}; /* for buggy compilers */ + #endif + + /* =========================================================================== + * Update a hash value with the given input byte + * IN assertion: all calls to to UPDATE_HASH are made with consecutive + * input characters, so that a running hash key can be computed from the + * previous key instead of complete recalculation each time. + */ + #define UPDATE_HASH(s,h,c) (h = (((h)<hash_shift) ^ (c)) & s->hash_mask) + + + /* =========================================================================== + * Insert string str in the dictionary and set match_head to the previous head + * of the hash chain (the most recent string with same hash key). Return + * the previous length of the hash chain. + * If this file is compiled with -DFASTEST, the compression level is forced + * to 1, and no hash chains are maintained. + * IN assertion: all calls to to INSERT_STRING are made with consecutive + * input characters and the first MIN_MATCH bytes of str are valid + * (except for the last MIN_MATCH-1 bytes of the input file). + */ + #ifdef FASTEST + #define INSERT_STRING(s, str, match_head) \ + (UPDATE_HASH(s, s->ins_h, s->window[(str) + (MIN_MATCH-1)]), \ + match_head = s->head[s->ins_h], \ + s->head[s->ins_h] = (Pos)(str)) + #else + #define INSERT_STRING(s, str, match_head) \ + (UPDATE_HASH(s, s->ins_h, s->window[(str) + (MIN_MATCH-1)]), \ + match_head = s->prev[(str) & s->w_mask] = s->head[s->ins_h], \ + s->head[s->ins_h] = (Pos)(str)) + #endif + + /* =========================================================================== + * Initialize the hash table (avoiding 64K overflow for 16 bit systems). + * prev[] will be initialized on the fly. + */ + #define CLEAR_HASH(s) \ + s->head[s->hash_size-1] = NIL; \ + zmemzero((Bytef *)s->head, (unsigned)(s->hash_size-1)*sizeof(*s->head)); + + /* ========================================================================= */ + int ZEXPORT deflateInit_(strm, level, version, stream_size) + z_streamp strm; + int level; + const char *version; + int stream_size; + { + return deflateInit2_(strm, level, Z_DEFLATED, MAX_WBITS, DEF_MEM_LEVEL, + Z_DEFAULT_STRATEGY, version, stream_size); + /* To do: ignore strm->next_in if we use it as window */ + } + + /* ========================================================================= */ + int ZEXPORT deflateInit2_(strm, level, method, windowBits, memLevel, strategy, + version, stream_size) + z_streamp strm; + int level; + int method; + int windowBits; + int memLevel; + int strategy; + const char *version; + int stream_size; + { + deflate_state *s; + int wrap = 1; + static const char my_version[] = ZLIB_VERSION; + + ushf *overlay; + /* We overlay pending_buf and d_buf+l_buf. This works since the average + * output size for (length,distance) codes is <= 24 bits. + */ + + if (version == Z_NULL || version[0] != my_version[0] || + stream_size != sizeof(z_stream)) { + return Z_VERSION_ERROR; + } + if (strm == Z_NULL) return Z_STREAM_ERROR; + + strm->msg = Z_NULL; + if (strm->zalloc == (alloc_func)0) { + strm->zalloc = zcalloc; + strm->opaque = (voidpf)0; + } + if (strm->zfree == (free_func)0) strm->zfree = zcfree; + + #ifdef FASTEST + if (level != 0) level = 1; + #else + if (level == Z_DEFAULT_COMPRESSION) level = 6; + #endif + + if (windowBits < 0) { /* suppress zlib wrapper */ + wrap = 0; + windowBits = -windowBits; + } + #ifdef GZIP + else if (windowBits > 15) { + wrap = 2; /* write gzip wrapper instead */ + windowBits -= 16; + } + #endif + if (memLevel < 1 || memLevel > MAX_MEM_LEVEL || method != Z_DEFLATED || + windowBits < 8 || windowBits > 15 || level < 0 || level > 9 || + strategy < 0 || strategy > Z_RLE) { + return Z_STREAM_ERROR; + } + if (windowBits == 8) windowBits = 9; /* until 256-byte window bug fixed */ + s = (deflate_state *) ZALLOC(strm, 1, sizeof(deflate_state)); + if (s == Z_NULL) return Z_MEM_ERROR; + strm->state = (struct internal_state FAR *)s; + s->strm = strm; + + s->wrap = wrap; + s->w_bits = windowBits; + s->w_size = 1 << s->w_bits; + s->w_mask = s->w_size - 1; + + s->hash_bits = memLevel + 7; + s->hash_size = 1 << s->hash_bits; + s->hash_mask = s->hash_size - 1; + s->hash_shift = ((s->hash_bits+MIN_MATCH-1)/MIN_MATCH); + + s->window = (Bytef *) ZALLOC(strm, s->w_size, 2*sizeof(Byte)); + s->prev = (Posf *) ZALLOC(strm, s->w_size, sizeof(Pos)); + s->head = (Posf *) ZALLOC(strm, s->hash_size, sizeof(Pos)); + + s->lit_bufsize = 1 << (memLevel + 6); /* 16K elements by default */ + + overlay = (ushf *) ZALLOC(strm, s->lit_bufsize, sizeof(ush)+2); + s->pending_buf = (uchf *) overlay; + s->pending_buf_size = (ulg)s->lit_bufsize * (sizeof(ush)+2L); + + if (s->window == Z_NULL || s->prev == Z_NULL || s->head == Z_NULL || + s->pending_buf == Z_NULL) { + s->status = FINISH_STATE; + strm->msg = (char*)ERR_MSG(Z_MEM_ERROR); + deflateEnd (strm); + return Z_MEM_ERROR; + } + s->d_buf = overlay + s->lit_bufsize/sizeof(ush); + s->l_buf = s->pending_buf + (1+sizeof(ush))*s->lit_bufsize; + + s->level = level; + s->strategy = strategy; + s->method = (Byte)method; + + return deflateReset(strm); + } + + /* ========================================================================= */ + int ZEXPORT deflateSetDictionary (strm, dictionary, dictLength) + z_streamp strm; + const Bytef *dictionary; + uInt dictLength; + { + deflate_state *s; + uInt length = dictLength; + uInt n; + IPos hash_head = 0; + + if (strm == Z_NULL || strm->state == Z_NULL || dictionary == Z_NULL || + strm->state->wrap == 2 || + (strm->state->wrap == 1 && strm->state->status != INIT_STATE)) + return Z_STREAM_ERROR; + + s = strm->state; + if (s->wrap) + strm->adler = adler32(strm->adler, dictionary, dictLength); + + if (length < MIN_MATCH) return Z_OK; + if (length > MAX_DIST(s)) { + length = MAX_DIST(s); + #ifndef USE_DICT_HEAD + dictionary += dictLength - length; /* use the tail of the dictionary */ + #endif + } + zmemcpy(s->window, dictionary, length); + s->strstart = length; + s->block_start = (long)length; + + /* Insert all strings in the hash table (except for the last two bytes). + * s->lookahead stays null, so s->ins_h will be recomputed at the next + * call of fill_window. + */ + s->ins_h = s->window[0]; + UPDATE_HASH(s, s->ins_h, s->window[1]); + for (n = 0; n <= length - MIN_MATCH; n++) { + INSERT_STRING(s, n, hash_head); + } + if (hash_head) hash_head = 0; /* to make compiler happy */ + return Z_OK; + } + + /* ========================================================================= */ + int ZEXPORT deflateReset (strm) + z_streamp strm; + { + deflate_state *s; + + if (strm == Z_NULL || strm->state == Z_NULL || + strm->zalloc == (alloc_func)0 || strm->zfree == (free_func)0) { + return Z_STREAM_ERROR; + } + + strm->total_in = strm->total_out = 0; + strm->msg = Z_NULL; /* use zfree if we ever allocate msg dynamically */ + strm->data_type = Z_UNKNOWN; + + s = (deflate_state *)strm->state; + s->pending = 0; + s->pending_out = s->pending_buf; + + if (s->wrap < 0) { + s->wrap = -s->wrap; /* was made negative by deflate(..., Z_FINISH); */ + } + s->status = s->wrap ? INIT_STATE : BUSY_STATE; + strm->adler = + #ifdef GZIP + s->wrap == 2 ? crc32(0L, Z_NULL, 0) : + #endif + adler32(0L, Z_NULL, 0); + s->last_flush = Z_NO_FLUSH; + + _tr_init(s); + lm_init(s); + + return Z_OK; + } + + /* ========================================================================= */ + int ZEXPORT deflatePrime (strm, bits, value) + z_streamp strm; + int bits; + int value; + { + if (strm == Z_NULL || strm->state == Z_NULL) return Z_STREAM_ERROR; + strm->state->bi_valid = bits; + strm->state->bi_buf = (ush)(value & ((1 << bits) - 1)); + return Z_OK; + } + + /* ========================================================================= */ + int ZEXPORT deflateParams(strm, level, strategy) + z_streamp strm; + int level; + int strategy; + { + deflate_state *s; + compress_func func; + int err = Z_OK; + + if (strm == Z_NULL || strm->state == Z_NULL) return Z_STREAM_ERROR; + s = strm->state; + + #ifdef FASTEST + if (level != 0) level = 1; + #else + if (level == Z_DEFAULT_COMPRESSION) level = 6; + #endif + if (level < 0 || level > 9 || strategy < 0 || strategy > Z_RLE) { + return Z_STREAM_ERROR; + } + func = configuration_table[s->level].func; + + if (func != configuration_table[level].func && strm->total_in != 0) { + /* Flush the last buffer: */ + err = deflate(strm, Z_PARTIAL_FLUSH); + } + if (s->level != level) { + s->level = level; + s->max_lazy_match = configuration_table[level].max_lazy; + s->good_match = configuration_table[level].good_length; + s->nice_match = configuration_table[level].nice_length; + s->max_chain_length = configuration_table[level].max_chain; + } + s->strategy = strategy; + return err; + } + + /* ========================================================================= + * For the default windowBits of 15 and memLevel of 8, this function returns + * a close to exact, as well as small, upper bound on the compressed size. + * They are coded as constants here for a reason--if the #define's are + * changed, then this function needs to be changed as well. The return + * value for 15 and 8 only works for those exact settings. + * + * For any setting other than those defaults for windowBits and memLevel, + * the value returned is a conservative worst case for the maximum expansion + * resulting from using fixed blocks instead of stored blocks, which deflate + * can emit on compressed data for some combinations of the parameters. + * + * This function could be more sophisticated to provide closer upper bounds + * for every combination of windowBits and memLevel, as well as wrap. + * But even the conservative upper bound of about 14% expansion does not + * seem onerous for output buffer allocation. + */ + uLong ZEXPORT deflateBound(strm, sourceLen) + z_streamp strm; + uLong sourceLen; + { + deflate_state *s; + uLong destLen; + + /* conservative upper bound */ + destLen = sourceLen + + ((sourceLen + 7) >> 3) + ((sourceLen + 63) >> 6) + 11; + + /* if can't get parameters, return conservative bound */ + if (strm == Z_NULL || strm->state == Z_NULL) + return destLen; + + /* if not default parameters, return conservative bound */ + s = strm->state; + if (s->w_bits != 15 || s->hash_bits != 8 + 7) + return destLen; + + /* default settings: return tight bound for that case */ + return compressBound(sourceLen); + } + + /* ========================================================================= + * Put a short in the pending buffer. The 16-bit value is put in MSB order. + * IN assertion: the stream state is correct and there is enough room in + * pending_buf. + */ + local void putShortMSB (s, b) + deflate_state *s; + uInt b; + { + put_byte(s, (Byte)(b >> 8)); + put_byte(s, (Byte)(b & 0xff)); + } + + /* ========================================================================= + * Flush as much pending output as possible. All deflate() output goes + * through this function so some applications may wish to modify it + * to avoid allocating a large strm->next_out buffer and copying into it. + * (See also read_buf()). + */ + local void flush_pending(strm) + z_streamp strm; + { + unsigned len = strm->state->pending; + + if (len > strm->avail_out) len = strm->avail_out; + if (len == 0) return; + + zmemcpy(strm->next_out, strm->state->pending_out, len); + strm->next_out += len; + strm->state->pending_out += len; + strm->total_out += len; + strm->avail_out -= len; + strm->state->pending -= len; + if (strm->state->pending == 0) { + strm->state->pending_out = strm->state->pending_buf; + } + } + + /* ========================================================================= */ + int ZEXPORT deflate (strm, flush) + z_streamp strm; + int flush; + { + int old_flush; /* value of flush param for previous deflate call */ + deflate_state *s; + + if (strm == Z_NULL || strm->state == Z_NULL || + flush > Z_FINISH || flush < 0) { + return Z_STREAM_ERROR; + } + s = strm->state; + + if (strm->next_out == Z_NULL || + (strm->next_in == Z_NULL && strm->avail_in != 0) || + (s->status == FINISH_STATE && flush != Z_FINISH)) { + ERR_RETURN(strm, Z_STREAM_ERROR); + } + if (strm->avail_out == 0) ERR_RETURN(strm, Z_BUF_ERROR); + + s->strm = strm; /* just in case */ + old_flush = s->last_flush; + s->last_flush = flush; + + /* Write the header */ + if (s->status == INIT_STATE) { + #ifdef GZIP + if (s->wrap == 2) { + put_byte(s, 31); + put_byte(s, 139); + put_byte(s, 8); + put_byte(s, 0); + put_byte(s, 0); + put_byte(s, 0); + put_byte(s, 0); + put_byte(s, 0); + put_byte(s, s->level == 9 ? 2 : + (s->strategy >= Z_HUFFMAN_ONLY || s->level < 2 ? + 4 : 0)); + put_byte(s, 255); + s->status = BUSY_STATE; + strm->adler = crc32(0L, Z_NULL, 0); + } + else + #endif + { + uInt header = (Z_DEFLATED + ((s->w_bits-8)<<4)) << 8; + uInt level_flags; + + if (s->strategy >= Z_HUFFMAN_ONLY || s->level < 2) + level_flags = 0; + else if (s->level < 6) + level_flags = 1; + else if (s->level == 6) + level_flags = 2; + else + level_flags = 3; + header |= (level_flags << 6); + if (s->strstart != 0) header |= PRESET_DICT; + header += 31 - (header % 31); + + s->status = BUSY_STATE; + putShortMSB(s, header); + + /* Save the adler32 of the preset dictionary: */ + if (s->strstart != 0) { + putShortMSB(s, (uInt)(strm->adler >> 16)); + putShortMSB(s, (uInt)(strm->adler & 0xffff)); + } + strm->adler = adler32(0L, Z_NULL, 0); + } + } + + /* Flush as much pending output as possible */ + if (s->pending != 0) { + flush_pending(strm); + if (strm->avail_out == 0) { + /* Since avail_out is 0, deflate will be called again with + * more output space, but possibly with both pending and + * avail_in equal to zero. There won't be anything to do, + * but this is not an error situation so make sure we + * return OK instead of BUF_ERROR at next call of deflate: + */ + s->last_flush = -1; + return Z_OK; + } + + /* Make sure there is something to do and avoid duplicate consecutive + * flushes. For repeated and useless calls with Z_FINISH, we keep + * returning Z_STREAM_END instead of Z_BUF_ERROR. + */ + } else if (strm->avail_in == 0 && flush <= old_flush && + flush != Z_FINISH) { + ERR_RETURN(strm, Z_BUF_ERROR); + } + + /* User must not provide more input after the first FINISH: */ + if (s->status == FINISH_STATE && strm->avail_in != 0) { + ERR_RETURN(strm, Z_BUF_ERROR); + } + + /* Start a new block or continue the current one. + */ + if (strm->avail_in != 0 || s->lookahead != 0 || + (flush != Z_NO_FLUSH && s->status != FINISH_STATE)) { + block_state bstate; + + bstate = (*(configuration_table[s->level].func))(s, flush); + + if (bstate == finish_started || bstate == finish_done) { + s->status = FINISH_STATE; + } + if (bstate == need_more || bstate == finish_started) { + if (strm->avail_out == 0) { + s->last_flush = -1; /* avoid BUF_ERROR next call, see above */ + } + return Z_OK; + /* If flush != Z_NO_FLUSH && avail_out == 0, the next call + * of deflate should use the same flush parameter to make sure + * that the flush is complete. So we don't have to output an + * empty block here, this will be done at next call. This also + * ensures that for a very small output buffer, we emit at most + * one empty block. + */ + } + if (bstate == block_done) { + if (flush == Z_PARTIAL_FLUSH) { + _tr_align(s); + } else { /* FULL_FLUSH or SYNC_FLUSH */ + _tr_stored_block(s, (char*)0, 0L, 0); + /* For a full flush, this empty block will be recognized + * as a special marker by inflate_sync(). + */ + if (flush == Z_FULL_FLUSH) { + CLEAR_HASH(s); /* forget history */ + } + } + flush_pending(strm); + if (strm->avail_out == 0) { + s->last_flush = -1; /* avoid BUF_ERROR at next call, see above */ + return Z_OK; + } + } + } + Assert(strm->avail_out > 0, "bug2"); + + if (flush != Z_FINISH) return Z_OK; + if (s->wrap <= 0) return Z_STREAM_END; + + /* Write the trailer */ + #ifdef GZIP + if (s->wrap == 2) { + put_byte(s, (Byte)(strm->adler & 0xff)); + put_byte(s, (Byte)((strm->adler >> 8) & 0xff)); + put_byte(s, (Byte)((strm->adler >> 16) & 0xff)); + put_byte(s, (Byte)((strm->adler >> 24) & 0xff)); + put_byte(s, (Byte)(strm->total_in & 0xff)); + put_byte(s, (Byte)((strm->total_in >> 8) & 0xff)); + put_byte(s, (Byte)((strm->total_in >> 16) & 0xff)); + put_byte(s, (Byte)((strm->total_in >> 24) & 0xff)); + } + else + #endif + { + putShortMSB(s, (uInt)(strm->adler >> 16)); + putShortMSB(s, (uInt)(strm->adler & 0xffff)); + } + flush_pending(strm); + /* If avail_out is zero, the application will call deflate again + * to flush the rest. + */ + if (s->wrap > 0) s->wrap = -s->wrap; /* write the trailer only once! */ + return s->pending != 0 ? Z_OK : Z_STREAM_END; + } + + /* ========================================================================= */ + int ZEXPORT deflateEnd (strm) + z_streamp strm; + { + int status; + + if (strm == Z_NULL || strm->state == Z_NULL) return Z_STREAM_ERROR; + + status = strm->state->status; + if (status != INIT_STATE && status != BUSY_STATE && + status != FINISH_STATE) { + return Z_STREAM_ERROR; + } + + /* Deallocate in reverse order of allocations: */ + TRY_FREE(strm, strm->state->pending_buf); + TRY_FREE(strm, strm->state->head); + TRY_FREE(strm, strm->state->prev); + TRY_FREE(strm, strm->state->window); + + ZFREE(strm, strm->state); + strm->state = Z_NULL; + + return status == BUSY_STATE ? Z_DATA_ERROR : Z_OK; + } + + /* ========================================================================= + * Copy the source state to the destination state. + * To simplify the source, this is not supported for 16-bit MSDOS (which + * doesn't have enough memory anyway to duplicate compression states). + */ + int ZEXPORT deflateCopy (dest, source) + z_streamp dest; + z_streamp source; + { + #ifdef MAXSEG_64K + return Z_STREAM_ERROR; + #else + deflate_state *ds; + deflate_state *ss; + ushf *overlay; + + + if (source == Z_NULL || dest == Z_NULL || source->state == Z_NULL) { + return Z_STREAM_ERROR; + } + + ss = source->state; + + *dest = *source; + + ds = (deflate_state *) ZALLOC(dest, 1, sizeof(deflate_state)); + if (ds == Z_NULL) return Z_MEM_ERROR; + dest->state = (struct internal_state FAR *) ds; + *ds = *ss; + ds->strm = dest; + + ds->window = (Bytef *) ZALLOC(dest, ds->w_size, 2*sizeof(Byte)); + ds->prev = (Posf *) ZALLOC(dest, ds->w_size, sizeof(Pos)); + ds->head = (Posf *) ZALLOC(dest, ds->hash_size, sizeof(Pos)); + overlay = (ushf *) ZALLOC(dest, ds->lit_bufsize, sizeof(ush)+2); + ds->pending_buf = (uchf *) overlay; + + if (ds->window == Z_NULL || ds->prev == Z_NULL || ds->head == Z_NULL || + ds->pending_buf == Z_NULL) { + deflateEnd (dest); + return Z_MEM_ERROR; + } + /* following zmemcpy do not work for 16-bit MSDOS */ + zmemcpy(ds->window, ss->window, ds->w_size * 2 * sizeof(Byte)); + zmemcpy(ds->prev, ss->prev, ds->w_size * sizeof(Pos)); + zmemcpy(ds->head, ss->head, ds->hash_size * sizeof(Pos)); + zmemcpy(ds->pending_buf, ss->pending_buf, (uInt)ds->pending_buf_size); + + ds->pending_out = ds->pending_buf + (ss->pending_out - ss->pending_buf); + ds->d_buf = overlay + ds->lit_bufsize/sizeof(ush); + ds->l_buf = ds->pending_buf + (1+sizeof(ush))*ds->lit_bufsize; + + ds->l_desc.dyn_tree = ds->dyn_ltree; + ds->d_desc.dyn_tree = ds->dyn_dtree; + ds->bl_desc.dyn_tree = ds->bl_tree; + + return Z_OK; + #endif /* MAXSEG_64K */ + } + + /* =========================================================================== + * Read a new buffer from the current input stream, update the adler32 + * and total number of bytes read. All deflate() input goes through + * this function so some applications may wish to modify it to avoid + * allocating a large strm->next_in buffer and copying from it. + * (See also flush_pending()). + */ + local int read_buf(strm, buf, size) + z_streamp strm; + Bytef *buf; + unsigned size; + { + unsigned len = strm->avail_in; + + if (len > size) len = size; + if (len == 0) return 0; + + strm->avail_in -= len; + + if (strm->state->wrap == 1) { + strm->adler = adler32(strm->adler, strm->next_in, len); + } + #ifdef GZIP + else if (strm->state->wrap == 2) { + strm->adler = crc32(strm->adler, strm->next_in, len); + } + #endif + zmemcpy(buf, strm->next_in, len); + strm->next_in += len; + strm->total_in += len; + + return (int)len; + } + + /* =========================================================================== + * Initialize the "longest match" routines for a new zlib stream + */ + local void lm_init (s) + deflate_state *s; + { + s->window_size = (ulg)2L*s->w_size; + + CLEAR_HASH(s); + + /* Set the default configuration parameters: + */ + s->max_lazy_match = configuration_table[s->level].max_lazy; + s->good_match = configuration_table[s->level].good_length; + s->nice_match = configuration_table[s->level].nice_length; + s->max_chain_length = configuration_table[s->level].max_chain; + + s->strstart = 0; + s->block_start = 0L; + s->lookahead = 0; + s->match_length = s->prev_length = MIN_MATCH-1; + s->match_available = 0; + s->ins_h = 0; + #ifdef ASMV + match_init(); /* initialize the asm code */ + #endif + } + + #ifndef FASTEST + /* =========================================================================== + * Set match_start to the longest match starting at the given string and + * return its length. Matches shorter or equal to prev_length are discarded, + * in which case the result is equal to prev_length and match_start is + * garbage. + * IN assertions: cur_match is the head of the hash chain for the current + * string (strstart) and its distance is <= MAX_DIST, and prev_length >= 1 + * OUT assertion: the match length is not greater than s->lookahead. + */ + #ifndef ASMV + /* For 80x86 and 680x0, an optimized version will be provided in match.asm or + * match.S. The code will be functionally equivalent. + */ + local uInt longest_match(s, cur_match) + deflate_state *s; + IPos cur_match; /* current match */ + { + unsigned chain_length = s->max_chain_length;/* max hash chain length */ + register Bytef *scan = s->window + s->strstart; /* current string */ + register Bytef *match; /* matched string */ + register int len; /* length of current match */ + int best_len = s->prev_length; /* best match length so far */ + int nice_match = s->nice_match; /* stop if match long enough */ + IPos limit = s->strstart > (IPos)MAX_DIST(s) ? + s->strstart - (IPos)MAX_DIST(s) : NIL; + /* Stop when cur_match becomes <= limit. To simplify the code, + * we prevent matches with the string of window index 0. + */ + Posf *prev = s->prev; + uInt wmask = s->w_mask; + + #ifdef UNALIGNED_OK + /* Compare two bytes at a time. Note: this is not always beneficial. + * Try with and without -DUNALIGNED_OK to check. + */ + register Bytef *strend = s->window + s->strstart + MAX_MATCH - 1; + register ush scan_start = *(ushf*)scan; + register ush scan_end = *(ushf*)(scan+best_len-1); + #else + register Bytef *strend = s->window + s->strstart + MAX_MATCH; + register Byte scan_end1 = scan[best_len-1]; + register Byte scan_end = scan[best_len]; + #endif + + /* The code is optimized for HASH_BITS >= 8 and MAX_MATCH-2 multiple of 16. + * It is easy to get rid of this optimization if necessary. + */ + Assert(s->hash_bits >= 8 && MAX_MATCH == 258, "Code too clever"); + + /* Do not waste too much time if we already have a good match: */ + if (s->prev_length >= s->good_match) { + chain_length >>= 2; + } + /* Do not look for matches beyond the end of the input. This is necessary + * to make deflate deterministic. + */ + if ((uInt)nice_match > s->lookahead) nice_match = s->lookahead; + + Assert((ulg)s->strstart <= s->window_size-MIN_LOOKAHEAD, "need lookahead"); + + do { + Assert(cur_match < s->strstart, "no future"); + match = s->window + cur_match; + + /* Skip to next match if the match length cannot increase + * or if the match length is less than 2: + */ + #if (defined(UNALIGNED_OK) && MAX_MATCH == 258) + /* This code assumes sizeof(unsigned short) == 2. Do not use + * UNALIGNED_OK if your compiler uses a different size. + */ + if (*(ushf*)(match+best_len-1) != scan_end || + *(ushf*)match != scan_start) continue; + + /* It is not necessary to compare scan[2] and match[2] since they are + * always equal when the other bytes match, given that the hash keys + * are equal and that HASH_BITS >= 8. Compare 2 bytes at a time at + * strstart+3, +5, ... up to strstart+257. We check for insufficient + * lookahead only every 4th comparison; the 128th check will be made + * at strstart+257. If MAX_MATCH-2 is not a multiple of 8, it is + * necessary to put more guard bytes at the end of the window, or + * to check more often for insufficient lookahead. + */ + Assert(scan[2] == match[2], "scan[2]?"); + scan++, match++; + do { + } while (*(ushf*)(scan+=2) == *(ushf*)(match+=2) && + *(ushf*)(scan+=2) == *(ushf*)(match+=2) && + *(ushf*)(scan+=2) == *(ushf*)(match+=2) && + *(ushf*)(scan+=2) == *(ushf*)(match+=2) && + scan < strend); + /* The funny "do {}" generates better code on most compilers */ + + /* Here, scan <= window+strstart+257 */ + Assert(scan <= s->window+(unsigned)(s->window_size-1), "wild scan"); + if (*scan == *match) scan++; + + len = (MAX_MATCH - 1) - (int)(strend-scan); + scan = strend - (MAX_MATCH-1); + + #else /* UNALIGNED_OK */ + + if (match[best_len] != scan_end || + match[best_len-1] != scan_end1 || + *match != *scan || + *++match != scan[1]) continue; + + /* The check at best_len-1 can be removed because it will be made + * again later. (This heuristic is not always a win.) + * It is not necessary to compare scan[2] and match[2] since they + * are always equal when the other bytes match, given that + * the hash keys are equal and that HASH_BITS >= 8. + */ + scan += 2, match++; + Assert(*scan == *match, "match[2]?"); + + /* We check for insufficient lookahead only every 8th comparison; + * the 256th check will be made at strstart+258. + */ + do { + } while (*++scan == *++match && *++scan == *++match && + *++scan == *++match && *++scan == *++match && + *++scan == *++match && *++scan == *++match && + *++scan == *++match && *++scan == *++match && + scan < strend); + + Assert(scan <= s->window+(unsigned)(s->window_size-1), "wild scan"); + + len = MAX_MATCH - (int)(strend - scan); + scan = strend - MAX_MATCH; + + #endif /* UNALIGNED_OK */ + + if (len > best_len) { + s->match_start = cur_match; + best_len = len; + if (len >= nice_match) break; + #ifdef UNALIGNED_OK + scan_end = *(ushf*)(scan+best_len-1); + #else + scan_end1 = scan[best_len-1]; + scan_end = scan[best_len]; + #endif + } + } while ((cur_match = prev[cur_match & wmask]) > limit + && --chain_length != 0); + + if ((uInt)best_len <= s->lookahead) return (uInt)best_len; + return s->lookahead; + } + #endif /* ASMV */ + #endif /* FASTEST */ + + /* --------------------------------------------------------------------------- + * Optimized version for level == 1 or strategy == Z_RLE only + */ + local uInt longest_match_fast(s, cur_match) + deflate_state *s; + IPos cur_match; /* current match */ + { + register Bytef *scan = s->window + s->strstart; /* current string */ + register Bytef *match; /* matched string */ + register int len; /* length of current match */ + register Bytef *strend = s->window + s->strstart + MAX_MATCH; + + /* The code is optimized for HASH_BITS >= 8 and MAX_MATCH-2 multiple of 16. + * It is easy to get rid of this optimization if necessary. + */ + Assert(s->hash_bits >= 8 && MAX_MATCH == 258, "Code too clever"); + + Assert((ulg)s->strstart <= s->window_size-MIN_LOOKAHEAD, "need lookahead"); + + Assert(cur_match < s->strstart, "no future"); + + match = s->window + cur_match; + + /* Return failure if the match length is less than 2: + */ + if (match[0] != scan[0] || match[1] != scan[1]) return MIN_MATCH-1; + + /* The check at best_len-1 can be removed because it will be made + * again later. (This heuristic is not always a win.) + * It is not necessary to compare scan[2] and match[2] since they + * are always equal when the other bytes match, given that + * the hash keys are equal and that HASH_BITS >= 8. + */ + scan += 2, match += 2; + Assert(*scan == *match, "match[2]?"); + + /* We check for insufficient lookahead only every 8th comparison; + * the 256th check will be made at strstart+258. + */ + do { + } while (*++scan == *++match && *++scan == *++match && + *++scan == *++match && *++scan == *++match && + *++scan == *++match && *++scan == *++match && + *++scan == *++match && *++scan == *++match && + scan < strend); + + Assert(scan <= s->window+(unsigned)(s->window_size-1), "wild scan"); + + len = MAX_MATCH - (int)(strend - scan); + + if (len < MIN_MATCH) return MIN_MATCH - 1; + + s->match_start = cur_match; + return (uInt)len <= s->lookahead ? (uInt)len : s->lookahead; + } + + #ifdef DEBUG + /* =========================================================================== + * Check that the match at match_start is indeed a match. + */ + local void check_match(s, start, match, length) + deflate_state *s; + IPos start, match; + int length; + { + /* check that the match is indeed a match */ + if (zmemcmp(s->window + match, + s->window + start, length) != EQUAL) { + fprintf(stderr, " start %u, match %u, length %d\n", + start, match, length); + do { + fprintf(stderr, "%c%c", s->window[match++], s->window[start++]); + } while (--length != 0); + z_error("invalid match"); + } + if (z_verbose > 1) { + fprintf(stderr,"\\[%d,%d]", start-match, length); + do { putc(s->window[start++], stderr); } while (--length != 0); + } + } + #else + # define check_match(s, start, match, length) + #endif /* DEBUG */ + + /* =========================================================================== + * Fill the window when the lookahead becomes insufficient. + * Updates strstart and lookahead. + * + * IN assertion: lookahead < MIN_LOOKAHEAD + * OUT assertions: strstart <= window_size-MIN_LOOKAHEAD + * At least one byte has been read, or avail_in == 0; reads are + * performed for at least two bytes (required for the zip translate_eol + * option -- not supported here). + */ + local void fill_window(s) + deflate_state *s; + { + register unsigned n, m; + register Posf *p; + unsigned more; /* Amount of free space at the end of the window. */ + uInt wsize = s->w_size; + + do { + more = (unsigned)(s->window_size -(ulg)s->lookahead -(ulg)s->strstart); + + /* Deal with !@#$% 64K limit: */ + if (sizeof(int) <= 2) { + if (more == 0 && s->strstart == 0 && s->lookahead == 0) { + more = wsize; + + } else if (more == (unsigned)(-1)) { + /* Very unlikely, but possible on 16 bit machine if + * strstart == 0 && lookahead == 1 (input done a byte at time) + */ + more--; + } + } + + /* If the window is almost full and there is insufficient lookahead, + * move the upper half to the lower one to make room in the upper half. + */ + if (s->strstart >= wsize+MAX_DIST(s)) { + + zmemcpy(s->window, s->window+wsize, (unsigned)wsize); + s->match_start -= wsize; + s->strstart -= wsize; /* we now have strstart >= MAX_DIST */ + s->block_start -= (long) wsize; + + /* Slide the hash table (could be avoided with 32 bit values + at the expense of memory usage). We slide even when level == 0 + to keep the hash table consistent if we switch back to level > 0 + later. (Using level 0 permanently is not an optimal usage of + zlib, so we don't care about this pathological case.) + */ + n = s->hash_size; + p = &s->head[n]; + do { + m = *--p; + *p = (Pos)(m >= wsize ? m-wsize : NIL); + } while (--n); + + n = wsize; + #ifndef FASTEST + p = &s->prev[n]; + do { + m = *--p; + *p = (Pos)(m >= wsize ? m-wsize : NIL); + /* If n is not on any hash chain, prev[n] is garbage but + * its value will never be used. + */ + } while (--n); + #endif + more += wsize; + } + if (s->strm->avail_in == 0) return; + + /* If there was no sliding: + * strstart <= WSIZE+MAX_DIST-1 && lookahead <= MIN_LOOKAHEAD - 1 && + * more == window_size - lookahead - strstart + * => more >= window_size - (MIN_LOOKAHEAD-1 + WSIZE + MAX_DIST-1) + * => more >= window_size - 2*WSIZE + 2 + * In the BIG_MEM or MMAP case (not yet supported), + * window_size == input_size + MIN_LOOKAHEAD && + * strstart + s->lookahead <= input_size => more >= MIN_LOOKAHEAD. + * Otherwise, window_size == 2*WSIZE so more >= 2. + * If there was sliding, more >= WSIZE. So in all cases, more >= 2. + */ + Assert(more >= 2, "more < 2"); + + n = read_buf(s->strm, s->window + s->strstart + s->lookahead, more); + s->lookahead += n; + + /* Initialize the hash value now that we have some input: */ + if (s->lookahead >= MIN_MATCH) { + s->ins_h = s->window[s->strstart]; + UPDATE_HASH(s, s->ins_h, s->window[s->strstart+1]); + #if MIN_MATCH != 3 + Call UPDATE_HASH() MIN_MATCH-3 more times + #endif + } + /* If the whole input has less than MIN_MATCH bytes, ins_h is garbage, + * but this is not important since only literal bytes will be emitted. + */ + + } while (s->lookahead < MIN_LOOKAHEAD && s->strm->avail_in != 0); + } + + /* =========================================================================== + * Flush the current block, with given end-of-file flag. + * IN assertion: strstart is set to the end of the current match. + */ + #define FLUSH_BLOCK_ONLY(s, eof) { \ + _tr_flush_block(s, (s->block_start >= 0L ? \ + (charf *)&s->window[(unsigned)s->block_start] : \ + (charf *)Z_NULL), \ + (ulg)((long)s->strstart - s->block_start), \ + (eof)); \ + s->block_start = s->strstart; \ + flush_pending(s->strm); \ + Tracev((stderr,"[FLUSH]")); \ + } + + /* Same but force premature exit if necessary. */ + #define FLUSH_BLOCK(s, eof) { \ + FLUSH_BLOCK_ONLY(s, eof); \ + if (s->strm->avail_out == 0) return (eof) ? finish_started : need_more; \ + } + + /* =========================================================================== + * Copy without compression as much as possible from the input stream, return + * the current block state. + * This function does not insert new strings in the dictionary since + * uncompressible data is probably not useful. This function is used + * only for the level=0 compression option. + * NOTE: this function should be optimized to avoid extra copying from + * window to pending_buf. + */ + local block_state deflate_stored(s, flush) + deflate_state *s; + int flush; + { + /* Stored blocks are limited to 0xffff bytes, pending_buf is limited + * to pending_buf_size, and each stored block has a 5 byte header: + */ + ulg max_block_size = 0xffff; + ulg max_start; + + if (max_block_size > s->pending_buf_size - 5) { + max_block_size = s->pending_buf_size - 5; + } + + /* Copy as much as possible from input to output: */ + for (;;) { + /* Fill the window as much as possible: */ + if (s->lookahead <= 1) { + + Assert(s->strstart < s->w_size+MAX_DIST(s) || + s->block_start >= (long)s->w_size, "slide too late"); + + fill_window(s); + if (s->lookahead == 0 && flush == Z_NO_FLUSH) return need_more; + + if (s->lookahead == 0) break; /* flush the current block */ + } + Assert(s->block_start >= 0L, "block gone"); + + s->strstart += s->lookahead; + s->lookahead = 0; + + /* Emit a stored block if pending_buf will be full: */ + max_start = s->block_start + max_block_size; + if (s->strstart == 0 || (ulg)s->strstart >= max_start) { + /* strstart == 0 is possible when wraparound on 16-bit machine */ + s->lookahead = (uInt)(s->strstart - max_start); + s->strstart = (uInt)max_start; + FLUSH_BLOCK(s, 0); + } + /* Flush if we may have to slide, otherwise block_start may become + * negative and the data will be gone: + */ + if (s->strstart - (uInt)s->block_start >= MAX_DIST(s)) { + FLUSH_BLOCK(s, 0); + } + } + FLUSH_BLOCK(s, flush == Z_FINISH); + return flush == Z_FINISH ? finish_done : block_done; + } + + /* =========================================================================== + * Compress as much as possible from the input stream, return the current + * block state. + * This function does not perform lazy evaluation of matches and inserts + * new strings in the dictionary only for unmatched strings or for short + * matches. It is used only for the fast compression options. + */ + local block_state deflate_fast(s, flush) + deflate_state *s; + int flush; + { + IPos hash_head = NIL; /* head of the hash chain */ + int bflush; /* set if current block must be flushed */ + + for (;;) { + /* Make sure that we always have enough lookahead, except + * at the end of the input file. We need MAX_MATCH bytes + * for the next match, plus MIN_MATCH bytes to insert the + * string following the next match. + */ + if (s->lookahead < MIN_LOOKAHEAD) { + fill_window(s); + if (s->lookahead < MIN_LOOKAHEAD && flush == Z_NO_FLUSH) { + return need_more; + } + if (s->lookahead == 0) break; /* flush the current block */ + } + + /* Insert the string window[strstart .. strstart+2] in the + * dictionary, and set hash_head to the head of the hash chain: + */ + if (s->lookahead >= MIN_MATCH) { + INSERT_STRING(s, s->strstart, hash_head); + } + + /* Find the longest match, discarding those <= prev_length. + * At this point we have always match_length < MIN_MATCH + */ + if (hash_head != NIL && s->strstart - hash_head <= MAX_DIST(s)) { + /* To simplify the code, we prevent matches with the string + * of window index 0 (in particular we have to avoid a match + * of the string with itself at the start of the input file). + */ + #ifdef FASTEST + if ((s->strategy < Z_HUFFMAN_ONLY) || + (s->strategy == Z_RLE && s->strstart - hash_head == 1)) { + s->match_length = longest_match_fast (s, hash_head); + } + #else + if (s->strategy < Z_HUFFMAN_ONLY) { + s->match_length = longest_match (s, hash_head); + } else if (s->strategy == Z_RLE && s->strstart - hash_head == 1) { + s->match_length = longest_match_fast (s, hash_head); + } + #endif + /* longest_match() or longest_match_fast() sets match_start */ + } + if (s->match_length >= MIN_MATCH) { + check_match(s, s->strstart, s->match_start, s->match_length); + + _tr_tally_dist(s, s->strstart - s->match_start, + s->match_length - MIN_MATCH, bflush); + + s->lookahead -= s->match_length; + + /* Insert new strings in the hash table only if the match length + * is not too large. This saves time but degrades compression. + */ + #ifndef FASTEST + if (s->match_length <= s->max_insert_length && + s->lookahead >= MIN_MATCH) { + s->match_length--; /* string at strstart already in table */ + do { + s->strstart++; + INSERT_STRING(s, s->strstart, hash_head); + /* strstart never exceeds WSIZE-MAX_MATCH, so there are + * always MIN_MATCH bytes ahead. + */ + } while (--s->match_length != 0); + s->strstart++; + } else + #endif + { + s->strstart += s->match_length; + s->match_length = 0; + s->ins_h = s->window[s->strstart]; + UPDATE_HASH(s, s->ins_h, s->window[s->strstart+1]); + #if MIN_MATCH != 3 + Call UPDATE_HASH() MIN_MATCH-3 more times + #endif + /* If lookahead < MIN_MATCH, ins_h is garbage, but it does not + * matter since it will be recomputed at next deflate call. + */ + } + } else { + /* No match, output a literal byte */ + Tracevv((stderr,"%c", s->window[s->strstart])); + _tr_tally_lit (s, s->window[s->strstart], bflush); + s->lookahead--; + s->strstart++; + } + if (bflush) FLUSH_BLOCK(s, 0); + } + FLUSH_BLOCK(s, flush == Z_FINISH); + return flush == Z_FINISH ? finish_done : block_done; + } + + #ifndef FASTEST + /* =========================================================================== + * Same as above, but achieves better compression. We use a lazy + * evaluation for matches: a match is finally adopted only if there is + * no better match at the next window position. + */ + local block_state deflate_slow(s, flush) + deflate_state *s; + int flush; + { + IPos hash_head = NIL; /* head of hash chain */ + int bflush; /* set if current block must be flushed */ + + /* Process the input block. */ + for (;;) { + /* Make sure that we always have enough lookahead, except + * at the end of the input file. We need MAX_MATCH bytes + * for the next match, plus MIN_MATCH bytes to insert the + * string following the next match. + */ + if (s->lookahead < MIN_LOOKAHEAD) { + fill_window(s); + if (s->lookahead < MIN_LOOKAHEAD && flush == Z_NO_FLUSH) { + return need_more; + } + if (s->lookahead == 0) break; /* flush the current block */ + } + + /* Insert the string window[strstart .. strstart+2] in the + * dictionary, and set hash_head to the head of the hash chain: + */ + if (s->lookahead >= MIN_MATCH) { + INSERT_STRING(s, s->strstart, hash_head); + } + + /* Find the longest match, discarding those <= prev_length. + */ + s->prev_length = s->match_length, s->prev_match = s->match_start; + s->match_length = MIN_MATCH-1; + + if (hash_head != NIL && s->prev_length < s->max_lazy_match && + s->strstart - hash_head <= MAX_DIST(s)) { + /* To simplify the code, we prevent matches with the string + * of window index 0 (in particular we have to avoid a match + * of the string with itself at the start of the input file). + */ + if (s->strategy < Z_HUFFMAN_ONLY) { + s->match_length = longest_match (s, hash_head); + } else if (s->strategy == Z_RLE && s->strstart - hash_head == 1) { + s->match_length = longest_match_fast (s, hash_head); + } + /* longest_match() or longest_match_fast() sets match_start */ + + if (s->match_length <= 5 && (s->strategy == Z_FILTERED + #if TOO_FAR <= 32767 + || (s->match_length == MIN_MATCH && + s->strstart - s->match_start > TOO_FAR) + #endif + )) { + + /* If prev_match is also MIN_MATCH, match_start is garbage + * but we will ignore the current match anyway. + */ + s->match_length = MIN_MATCH-1; + } + } + /* If there was a match at the previous step and the current + * match is not better, output the previous match: + */ + if (s->prev_length >= MIN_MATCH && s->match_length <= s->prev_length) { + uInt max_insert = s->strstart + s->lookahead - MIN_MATCH; + /* Do not insert strings in hash table beyond this. */ + + check_match(s, s->strstart-1, s->prev_match, s->prev_length); + + _tr_tally_dist(s, s->strstart -1 - s->prev_match, + s->prev_length - MIN_MATCH, bflush); + + /* Insert in hash table all strings up to the end of the match. + * strstart-1 and strstart are already inserted. If there is not + * enough lookahead, the last two strings are not inserted in + * the hash table. + */ + s->lookahead -= s->prev_length-1; + s->prev_length -= 2; + do { + if (++s->strstart <= max_insert) { + INSERT_STRING(s, s->strstart, hash_head); + } + } while (--s->prev_length != 0); + s->match_available = 0; + s->match_length = MIN_MATCH-1; + s->strstart++; + + if (bflush) FLUSH_BLOCK(s, 0); + + } else if (s->match_available) { + /* If there was no match at the previous position, output a + * single literal. If there was a match but the current match + * is longer, truncate the previous match to a single literal. + */ + Tracevv((stderr,"%c", s->window[s->strstart-1])); + _tr_tally_lit(s, s->window[s->strstart-1], bflush); + if (bflush) { + FLUSH_BLOCK_ONLY(s, 0); + } + s->strstart++; + s->lookahead--; + if (s->strm->avail_out == 0) return need_more; + } else { + /* There is no previous match to compare with, wait for + * the next step to decide. + */ + s->match_available = 1; + s->strstart++; + s->lookahead--; + } + } + Assert (flush != Z_NO_FLUSH, "no flush?"); + if (s->match_available) { + Tracevv((stderr,"%c", s->window[s->strstart-1])); + _tr_tally_lit(s, s->window[s->strstart-1], bflush); + s->match_available = 0; + } + FLUSH_BLOCK(s, flush == Z_FINISH); + return flush == Z_FINISH ? finish_done : block_done; + } + #endif /* FASTEST */ Index: llvm-test/Runtime/zlib/deflate.h diff -c /dev/null llvm-test/Runtime/zlib/deflate.h:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/deflate.h Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,326 ---- + /* deflate.h -- internal compression state + * Copyright (C) 1995-2002 Jean-loup Gailly + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* WARNING: this file should *not* be used by applications. It is + part of the implementation of the compression library and is + subject to change. Applications should only use zlib.h. + */ + + /* @(#) $Id: deflate.h,v 1.1 2004/12/06 21:19:39 criswell Exp $ */ + + #ifndef DEFLATE_H + #define DEFLATE_H + + #include "zutil.h" + + /* define NO_GZIP when compiling if you want to disable gzip header and + trailer creation by deflate(). NO_GZIP would be used to avoid linking in + the crc code when it is not needed. For shared libraries, gzip encoding + should be left enabled. */ + #ifndef NO_GZIP + # define GZIP + #endif + + /* =========================================================================== + * Internal compression state. + */ + + #define LENGTH_CODES 29 + /* number of length codes, not counting the special END_BLOCK code */ + + #define LITERALS 256 + /* number of literal bytes 0..255 */ + + #define L_CODES (LITERALS+1+LENGTH_CODES) + /* number of Literal or Length codes, including the END_BLOCK code */ + + #define D_CODES 30 + /* number of distance codes */ + + #define BL_CODES 19 + /* number of codes used to transfer the bit lengths */ + + #define HEAP_SIZE (2*L_CODES+1) + /* maximum heap size */ + + #define MAX_BITS 15 + /* All codes must not exceed MAX_BITS bits */ + + #define INIT_STATE 42 + #define BUSY_STATE 113 + #define FINISH_STATE 666 + /* Stream status */ + + + /* Data structure describing a single value and its code string. */ + typedef struct ct_data_s { + union { + ush freq; /* frequency count */ + ush code; /* bit string */ + } fc; + union { + ush dad; /* father node in Huffman tree */ + ush len; /* length of bit string */ + } dl; + } FAR ct_data; + + #define Freq fc.freq + #define Code fc.code + #define Dad dl.dad + #define Len dl.len + + typedef struct static_tree_desc_s static_tree_desc; + + typedef struct tree_desc_s { + ct_data *dyn_tree; /* the dynamic tree */ + int max_code; /* largest code with non zero frequency */ + static_tree_desc *stat_desc; /* the corresponding static tree */ + } FAR tree_desc; + + typedef ush Pos; + typedef Pos FAR Posf; + typedef unsigned IPos; + + /* A Pos is an index in the character window. We use short instead of int to + * save space in the various tables. IPos is used only for parameter passing. + */ + + typedef struct internal_state { + z_streamp strm; /* pointer back to this zlib stream */ + int status; /* as the name implies */ + Bytef *pending_buf; /* output still pending */ + ulg pending_buf_size; /* size of pending_buf */ + Bytef *pending_out; /* next pending byte to output to the stream */ + int pending; /* nb of bytes in the pending buffer */ + int wrap; /* bit 0 true for zlib, bit 1 true for gzip */ + Byte data_type; /* UNKNOWN, BINARY or ASCII */ + Byte method; /* STORED (for zip only) or DEFLATED */ + int last_flush; /* value of flush param for previous deflate call */ + + /* used by deflate.c: */ + + uInt w_size; /* LZ77 window size (32K by default) */ + uInt w_bits; /* log2(w_size) (8..16) */ + uInt w_mask; /* w_size - 1 */ + + Bytef *window; + /* Sliding window. Input bytes are read into the second half of the window, + * and move to the first half later to keep a dictionary of at least wSize + * bytes. With this organization, matches are limited to a distance of + * wSize-MAX_MATCH bytes, but this ensures that IO is always + * performed with a length multiple of the block size. Also, it limits + * the window size to 64K, which is quite useful on MSDOS. + * To do: use the user input buffer as sliding window. + */ + + ulg window_size; + /* Actual size of window: 2*wSize, except when the user input buffer + * is directly used as sliding window. + */ + + Posf *prev; + /* Link to older string with same hash index. To limit the size of this + * array to 64K, this link is maintained only for the last 32K strings. + * An index in this array is thus a window index modulo 32K. + */ + + Posf *head; /* Heads of the hash chains or NIL. */ + + uInt ins_h; /* hash index of string to be inserted */ + uInt hash_size; /* number of elements in hash table */ + uInt hash_bits; /* log2(hash_size) */ + uInt hash_mask; /* hash_size-1 */ + + uInt hash_shift; + /* Number of bits by which ins_h must be shifted at each input + * step. It must be such that after MIN_MATCH steps, the oldest + * byte no longer takes part in the hash key, that is: + * hash_shift * MIN_MATCH >= hash_bits + */ + + long block_start; + /* Window position at the beginning of the current output block. Gets + * negative when the window is moved backwards. + */ + + uInt match_length; /* length of best match */ + IPos prev_match; /* previous match */ + int match_available; /* set if previous match exists */ + uInt strstart; /* start of string to insert */ + uInt match_start; /* start of matching string */ + uInt lookahead; /* number of valid bytes ahead in window */ + + uInt prev_length; + /* Length of the best match at previous step. Matches not greater than this + * are discarded. This is used in the lazy match evaluation. + */ + + uInt max_chain_length; + /* To speed up deflation, hash chains are never searched beyond this + * length. A higher limit improves compression ratio but degrades the + * speed. + */ + + uInt max_lazy_match; + /* Attempt to find a better match only when the current match is strictly + * smaller than this value. This mechanism is used only for compression + * levels >= 4. + */ + # define max_insert_length max_lazy_match + /* Insert new strings in the hash table only if the match length is not + * greater than this length. This saves time but degrades compression. + * max_insert_length is used only for compression levels <= 3. + */ + + int level; /* compression level (1..9) */ + int strategy; /* favor or force Huffman coding*/ + + uInt good_match; + /* Use a faster search when the previous match is longer than this */ + + int nice_match; /* Stop searching when current match exceeds this */ + + /* used by trees.c: */ + /* Didn't use ct_data typedef below to supress compiler warning */ + struct ct_data_s dyn_ltree[HEAP_SIZE]; /* literal and length tree */ + struct ct_data_s dyn_dtree[2*D_CODES+1]; /* distance tree */ + struct ct_data_s bl_tree[2*BL_CODES+1]; /* Huffman tree for bit lengths */ + + struct tree_desc_s l_desc; /* desc. for literal tree */ + struct tree_desc_s d_desc; /* desc. for distance tree */ + struct tree_desc_s bl_desc; /* desc. for bit length tree */ + + ush bl_count[MAX_BITS+1]; + /* number of codes at each bit length for an optimal tree */ + + int heap[2*L_CODES+1]; /* heap used to build the Huffman trees */ + int heap_len; /* number of elements in the heap */ + int heap_max; /* element of largest frequency */ + /* The sons of heap[n] are heap[2*n] and heap[2*n+1]. heap[0] is not used. + * The same heap array is used to build all trees. + */ + + uch depth[2*L_CODES+1]; + /* Depth of each subtree used as tie breaker for trees of equal frequency + */ + + uchf *l_buf; /* buffer for literals or lengths */ + + uInt lit_bufsize; + /* Size of match buffer for literals/lengths. There are 4 reasons for + * limiting lit_bufsize to 64K: + * - frequencies can be kept in 16 bit counters + * - if compression is not successful for the first block, all input + * data is still in the window so we can still emit a stored block even + * when input comes from standard input. (This can also be done for + * all blocks if lit_bufsize is not greater than 32K.) + * - if compression is not successful for a file smaller than 64K, we can + * even emit a stored file instead of a stored block (saving 5 bytes). + * This is applicable only for zip (not gzip or zlib). + * - creating new Huffman trees less frequently may not provide fast + * adaptation to changes in the input data statistics. (Take for + * example a binary file with poorly compressible code followed by + * a highly compressible string table.) Smaller buffer sizes give + * fast adaptation but have of course the overhead of transmitting + * trees more frequently. + * - I can't count above 4 + */ + + uInt last_lit; /* running index in l_buf */ + + ushf *d_buf; + /* Buffer for distances. To simplify the code, d_buf and l_buf have + * the same number of elements. To use different lengths, an extra flag + * array would be necessary. + */ + + ulg opt_len; /* bit length of current block with optimal trees */ + ulg static_len; /* bit length of current block with static trees */ + uInt matches; /* number of string matches in current block */ + int last_eob_len; /* bit length of EOB code for last block */ + + #ifdef DEBUG + ulg compressed_len; /* total bit length of compressed file mod 2^32 */ + ulg bits_sent; /* bit length of compressed data sent mod 2^32 */ + #endif + + ush bi_buf; + /* Output buffer. bits are inserted starting at the bottom (least + * significant bits). + */ + int bi_valid; + /* Number of valid bits in bi_buf. All bits above the last valid bit + * are always zero. + */ + + } FAR deflate_state; + + /* Output a byte on the stream. + * IN assertion: there is enough room in pending_buf. + */ + #define put_byte(s, c) {s->pending_buf[s->pending++] = (c);} + + + #define MIN_LOOKAHEAD (MAX_MATCH+MIN_MATCH+1) + /* Minimum amount of lookahead, except at the end of the input file. + * See deflate.c for comments about the MIN_MATCH+1. + */ + + #define MAX_DIST(s) ((s)->w_size-MIN_LOOKAHEAD) + /* In order to simplify the code, particularly on 16 bit machines, match + * distances are limited to MAX_DIST instead of WSIZE. + */ + + /* in trees.c */ + void _tr_init OF((deflate_state *s)); + int _tr_tally OF((deflate_state *s, unsigned dist, unsigned lc)); + void _tr_flush_block OF((deflate_state *s, charf *buf, ulg stored_len, + int eof)); + void _tr_align OF((deflate_state *s)); + void _tr_stored_block OF((deflate_state *s, charf *buf, ulg stored_len, + int eof)); + + #define d_code(dist) \ + ((dist) < 256 ? _dist_code[dist] : _dist_code[256+((dist)>>7)]) + /* Mapping from a distance to a distance code. dist is the distance - 1 and + * must not have side effects. _dist_code[256] and _dist_code[257] are never + * used. + */ + + #ifndef DEBUG + /* Inline versions of _tr_tally for speed: */ + + #if defined(GEN_TREES_H) || !defined(STDC) + extern uch _length_code[]; + extern uch _dist_code[]; + #else + extern const uch _length_code[]; + extern const uch _dist_code[]; + #endif + + # define _tr_tally_lit(s, c, flush) \ + { uch cc = (c); \ + s->d_buf[s->last_lit] = 0; \ + s->l_buf[s->last_lit++] = cc; \ + s->dyn_ltree[cc].Freq++; \ + flush = (s->last_lit == s->lit_bufsize-1); \ + } + # define _tr_tally_dist(s, distance, length, flush) \ + { uch len = (length); \ + ush dist = (distance); \ + s->d_buf[s->last_lit] = dist; \ + s->l_buf[s->last_lit++] = len; \ + dist--; \ + s->dyn_ltree[_length_code[len]+LITERALS+1].Freq++; \ + s->dyn_dtree[d_code(dist)].Freq++; \ + flush = (s->last_lit == s->lit_bufsize-1); \ + } + #else + # define _tr_tally_lit(s, c, flush) flush = _tr_tally(s, 0, c) + # define _tr_tally_dist(s, distance, length, flush) \ + flush = _tr_tally(s, distance, length) + #endif + + #endif /* DEFLATE_H */ Index: llvm-test/Runtime/zlib/example.c diff -c /dev/null llvm-test/Runtime/zlib/example.c:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/example.c Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,567 ---- + /* example.c -- usage example of the zlib compression library + * Copyright (C) 1995-2003 Jean-loup Gailly. + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* @(#) $Id: example.c,v 1.1 2004/12/06 21:19:39 criswell Exp $ */ + + #include + #include "zlib.h" + + #ifdef STDC + # include + # include + #else + extern void exit OF((int)); + #endif + + #if defined(VMS) || defined(RISCOS) + # define TESTFILE "foo-gz" + #else + # define TESTFILE "foo.gz" + #endif + + #define CHECK_ERR(err, msg) { \ + if (err != Z_OK) { \ + fprintf(stderr, "%s error: %d\n", msg, err); \ + exit(1); \ + } \ + } + + const char hello[] = "hello, hello!"; + /* "hello world" would be more standard, but the repeated "hello" + * stresses the compression code better, sorry... + */ + + const char dictionary[] = "hello"; + uLong dictId; /* Adler32 value of the dictionary */ + + void test_compress OF((Byte *compr, uLong comprLen, + Byte *uncompr, uLong uncomprLen)); + void test_gzio OF((const char *fname, + Byte *uncompr, uLong uncomprLen)); + void test_deflate OF((Byte *compr, uLong comprLen)); + void test_inflate OF((Byte *compr, uLong comprLen, + Byte *uncompr, uLong uncomprLen)); + void test_large_deflate OF((Byte *compr, uLong comprLen, + Byte *uncompr, uLong uncomprLen)); + void test_large_inflate OF((Byte *compr, uLong comprLen, + Byte *uncompr, uLong uncomprLen)); + void test_flush OF((Byte *compr, uLong *comprLen)); + void test_sync OF((Byte *compr, uLong comprLen, + Byte *uncompr, uLong uncomprLen)); + void test_dict_deflate OF((Byte *compr, uLong comprLen)); + void test_dict_inflate OF((Byte *compr, uLong comprLen, + Byte *uncompr, uLong uncomprLen)); + int main OF((int argc, char *argv[])); + + /* =========================================================================== + * Test compress() and uncompress() + */ + void test_compress(compr, comprLen, uncompr, uncomprLen) + Byte *compr, *uncompr; + uLong comprLen, uncomprLen; + { + int err; + uLong len = (uLong)strlen(hello)+1; + + err = compress(compr, &comprLen, (const Bytef*)hello, len); + CHECK_ERR(err, "compress"); + + strcpy((char*)uncompr, "garbage"); + + err = uncompress(uncompr, &uncomprLen, compr, comprLen); + CHECK_ERR(err, "uncompress"); + + if (strcmp((char*)uncompr, hello)) { + fprintf(stderr, "bad uncompress\n"); + exit(1); + } else { + printf("uncompress(): %s\n", (char *)uncompr); + } + } + + /* =========================================================================== + * Test read/write of .gz files + */ + void test_gzio(fname, uncompr, uncomprLen) + const char *fname; /* compressed file name */ + Byte *uncompr; + uLong uncomprLen; + { + #ifdef NO_GZCOMPRESS + fprintf(stderr, "NO_GZCOMPRESS -- gz* functions cannot compress\n"); + #else + int err; + int len = (int)strlen(hello)+1; + gzFile file; + z_off_t pos; + + file = gzopen(fname, "wb"); + if (file == NULL) { + fprintf(stderr, "gzopen error\n"); + exit(1); + } + gzputc(file, 'h'); + if (gzputs(file, "ello") != 4) { + fprintf(stderr, "gzputs err: %s\n", gzerror(file, &err)); + exit(1); + } + if (gzprintf(file, ", %s!", "hello") != 8) { + fprintf(stderr, "gzprintf err: %s\n", gzerror(file, &err)); + exit(1); + } + gzseek(file, 1L, SEEK_CUR); /* add one zero byte */ + gzclose(file); + + file = gzopen(fname, "rb"); + if (file == NULL) { + fprintf(stderr, "gzopen error\n"); + exit(1); + } + strcpy((char*)uncompr, "garbage"); + + if (gzread(file, uncompr, (unsigned)uncomprLen) != len) { + fprintf(stderr, "gzread err: %s\n", gzerror(file, &err)); + exit(1); + } + if (strcmp((char*)uncompr, hello)) { + fprintf(stderr, "bad gzread: %s\n", (char*)uncompr); + exit(1); + } else { + printf("gzread(): %s\n", (char*)uncompr); + } + + pos = gzseek(file, -8L, SEEK_CUR); + if (pos != 6 || gztell(file) != pos) { + fprintf(stderr, "gzseek error, pos=%ld, gztell=%ld\n", + (long)pos, (long)gztell(file)); + exit(1); + } + + if (gzgetc(file) != ' ') { + fprintf(stderr, "gzgetc error\n"); + exit(1); + } + + if (gzungetc(' ', file) != ' ') { + fprintf(stderr, "gzungetc error\n"); + exit(1); + } + + gzgets(file, (char*)uncompr, (int)uncomprLen); + if (strlen((char*)uncompr) != 7) { /* " hello!" */ + fprintf(stderr, "gzgets err after gzseek: %s\n", gzerror(file, &err)); + exit(1); + } + if (strcmp((char*)uncompr, hello + 6)) { + fprintf(stderr, "bad gzgets after gzseek\n"); + exit(1); + } else { + printf("gzgets() after gzseek: %s\n", (char*)uncompr); + } + + gzclose(file); + #endif + } + + /* =========================================================================== + * Test deflate() with small buffers + */ + void test_deflate(compr, comprLen) + Byte *compr; + uLong comprLen; + { + z_stream c_stream; /* compression stream */ + int err; + uLong len = (uLong)strlen(hello)+1; + + c_stream.zalloc = (alloc_func)0; + c_stream.zfree = (free_func)0; + c_stream.opaque = (voidpf)0; + + err = deflateInit(&c_stream, Z_DEFAULT_COMPRESSION); + CHECK_ERR(err, "deflateInit"); + + c_stream.next_in = (Bytef*)hello; + c_stream.next_out = compr; + + while (c_stream.total_in != len && c_stream.total_out < comprLen) { + c_stream.avail_in = c_stream.avail_out = 1; /* force small buffers */ + err = deflate(&c_stream, Z_NO_FLUSH); + CHECK_ERR(err, "deflate"); + } + /* Finish the stream, still forcing small buffers: */ + for (;;) { + c_stream.avail_out = 1; + err = deflate(&c_stream, Z_FINISH); + if (err == Z_STREAM_END) break; + CHECK_ERR(err, "deflate"); + } + + err = deflateEnd(&c_stream); + CHECK_ERR(err, "deflateEnd"); + } + + /* =========================================================================== + * Test inflate() with small buffers + */ + void test_inflate(compr, comprLen, uncompr, uncomprLen) + Byte *compr, *uncompr; + uLong comprLen, uncomprLen; + { + int err; + z_stream d_stream; /* decompression stream */ + + strcpy((char*)uncompr, "garbage"); + + d_stream.zalloc = (alloc_func)0; + d_stream.zfree = (free_func)0; + d_stream.opaque = (voidpf)0; + + d_stream.next_in = compr; + d_stream.avail_in = 0; + d_stream.next_out = uncompr; + + err = inflateInit(&d_stream); + CHECK_ERR(err, "inflateInit"); + + while (d_stream.total_out < uncomprLen && d_stream.total_in < comprLen) { + d_stream.avail_in = d_stream.avail_out = 1; /* force small buffers */ + err = inflate(&d_stream, Z_NO_FLUSH); + if (err == Z_STREAM_END) break; + CHECK_ERR(err, "inflate"); + } + + err = inflateEnd(&d_stream); + CHECK_ERR(err, "inflateEnd"); + + if (strcmp((char*)uncompr, hello)) { + fprintf(stderr, "bad inflate\n"); + exit(1); + } else { + printf("inflate(): %s\n", (char *)uncompr); + } + } + + /* =========================================================================== + * Test deflate() with large buffers and dynamic change of compression level + */ + void test_large_deflate(compr, comprLen, uncompr, uncomprLen) + Byte *compr, *uncompr; + uLong comprLen, uncomprLen; + { + z_stream c_stream; /* compression stream */ + int err; + + c_stream.zalloc = (alloc_func)0; + c_stream.zfree = (free_func)0; + c_stream.opaque = (voidpf)0; + + err = deflateInit(&c_stream, Z_BEST_SPEED); + CHECK_ERR(err, "deflateInit"); + + c_stream.next_out = compr; + c_stream.avail_out = (uInt)comprLen; + + /* At this point, uncompr is still mostly zeroes, so it should compress + * very well: + */ + c_stream.next_in = uncompr; + c_stream.avail_in = (uInt)uncomprLen; + err = deflate(&c_stream, Z_NO_FLUSH); + CHECK_ERR(err, "deflate"); + if (c_stream.avail_in != 0) { + fprintf(stderr, "deflate not greedy\n"); + exit(1); + } + + /* Feed in already compressed data and switch to no compression: */ + deflateParams(&c_stream, Z_NO_COMPRESSION, Z_DEFAULT_STRATEGY); + c_stream.next_in = compr; + c_stream.avail_in = (uInt)comprLen/2; + err = deflate(&c_stream, Z_NO_FLUSH); + CHECK_ERR(err, "deflate"); + + /* Switch back to compressing mode: */ + deflateParams(&c_stream, Z_BEST_COMPRESSION, Z_FILTERED); + c_stream.next_in = uncompr; + c_stream.avail_in = (uInt)uncomprLen; + err = deflate(&c_stream, Z_NO_FLUSH); + CHECK_ERR(err, "deflate"); + + err = deflate(&c_stream, Z_FINISH); + if (err != Z_STREAM_END) { + fprintf(stderr, "deflate should report Z_STREAM_END\n"); + exit(1); + } + err = deflateEnd(&c_stream); + CHECK_ERR(err, "deflateEnd"); + } + + /* =========================================================================== + * Test inflate() with large buffers + */ + void test_large_inflate(compr, comprLen, uncompr, uncomprLen) + Byte *compr, *uncompr; + uLong comprLen, uncomprLen; + { + int err; + z_stream d_stream; /* decompression stream */ + + strcpy((char*)uncompr, "garbage"); + + d_stream.zalloc = (alloc_func)0; + d_stream.zfree = (free_func)0; + d_stream.opaque = (voidpf)0; + + d_stream.next_in = compr; + d_stream.avail_in = (uInt)comprLen; + + err = inflateInit(&d_stream); + CHECK_ERR(err, "inflateInit"); + + for (;;) { + d_stream.next_out = uncompr; /* discard the output */ + d_stream.avail_out = (uInt)uncomprLen; + err = inflate(&d_stream, Z_NO_FLUSH); + if (err == Z_STREAM_END) break; + CHECK_ERR(err, "large inflate"); + } + + err = inflateEnd(&d_stream); + CHECK_ERR(err, "inflateEnd"); + + if (d_stream.total_out != 2*uncomprLen + comprLen/2) { + fprintf(stderr, "bad large inflate: %ld\n", d_stream.total_out); + exit(1); + } else { + printf("large_inflate(): OK\n"); + } + } + + /* =========================================================================== + * Test deflate() with full flush + */ + void test_flush(compr, comprLen) + Byte *compr; + uLong *comprLen; + { + z_stream c_stream; /* compression stream */ + int err; + uInt len = (uInt)strlen(hello)+1; + + c_stream.zalloc = (alloc_func)0; + c_stream.zfree = (free_func)0; + c_stream.opaque = (voidpf)0; + + err = deflateInit(&c_stream, Z_DEFAULT_COMPRESSION); + CHECK_ERR(err, "deflateInit"); + + c_stream.next_in = (Bytef*)hello; + c_stream.next_out = compr; + c_stream.avail_in = 3; + c_stream.avail_out = (uInt)*comprLen; + err = deflate(&c_stream, Z_FULL_FLUSH); + CHECK_ERR(err, "deflate"); + + compr[3]++; /* force an error in first compressed block */ + c_stream.avail_in = len - 3; + + err = deflate(&c_stream, Z_FINISH); + if (err != Z_STREAM_END) { + CHECK_ERR(err, "deflate"); + } + err = deflateEnd(&c_stream); + CHECK_ERR(err, "deflateEnd"); + + *comprLen = c_stream.total_out; + } + + /* =========================================================================== + * Test inflateSync() + */ + void test_sync(compr, comprLen, uncompr, uncomprLen) + Byte *compr, *uncompr; + uLong comprLen, uncomprLen; + { + int err; + z_stream d_stream; /* decompression stream */ + + strcpy((char*)uncompr, "garbage"); + + d_stream.zalloc = (alloc_func)0; + d_stream.zfree = (free_func)0; + d_stream.opaque = (voidpf)0; + + d_stream.next_in = compr; + d_stream.avail_in = 2; /* just read the zlib header */ + + err = inflateInit(&d_stream); + CHECK_ERR(err, "inflateInit"); + + d_stream.next_out = uncompr; + d_stream.avail_out = (uInt)uncomprLen; + + inflate(&d_stream, Z_NO_FLUSH); + CHECK_ERR(err, "inflate"); + + d_stream.avail_in = (uInt)comprLen-2; /* read all compressed data */ + err = inflateSync(&d_stream); /* but skip the damaged part */ + CHECK_ERR(err, "inflateSync"); + + err = inflate(&d_stream, Z_FINISH); + if (err != Z_DATA_ERROR) { + fprintf(stderr, "inflate should report DATA_ERROR\n"); + /* Because of incorrect adler32 */ + exit(1); + } + err = inflateEnd(&d_stream); + CHECK_ERR(err, "inflateEnd"); + + printf("after inflateSync(): hel%s\n", (char *)uncompr); + } + + /* =========================================================================== + * Test deflate() with preset dictionary + */ + void test_dict_deflate(compr, comprLen) + Byte *compr; + uLong comprLen; + { + z_stream c_stream; /* compression stream */ + int err; + + c_stream.zalloc = (alloc_func)0; + c_stream.zfree = (free_func)0; + c_stream.opaque = (voidpf)0; + + err = deflateInit(&c_stream, Z_BEST_COMPRESSION); + CHECK_ERR(err, "deflateInit"); + + err = deflateSetDictionary(&c_stream, + (const Bytef*)dictionary, sizeof(dictionary)); + CHECK_ERR(err, "deflateSetDictionary"); + + dictId = c_stream.adler; + c_stream.next_out = compr; + c_stream.avail_out = (uInt)comprLen; + + c_stream.next_in = (Bytef*)hello; + c_stream.avail_in = (uInt)strlen(hello)+1; + + err = deflate(&c_stream, Z_FINISH); + if (err != Z_STREAM_END) { + fprintf(stderr, "deflate should report Z_STREAM_END\n"); + exit(1); + } + err = deflateEnd(&c_stream); + CHECK_ERR(err, "deflateEnd"); + } + + /* =========================================================================== + * Test inflate() with a preset dictionary + */ + void test_dict_inflate(compr, comprLen, uncompr, uncomprLen) + Byte *compr, *uncompr; + uLong comprLen, uncomprLen; + { + int err; + z_stream d_stream; /* decompression stream */ + + strcpy((char*)uncompr, "garbage"); + + d_stream.zalloc = (alloc_func)0; + d_stream.zfree = (free_func)0; + d_stream.opaque = (voidpf)0; + + d_stream.next_in = compr; + d_stream.avail_in = (uInt)comprLen; + + err = inflateInit(&d_stream); + CHECK_ERR(err, "inflateInit"); + + d_stream.next_out = uncompr; + d_stream.avail_out = (uInt)uncomprLen; + + for (;;) { + err = inflate(&d_stream, Z_NO_FLUSH); + if (err == Z_STREAM_END) break; + if (err == Z_NEED_DICT) { + if (d_stream.adler != dictId) { + fprintf(stderr, "unexpected dictionary"); + exit(1); + } + err = inflateSetDictionary(&d_stream, (const Bytef*)dictionary, + sizeof(dictionary)); + } + CHECK_ERR(err, "inflate with dict"); + } + + err = inflateEnd(&d_stream); + CHECK_ERR(err, "inflateEnd"); + + if (strcmp((char*)uncompr, hello)) { + fprintf(stderr, "bad inflate with dict\n"); + exit(1); + } else { + printf("inflate with dictionary: %s\n", (char *)uncompr); + } + } + + /* =========================================================================== + * Usage: example [output.gz [input.gz]] + */ + + int main(argc, argv) + int argc; + char *argv[]; + { + Byte *compr, *uncompr; + uLong comprLen = 10000*sizeof(int); /* don't overflow on MSDOS */ + uLong uncomprLen = comprLen; + static const char* myVersion = ZLIB_VERSION; + + if (zlibVersion()[0] != myVersion[0]) { + fprintf(stderr, "incompatible zlib version\n"); + exit(1); + + } else if (strcmp(zlibVersion(), ZLIB_VERSION) != 0) { + fprintf(stderr, "warning: different zlib version\n"); + } + + printf("zlib version %s = 0x%04x, compile flags = 0x%lx\n", + ZLIB_VERSION, ZLIB_VERNUM, zlibCompileFlags()); + + compr = (Byte*)calloc((uInt)comprLen, 1); + uncompr = (Byte*)calloc((uInt)uncomprLen, 1); + /* compr and uncompr are cleared to avoid reading uninitialized + * data and to ensure that uncompr compresses well. + */ + if (compr == Z_NULL || uncompr == Z_NULL) { + printf("out of memory\n"); + exit(1); + } + test_compress(compr, comprLen, uncompr, uncomprLen); + + test_gzio((argc > 1 ? argv[1] : TESTFILE), + uncompr, uncomprLen); + + test_deflate(compr, comprLen); + test_inflate(compr, comprLen, uncompr, uncomprLen); + + test_large_deflate(compr, comprLen, uncompr, uncomprLen); + test_large_inflate(compr, comprLen, uncompr, uncomprLen); + + test_flush(compr, &comprLen); + test_sync(compr, comprLen, uncompr, uncomprLen); + comprLen = uncomprLen; + + test_dict_deflate(compr, comprLen); + test_dict_inflate(compr, comprLen, uncompr, uncomprLen); + + free(compr); + free(uncompr); + + return 0; + } Index: llvm-test/Runtime/zlib/gzio.c diff -c /dev/null llvm-test/Runtime/zlib/gzio.c:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/gzio.c Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,1005 ---- + /* gzio.c -- IO on .gz files + * Copyright (C) 1995-2003 Jean-loup Gailly. + * For conditions of distribution and use, see copyright notice in zlib.h + * + * Compile this file with -DNO_GZCOMPRESS to avoid the compression code. + */ + + /* @(#) $Id: gzio.c,v 1.1 2004/12/06 21:19:39 criswell Exp $ */ + + #include + + #include "zutil.h" + + #ifdef NO_DEFLATE /* for compatiblity with old definition */ + # define NO_GZCOMPRESS + #endif + + #ifndef NO_DUMMY_DECL + struct internal_state {int dummy;}; /* for buggy compilers */ + #endif + + #ifndef Z_BUFSIZE + # ifdef MAXSEG_64K + # define Z_BUFSIZE 4096 /* minimize memory usage for 16-bit DOS */ + # else + # define Z_BUFSIZE 16384 + # endif + #endif + #ifndef Z_PRINTF_BUFSIZE + # define Z_PRINTF_BUFSIZE 4096 + #endif + + #ifdef __MVS__ + # pragma map (fdopen , "\174\174FDOPEN") + FILE *fdopen(int, const char *); + #endif + + #ifndef STDC + extern voidp malloc OF((uInt size)); + extern void free OF((voidpf ptr)); + #endif + + #define ALLOC(size) malloc(size) + #define TRYFREE(p) {if (p) free(p);} + + static int const gz_magic[2] = {0x1f, 0x8b}; /* gzip magic header */ + + /* gzip flag byte */ + #define ASCII_FLAG 0x01 /* bit 0 set: file probably ascii text */ + #define HEAD_CRC 0x02 /* bit 1 set: header CRC present */ + #define EXTRA_FIELD 0x04 /* bit 2 set: extra field present */ + #define ORIG_NAME 0x08 /* bit 3 set: original file name present */ + #define COMMENT 0x10 /* bit 4 set: file comment present */ + #define RESERVED 0xE0 /* bits 5..7: reserved */ + + typedef struct gz_stream { + z_stream stream; + int z_err; /* error code for last stream operation */ + int z_eof; /* set if end of input file */ + FILE *file; /* .gz file */ + Byte *inbuf; /* input buffer */ + Byte *outbuf; /* output buffer */ + uLong crc; /* crc32 of uncompressed data */ + char *msg; /* error message */ + char *path; /* path name for debugging only */ + int transparent; /* 1 if input file is not a .gz file */ + char mode; /* 'w' or 'r' */ + z_off_t start; /* start of compressed data in file (header skipped) */ + z_off_t in; /* bytes into deflate or inflate */ + z_off_t out; /* bytes out of deflate or inflate */ + int back; /* one character push-back */ + int last; /* true if push-back is last character */ + } gz_stream; + + + local gzFile gz_open OF((const char *path, const char *mode, int fd)); + local int do_flush OF((gzFile file, int flush)); + local int get_byte OF((gz_stream *s)); + local void check_header OF((gz_stream *s)); + local int destroy OF((gz_stream *s)); + local void putLong OF((FILE *file, uLong x)); + local uLong getLong OF((gz_stream *s)); + + /* =========================================================================== + Opens a gzip (.gz) file for reading or writing. The mode parameter + is as in fopen ("rb" or "wb"). The file is given either by file descriptor + or path name (if fd == -1). + gz_open returns NULL if the file could not be opened or if there was + insufficient memory to allocate the (de)compression state; errno + can be checked to distinguish the two cases (if errno is zero, the + zlib error is Z_MEM_ERROR). + */ + local gzFile gz_open (path, mode, fd) + const char *path; + const char *mode; + int fd; + { + int err; + int level = Z_DEFAULT_COMPRESSION; /* compression level */ + int strategy = Z_DEFAULT_STRATEGY; /* compression strategy */ + char *p = (char*)mode; + gz_stream *s; + char fmode[80]; /* copy of mode, without the compression level */ + char *m = fmode; + + if (!path || !mode) return Z_NULL; + + s = (gz_stream *)ALLOC(sizeof(gz_stream)); + if (!s) return Z_NULL; + + s->stream.zalloc = (alloc_func)0; + s->stream.zfree = (free_func)0; + s->stream.opaque = (voidpf)0; + s->stream.next_in = s->inbuf = Z_NULL; + s->stream.next_out = s->outbuf = Z_NULL; + s->stream.avail_in = s->stream.avail_out = 0; + s->file = NULL; + s->z_err = Z_OK; + s->z_eof = 0; + s->in = 0; + s->out = 0; + s->back = EOF; + s->crc = crc32(0L, Z_NULL, 0); + s->msg = NULL; + s->transparent = 0; + + s->path = (char*)ALLOC(strlen(path)+1); + if (s->path == NULL) { + return destroy(s), (gzFile)Z_NULL; + } + strcpy(s->path, path); /* do this early for debugging */ + + s->mode = '\0'; + do { + if (*p == 'r') s->mode = 'r'; + if (*p == 'w' || *p == 'a') s->mode = 'w'; + if (*p >= '0' && *p <= '9') { + level = *p - '0'; + } else if (*p == 'f') { + strategy = Z_FILTERED; + } else if (*p == 'h') { + strategy = Z_HUFFMAN_ONLY; + } else if (*p == 'R') { + strategy = Z_RLE; + } else { + *m++ = *p; /* copy the mode */ + } + } while (*p++ && m != fmode + sizeof(fmode)); + if (s->mode == '\0') return destroy(s), (gzFile)Z_NULL; + + if (s->mode == 'w') { + #ifdef NO_GZCOMPRESS + err = Z_STREAM_ERROR; + #else + err = deflateInit2(&(s->stream), level, + Z_DEFLATED, -MAX_WBITS, DEF_MEM_LEVEL, strategy); + /* windowBits is passed < 0 to suppress zlib header */ + + s->stream.next_out = s->outbuf = (Byte*)ALLOC(Z_BUFSIZE); + #endif + if (err != Z_OK || s->outbuf == Z_NULL) { + return destroy(s), (gzFile)Z_NULL; + } + } else { + s->stream.next_in = s->inbuf = (Byte*)ALLOC(Z_BUFSIZE); + + err = inflateInit2(&(s->stream), -MAX_WBITS); + /* windowBits is passed < 0 to tell that there is no zlib header. + * Note that in this case inflate *requires* an extra "dummy" byte + * after the compressed stream in order to complete decompression and + * return Z_STREAM_END. Here the gzip CRC32 ensures that 4 bytes are + * present after the compressed stream. + */ + if (err != Z_OK || s->inbuf == Z_NULL) { + return destroy(s), (gzFile)Z_NULL; + } + } + s->stream.avail_out = Z_BUFSIZE; + + errno = 0; + s->file = fd < 0 ? F_OPEN(path, fmode) : (FILE*)fdopen(fd, fmode); + + if (s->file == NULL) { + return destroy(s), (gzFile)Z_NULL; + } + if (s->mode == 'w') { + /* Write a very simple .gz header: + */ + fprintf(s->file, "%c%c%c%c%c%c%c%c%c%c", gz_magic[0], gz_magic[1], + Z_DEFLATED, 0 /*flags*/, 0,0,0,0 /*time*/, 0 /*xflags*/, OS_CODE); + s->start = 10L; + /* We use 10L instead of ftell(s->file) to because ftell causes an + * fflush on some systems. This version of the library doesn't use + * start anyway in write mode, so this initialization is not + * necessary. + */ + } else { + check_header(s); /* skip the .gz header */ + s->start = ftell(s->file) - s->stream.avail_in; + } + + return (gzFile)s; + } + + /* =========================================================================== + Opens a gzip (.gz) file for reading or writing. + */ + gzFile ZEXPORT gzopen (path, mode) + const char *path; + const char *mode; + { + return gz_open (path, mode, -1); + } + + /* =========================================================================== + Associate a gzFile with the file descriptor fd. fd is not dup'ed here + to mimic the behavio(u)r of fdopen. + */ + gzFile ZEXPORT gzdopen (fd, mode) + int fd; + const char *mode; + { + char name[20]; + + if (fd < 0) return (gzFile)Z_NULL; + sprintf(name, "", fd); /* for debugging */ + + return gz_open (name, mode, fd); + } + + /* =========================================================================== + * Update the compression level and strategy + */ + int ZEXPORT gzsetparams (file, level, strategy) + gzFile file; + int level; + int strategy; + { + gz_stream *s = (gz_stream*)file; + + if (s == NULL || s->mode != 'w') return Z_STREAM_ERROR; + + /* Make room to allow flushing */ + if (s->stream.avail_out == 0) { + + s->stream.next_out = s->outbuf; + if (fwrite(s->outbuf, 1, Z_BUFSIZE, s->file) != Z_BUFSIZE) { + s->z_err = Z_ERRNO; + } + s->stream.avail_out = Z_BUFSIZE; + } + + return deflateParams (&(s->stream), level, strategy); + } + + /* =========================================================================== + Read a byte from a gz_stream; update next_in and avail_in. Return EOF + for end of file. + IN assertion: the stream s has been sucessfully opened for reading. + */ + local int get_byte(s) + gz_stream *s; + { + if (s->z_eof) return EOF; + if (s->stream.avail_in == 0) { + errno = 0; + s->stream.avail_in = fread(s->inbuf, 1, Z_BUFSIZE, s->file); + if (s->stream.avail_in == 0) { + s->z_eof = 1; + if (ferror(s->file)) s->z_err = Z_ERRNO; + return EOF; + } + s->stream.next_in = s->inbuf; + } + s->stream.avail_in--; + return *(s->stream.next_in)++; + } + + /* =========================================================================== + Check the gzip header of a gz_stream opened for reading. Set the stream + mode to transparent if the gzip magic header is not present; set s->err + to Z_DATA_ERROR if the magic header is present but the rest of the header + is incorrect. + IN assertion: the stream s has already been created sucessfully; + s->stream.avail_in is zero for the first time, but may be non-zero + for concatenated .gz files. + */ + local void check_header(s) + gz_stream *s; + { + int method; /* method byte */ + int flags; /* flags byte */ + uInt len; + int c; + + /* Assure two bytes in the buffer so we can peek ahead -- handle case + where first byte of header is at the end of the buffer after the last + gzip segment */ + len = s->stream.avail_in; + if (len < 2) { + if (len) s->inbuf[0] = s->stream.next_in[0]; + errno = 0; + len = fread(s->inbuf + len, 1, Z_BUFSIZE >> len, s->file); + if (len == 0 && ferror(s->file)) s->z_err = Z_ERRNO; + s->stream.avail_in += len; + s->stream.next_in = s->inbuf; + if (s->stream.avail_in < 2) { + s->transparent = s->stream.avail_in; + return; + } + } + + /* Peek ahead to check the gzip magic header */ + if (s->stream.next_in[0] != gz_magic[0] || + s->stream.next_in[1] != gz_magic[1]) { + s->transparent = 1; + return; + } + s->stream.avail_in -= 2; + s->stream.next_in += 2; + + /* Check the rest of the gzip header */ + method = get_byte(s); + flags = get_byte(s); + if (method != Z_DEFLATED || (flags & RESERVED) != 0) { + s->z_err = Z_DATA_ERROR; + return; + } + + /* Discard time, xflags and OS code: */ + for (len = 0; len < 6; len++) (void)get_byte(s); + + if ((flags & EXTRA_FIELD) != 0) { /* skip the extra field */ + len = (uInt)get_byte(s); + len += ((uInt)get_byte(s))<<8; + /* len is garbage if EOF but the loop below will quit anyway */ + while (len-- != 0 && get_byte(s) != EOF) ; + } + if ((flags & ORIG_NAME) != 0) { /* skip the original file name */ + while ((c = get_byte(s)) != 0 && c != EOF) ; + } + if ((flags & COMMENT) != 0) { /* skip the .gz file comment */ + while ((c = get_byte(s)) != 0 && c != EOF) ; + } + if ((flags & HEAD_CRC) != 0) { /* skip the header crc */ + for (len = 0; len < 2; len++) (void)get_byte(s); + } + s->z_err = s->z_eof ? Z_DATA_ERROR : Z_OK; + } + + /* =========================================================================== + * Cleanup then free the given gz_stream. Return a zlib error code. + Try freeing in the reverse order of allocations. + */ + local int destroy (s) + gz_stream *s; + { + int err = Z_OK; + + if (!s) return Z_STREAM_ERROR; + + TRYFREE(s->msg); + + if (s->stream.state != NULL) { + if (s->mode == 'w') { + #ifdef NO_GZCOMPRESS + err = Z_STREAM_ERROR; + #else + err = deflateEnd(&(s->stream)); + #endif + } else if (s->mode == 'r') { + err = inflateEnd(&(s->stream)); + } + } + if (s->file != NULL && fclose(s->file)) { + #ifdef ESPIPE + if (errno != ESPIPE) /* fclose is broken for pipes in HP/UX */ + #endif + err = Z_ERRNO; + } + if (s->z_err < 0) err = s->z_err; + + TRYFREE(s->inbuf); + TRYFREE(s->outbuf); + TRYFREE(s->path); + TRYFREE(s); + return err; + } + + /* =========================================================================== + Reads the given number of uncompressed bytes from the compressed file. + gzread returns the number of bytes actually read (0 for end of file). + */ + int ZEXPORT gzread (file, buf, len) + gzFile file; + voidp buf; + unsigned len; + { + gz_stream *s = (gz_stream*)file; + Bytef *start = (Bytef*)buf; /* starting point for crc computation */ + Byte *next_out; /* == stream.next_out but not forced far (for MSDOS) */ + + if (s == NULL || s->mode != 'r') return Z_STREAM_ERROR; + + if (s->z_err == Z_DATA_ERROR || s->z_err == Z_ERRNO) return -1; + if (s->z_err == Z_STREAM_END) return 0; /* EOF */ + + next_out = (Byte*)buf; + s->stream.next_out = (Bytef*)buf; + s->stream.avail_out = len; + + if (s->stream.avail_out && s->back != EOF) { + *next_out++ = s->back; + s->stream.next_out++; + s->stream.avail_out--; + s->back = EOF; + s->out++; + if (s->last) { + s->z_err = Z_STREAM_END; + return 1; + } + } + + while (s->stream.avail_out != 0) { + + if (s->transparent) { + /* Copy first the lookahead bytes: */ + uInt n = s->stream.avail_in; + if (n > s->stream.avail_out) n = s->stream.avail_out; + if (n > 0) { + zmemcpy(s->stream.next_out, s->stream.next_in, n); + next_out += n; + s->stream.next_out = next_out; + s->stream.next_in += n; + s->stream.avail_out -= n; + s->stream.avail_in -= n; + } + if (s->stream.avail_out > 0) { + s->stream.avail_out -= fread(next_out, 1, s->stream.avail_out, + s->file); + } + len -= s->stream.avail_out; + s->in += len; + s->out += len; + if (len == 0) s->z_eof = 1; + return (int)len; + } + if (s->stream.avail_in == 0 && !s->z_eof) { + + errno = 0; + s->stream.avail_in = fread(s->inbuf, 1, Z_BUFSIZE, s->file); + if (s->stream.avail_in == 0) { + s->z_eof = 1; + if (ferror(s->file)) { + s->z_err = Z_ERRNO; + break; + } + } + s->stream.next_in = s->inbuf; + } + s->in += s->stream.avail_in; + s->out += s->stream.avail_out; + s->z_err = inflate(&(s->stream), Z_NO_FLUSH); + s->in -= s->stream.avail_in; + s->out -= s->stream.avail_out; + + if (s->z_err == Z_STREAM_END) { + /* Check CRC and original size */ + s->crc = crc32(s->crc, start, (uInt)(s->stream.next_out - start)); + start = s->stream.next_out; + + if (getLong(s) != s->crc) { + s->z_err = Z_DATA_ERROR; + } else { + (void)getLong(s); + /* The uncompressed length returned by above getlong() may be + * different from s->out in case of concatenated .gz files. + * Check for such files: + */ + check_header(s); + if (s->z_err == Z_OK) { + inflateReset(&(s->stream)); + s->crc = crc32(0L, Z_NULL, 0); + } + } + } + if (s->z_err != Z_OK || s->z_eof) break; + } + s->crc = crc32(s->crc, start, (uInt)(s->stream.next_out - start)); + + return (int)(len - s->stream.avail_out); + } + + + /* =========================================================================== + Reads one byte from the compressed file. gzgetc returns this byte + or -1 in case of end of file or error. + */ + int ZEXPORT gzgetc(file) + gzFile file; + { + unsigned char c; + + return gzread(file, &c, 1) == 1 ? c : -1; + } + + + /* =========================================================================== + Push one byte back onto the stream. + */ + int ZEXPORT gzungetc(c, file) + int c; + gzFile file; + { + gz_stream *s = (gz_stream*)file; + + if (s == NULL || s->mode != 'r' || c == EOF || s->back != EOF) return EOF; + s->back = c; + s->out--; + s->last = (s->z_err == Z_STREAM_END); + if (s->last) s->z_err = Z_OK; + s->z_eof = 0; + return c; + } + + + /* =========================================================================== + Reads bytes from the compressed file until len-1 characters are + read, or a newline character is read and transferred to buf, or an + end-of-file condition is encountered. The string is then terminated + with a null character. + gzgets returns buf, or Z_NULL in case of error. + + The current implementation is not optimized at all. + */ + char * ZEXPORT gzgets(file, buf, len) + gzFile file; + char *buf; + int len; + { + char *b = buf; + if (buf == Z_NULL || len <= 0) return Z_NULL; + + while (--len > 0 && gzread(file, buf, 1) == 1 && *buf++ != '\n') ; + *buf = '\0'; + return b == buf && len > 0 ? Z_NULL : b; + } + + + #ifndef NO_GZCOMPRESS + /* =========================================================================== + Writes the given number of uncompressed bytes into the compressed file. + gzwrite returns the number of bytes actually written (0 in case of error). + */ + int ZEXPORT gzwrite (file, buf, len) + gzFile file; + voidpc buf; + unsigned len; + { + gz_stream *s = (gz_stream*)file; + + if (s == NULL || s->mode != 'w') return Z_STREAM_ERROR; + + s->stream.next_in = (Bytef*)buf; + s->stream.avail_in = len; + + while (s->stream.avail_in != 0) { + + if (s->stream.avail_out == 0) { + + s->stream.next_out = s->outbuf; + if (fwrite(s->outbuf, 1, Z_BUFSIZE, s->file) != Z_BUFSIZE) { + s->z_err = Z_ERRNO; + break; + } + s->stream.avail_out = Z_BUFSIZE; + } + s->in += s->stream.avail_in; + s->out += s->stream.avail_out; + s->z_err = deflate(&(s->stream), Z_NO_FLUSH); + s->in -= s->stream.avail_in; + s->out -= s->stream.avail_out; + if (s->z_err != Z_OK) break; + } + s->crc = crc32(s->crc, (const Bytef *)buf, len); + + return (int)(len - s->stream.avail_in); + } + + + /* =========================================================================== + Converts, formats, and writes the args to the compressed file under + control of the format string, as in fprintf. gzprintf returns the number of + uncompressed bytes actually written (0 in case of error). + */ + #ifdef STDC + #include + + int ZEXPORTVA gzprintf (gzFile file, const char *format, /* args */ ...) + { + char buf[Z_PRINTF_BUFSIZE]; + va_list va; + int len; + + buf[sizeof(buf) - 1] = 0; + va_start(va, format); + #ifdef NO_vsnprintf + # ifdef HAS_vsprintf_void + (void)vsprintf(buf, format, va); + va_end(va); + for (len = 0; len < sizeof(buf); len++) + if (buf[len] == 0) break; + # else + len = vsprintf(buf, format, va); + va_end(va); + # endif + #else + # ifdef HAS_vsnprintf_void + (void)vsnprintf(buf, sizeof(buf), format, va); + va_end(va); + len = strlen(buf); + # else + len = vsnprintf(buf, sizeof(buf), format, va); + va_end(va); + # endif + #endif + if (len <= 0 || len >= (int)sizeof(buf) || buf[sizeof(buf) - 1] != 0) + return 0; + return gzwrite(file, buf, (unsigned)len); + } + #else /* not ANSI C */ + + int ZEXPORTVA gzprintf (file, format, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, + a11, a12, a13, a14, a15, a16, a17, a18, a19, a20) + gzFile file; + const char *format; + int a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, + a11, a12, a13, a14, a15, a16, a17, a18, a19, a20; + { + char buf[Z_PRINTF_BUFSIZE]; + int len; + + buf[sizeof(buf) - 1] = 0; + #ifdef NO_snprintf + # ifdef HAS_sprintf_void + sprintf(buf, format, a1, a2, a3, a4, a5, a6, a7, a8, + a9, a10, a11, a12, a13, a14, a15, a16, a17, a18, a19, a20); + for (len = 0; len < sizeof(buf); len++) + if (buf[len] == 0) break; + # else + len = sprintf(buf, format, a1, a2, a3, a4, a5, a6, a7, a8, + a9, a10, a11, a12, a13, a14, a15, a16, a17, a18, a19, a20); + # endif + #else + # ifdef HAS_snprintf_void + snprintf(buf, sizeof(buf), format, a1, a2, a3, a4, a5, a6, a7, a8, + a9, a10, a11, a12, a13, a14, a15, a16, a17, a18, a19, a20); + len = strlen(buf); + # else + len = snprintf(buf, sizeof(buf), format, a1, a2, a3, a4, a5, a6, a7, a8, + a9, a10, a11, a12, a13, a14, a15, a16, a17, a18, a19, a20); + # endif + #endif + if (len <= 0 || len >= sizeof(buf) || buf[sizeof(buf) - 1] != 0) + return 0; + return gzwrite(file, buf, len); + } + #endif + + /* =========================================================================== + Writes c, converted to an unsigned char, into the compressed file. + gzputc returns the value that was written, or -1 in case of error. + */ + int ZEXPORT gzputc(file, c) + gzFile file; + int c; + { + unsigned char cc = (unsigned char) c; /* required for big endian systems */ + + return gzwrite(file, &cc, 1) == 1 ? (int)cc : -1; + } + + + /* =========================================================================== + Writes the given null-terminated string to the compressed file, excluding + the terminating null character. + gzputs returns the number of characters written, or -1 in case of error. + */ + int ZEXPORT gzputs(file, s) + gzFile file; + const char *s; + { + return gzwrite(file, (char*)s, (unsigned)strlen(s)); + } + + + /* =========================================================================== + Flushes all pending output into the compressed file. The parameter + flush is as in the deflate() function. + */ + local int do_flush (file, flush) + gzFile file; + int flush; + { + uInt len; + int done = 0; + gz_stream *s = (gz_stream*)file; + + if (s == NULL || s->mode != 'w') return Z_STREAM_ERROR; + + s->stream.avail_in = 0; /* should be zero already anyway */ + + for (;;) { + len = Z_BUFSIZE - s->stream.avail_out; + + if (len != 0) { + if ((uInt)fwrite(s->outbuf, 1, len, s->file) != len) { + s->z_err = Z_ERRNO; + return Z_ERRNO; + } + s->stream.next_out = s->outbuf; + s->stream.avail_out = Z_BUFSIZE; + } + if (done) break; + s->out += s->stream.avail_out; + s->z_err = deflate(&(s->stream), flush); + s->out -= s->stream.avail_out; + + /* Ignore the second of two consecutive flushes: */ + if (len == 0 && s->z_err == Z_BUF_ERROR) s->z_err = Z_OK; + + /* deflate has finished flushing only when it hasn't used up + * all the available space in the output buffer: + */ + done = (s->stream.avail_out != 0 || s->z_err == Z_STREAM_END); + + if (s->z_err != Z_OK && s->z_err != Z_STREAM_END) break; + } + return s->z_err == Z_STREAM_END ? Z_OK : s->z_err; + } + + int ZEXPORT gzflush (file, flush) + gzFile file; + int flush; + { + gz_stream *s = (gz_stream*)file; + int err = do_flush (file, flush); + + if (err) return err; + fflush(s->file); + return s->z_err == Z_STREAM_END ? Z_OK : s->z_err; + } + #endif /* NO_GZCOMPRESS */ + + /* =========================================================================== + Sets the starting position for the next gzread or gzwrite on the given + compressed file. The offset represents a number of bytes in the + gzseek returns the resulting offset location as measured in bytes from + the beginning of the uncompressed stream, or -1 in case of error. + SEEK_END is not implemented, returns error. + In this version of the library, gzseek can be extremely slow. + */ + z_off_t ZEXPORT gzseek (file, offset, whence) + gzFile file; + z_off_t offset; + int whence; + { + gz_stream *s = (gz_stream*)file; + + if (s == NULL || whence == SEEK_END || + s->z_err == Z_ERRNO || s->z_err == Z_DATA_ERROR) { + return -1L; + } + + if (s->mode == 'w') { + #ifdef NO_GZCOMPRESS + return -1L; + #else + if (whence == SEEK_SET) { + offset -= s->in; + } + if (offset < 0) return -1L; + + /* At this point, offset is the number of zero bytes to write. */ + if (s->inbuf == Z_NULL) { + s->inbuf = (Byte*)ALLOC(Z_BUFSIZE); /* for seeking */ + if (s->inbuf == Z_NULL) return -1L; + zmemzero(s->inbuf, Z_BUFSIZE); + } + while (offset > 0) { + uInt size = Z_BUFSIZE; + if (offset < Z_BUFSIZE) size = (uInt)offset; + + size = gzwrite(file, s->inbuf, size); + if (size == 0) return -1L; + + offset -= size; + } + return s->in; + #endif + } + /* Rest of function is for reading only */ + + /* compute absolute position */ + if (whence == SEEK_CUR) { + offset += s->out; + } + if (offset < 0) return -1L; + + if (s->transparent) { + /* map to fseek */ + s->back = EOF; + s->stream.avail_in = 0; + s->stream.next_in = s->inbuf; + if (fseek(s->file, offset, SEEK_SET) < 0) return -1L; + + s->in = s->out = offset; + return offset; + } + + /* For a negative seek, rewind and use positive seek */ + if (offset >= s->out) { + offset -= s->out; + } else if (gzrewind(file) < 0) { + return -1L; + } + /* offset is now the number of bytes to skip. */ + + if (offset != 0 && s->outbuf == Z_NULL) { + s->outbuf = (Byte*)ALLOC(Z_BUFSIZE); + if (s->outbuf == Z_NULL) return -1L; + } + if (offset && s->back != EOF) { + s->back = EOF; + s->out++; + offset--; + if (s->last) s->z_err = Z_STREAM_END; + } + while (offset > 0) { + int size = Z_BUFSIZE; + if (offset < Z_BUFSIZE) size = (int)offset; + + size = gzread(file, s->outbuf, (uInt)size); + if (size <= 0) return -1L; + offset -= size; + } + return s->out; + } + + /* =========================================================================== + Rewinds input file. + */ + int ZEXPORT gzrewind (file) + gzFile file; + { + gz_stream *s = (gz_stream*)file; + + if (s == NULL || s->mode != 'r') return -1; + + s->z_err = Z_OK; + s->z_eof = 0; + s->back = EOF; + s->stream.avail_in = 0; + s->stream.next_in = s->inbuf; + s->crc = crc32(0L, Z_NULL, 0); + if (!s->transparent) (void)inflateReset(&s->stream); + s->in = 0; + s->out = 0; + return fseek(s->file, s->start, SEEK_SET); + } + + /* =========================================================================== + Returns the starting position for the next gzread or gzwrite on the + given compressed file. This position represents a number of bytes in the + uncompressed data stream. + */ + z_off_t ZEXPORT gztell (file) + gzFile file; + { + return gzseek(file, 0L, SEEK_CUR); + } + + /* =========================================================================== + Returns 1 when EOF has previously been detected reading the given + input stream, otherwise zero. + */ + int ZEXPORT gzeof (file) + gzFile file; + { + gz_stream *s = (gz_stream*)file; + + /* With concatenated compressed files that can have embedded + * crc trailers, z_eof is no longer the only/best indicator of EOF + * on a gz_stream. Handle end-of-stream error explicitly here. + */ + if (s == NULL || s->mode != 'r') return 0; + if (s->z_eof) return 1; + return s->z_err == Z_STREAM_END; + } + + /* =========================================================================== + Outputs a long in LSB order to the given file + */ + local void putLong (file, x) + FILE *file; + uLong x; + { + int n; + for (n = 0; n < 4; n++) { + fputc((int)(x & 0xff), file); + x >>= 8; + } + } + + /* =========================================================================== + Reads a long in LSB order from the given gz_stream. Sets z_err in case + of error. + */ + local uLong getLong (s) + gz_stream *s; + { + uLong x = (uLong)get_byte(s); + int c; + + x += ((uLong)get_byte(s))<<8; + x += ((uLong)get_byte(s))<<16; + c = get_byte(s); + if (c == EOF) s->z_err = Z_DATA_ERROR; + x += ((uLong)c)<<24; + return x; + } + + /* =========================================================================== + Flushes all pending output if necessary, closes the compressed file + and deallocates all the (de)compression state. + */ + int ZEXPORT gzclose (file) + gzFile file; + { + int err; + gz_stream *s = (gz_stream*)file; + + if (s == NULL) return Z_STREAM_ERROR; + + if (s->mode == 'w') { + #ifdef NO_GZCOMPRESS + return Z_STREAM_ERROR; + #else + err = do_flush (file, Z_FINISH); + if (err != Z_OK) return destroy((gz_stream*)file); + + putLong (s->file, s->crc); + putLong (s->file, (uLong)(s->in & 0xffffffff)); + #endif + } + return destroy((gz_stream*)file); + } + + /* =========================================================================== + Returns the error message for the last error which occured on the + given compressed file. errnum is set to zlib error number. If an + error occured in the file system and not in the compression library, + errnum is set to Z_ERRNO and the application may consult errno + to get the exact error code. + */ + const char * ZEXPORT gzerror (file, errnum) + gzFile file; + int *errnum; + { + char *m; + gz_stream *s = (gz_stream*)file; + + if (s == NULL) { + *errnum = Z_STREAM_ERROR; + return (const char*)ERR_MSG(Z_STREAM_ERROR); + } + *errnum = s->z_err; + if (*errnum == Z_OK) return (const char*)""; + + m = (char*)(*errnum == Z_ERRNO ? zstrerror(errno) : s->stream.msg); + + if (m == NULL || *m == '\0') m = (char*)ERR_MSG(s->z_err); + + TRYFREE(s->msg); + s->msg = (char*)ALLOC(strlen(s->path) + strlen(m) + 3); + if (s->msg == Z_NULL) return (const char*)ERR_MSG(Z_MEM_ERROR); + strcpy(s->msg, s->path); + strcat(s->msg, ": "); + strcat(s->msg, m); + return (const char*)s->msg; + } + + /* =========================================================================== + Clear the error and end-of-file flags, and do the same for the real file. + */ + void ZEXPORT gzclearerr (file) + gzFile file; + { + gz_stream *s = (gz_stream*)file; + + if (s == NULL) return; + if (s->z_err != Z_STREAM_END) s->z_err = Z_OK; + s->z_eof = 0; + clearerr(s->file); + } Index: llvm-test/Runtime/zlib/infback.c diff -c /dev/null llvm-test/Runtime/zlib/infback.c:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/infback.c Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,619 ---- + /* infback.c -- inflate using a call-back interface + * Copyright (C) 1995-2003 Mark Adler + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* + This code is largely copied from inflate.c. Normally either infback.o or + inflate.o would be linked into an application--not both. The interface + with inffast.c is retained so that optimized assembler-coded versions of + inflate_fast() can be used with either inflate.c or infback.c. + */ + + #include "zutil.h" + #include "inftrees.h" + #include "inflate.h" + #include "inffast.h" + + /* function prototypes */ + local void fixedtables OF((struct inflate_state FAR *state)); + + /* + strm provides memory allocation functions in zalloc and zfree, or + Z_NULL to use the library memory allocation functions. + + windowBits is in the range 8..15, and window is a user-supplied + window and output buffer that is 2**windowBits bytes. + */ + int ZEXPORT inflateBackInit_(strm, windowBits, window, version, stream_size) + z_stream FAR *strm; + int windowBits; + unsigned char FAR *window; + const char *version; + int stream_size; + { + struct inflate_state FAR *state; + + if (version == Z_NULL || version[0] != ZLIB_VERSION[0] || + stream_size != (int)(sizeof(z_stream))) + return Z_VERSION_ERROR; + if (strm == Z_NULL || window == Z_NULL || + windowBits < 8 || windowBits > 15) + return Z_STREAM_ERROR; + strm->msg = Z_NULL; /* in case we return an error */ + if (strm->zalloc == (alloc_func)0) { + strm->zalloc = zcalloc; + strm->opaque = (voidpf)0; + } + if (strm->zfree == (free_func)0) strm->zfree = zcfree; + state = (struct inflate_state FAR *)ZALLOC(strm, 1, + sizeof(struct inflate_state)); + if (state == Z_NULL) return Z_MEM_ERROR; + Tracev((stderr, "inflate: allocated\n")); + strm->state = (voidpf)state; + state->wbits = windowBits; + state->wsize = 1U << windowBits; + state->window = window; + state->write = 0; + state->whave = 0; + return Z_OK; + } + + /* + Return state with length and distance decoding tables and index sizes set to + fixed code decoding. Normally this returns fixed tables from inffixed.h. + If BUILDFIXED is defined, then instead this routine builds the tables the + first time it's called, and returns those tables the first time and + thereafter. This reduces the size of the code by about 2K bytes, in + exchange for a little execution time. However, BUILDFIXED should not be + used for threaded applications, since the rewriting of the tables and virgin + may not be thread-safe. + */ + local void fixedtables(state) + struct inflate_state FAR *state; + { + #ifdef BUILDFIXED + static int virgin = 1; + static code *lenfix, *distfix; + static code fixed[544]; + + /* build fixed huffman tables if first call (may not be thread safe) */ + if (virgin) { + unsigned sym, bits; + static code *next; + + /* literal/length table */ + sym = 0; + while (sym < 144) state->lens[sym++] = 8; + while (sym < 256) state->lens[sym++] = 9; + while (sym < 280) state->lens[sym++] = 7; + while (sym < 288) state->lens[sym++] = 8; + next = fixed; + lenfix = next; + bits = 9; + inflate_table(LENS, state->lens, 288, &(next), &(bits), state->work); + + /* distance table */ + sym = 0; + while (sym < 32) state->lens[sym++] = 5; + distfix = next; + bits = 5; + inflate_table(DISTS, state->lens, 32, &(next), &(bits), state->work); + + /* do this just once */ + virgin = 0; + } + #else /* !BUILDFIXED */ + # include "inffixed.h" + #endif /* BUILDFIXED */ + state->lencode = lenfix; + state->lenbits = 9; + state->distcode = distfix; + state->distbits = 5; + } + + /* Macros for inflateBack(): */ + + /* Load returned state from inflate_fast() */ + #define LOAD() \ + do { \ + put = strm->next_out; \ + left = strm->avail_out; \ + next = strm->next_in; \ + have = strm->avail_in; \ + hold = state->hold; \ + bits = state->bits; \ + } while (0) + + /* Set state from registers for inflate_fast() */ + #define RESTORE() \ + do { \ + strm->next_out = put; \ + strm->avail_out = left; \ + strm->next_in = next; \ + strm->avail_in = have; \ + state->hold = hold; \ + state->bits = bits; \ + } while (0) + + /* Clear the input bit accumulator */ + #define INITBITS() \ + do { \ + hold = 0; \ + bits = 0; \ + } while (0) + + /* Assure that some input is available. If input is requested, but denied, + then return a Z_BUF_ERROR from inflateBack(). */ + #define PULL() \ + do { \ + if (have == 0) { \ + have = in(in_desc, &next); \ + if (have == 0) { \ + next = Z_NULL; \ + ret = Z_BUF_ERROR; \ + goto inf_leave; \ + } \ + } \ + } while (0) + + /* Get a byte of input into the bit accumulator, or return from inflateBack() + with an error if there is no input available. */ + #define PULLBYTE() \ + do { \ + PULL(); \ + have--; \ + hold += (unsigned long)(*next++) << bits; \ + bits += 8; \ + } while (0) + + /* Assure that there are at least n bits in the bit accumulator. If there is + not enough available input to do that, then return from inflateBack() with + an error. */ + #define NEEDBITS(n) \ + do { \ + while (bits < (unsigned)(n)) \ + PULLBYTE(); \ + } while (0) + + /* Return the low n bits of the bit accumulator (n < 16) */ + #define BITS(n) \ + ((unsigned)hold & ((1U << (n)) - 1)) + + /* Remove n bits from the bit accumulator */ + #define DROPBITS(n) \ + do { \ + hold >>= (n); \ + bits -= (unsigned)(n); \ + } while (0) + + /* Remove zero to seven bits as needed to go to a byte boundary */ + #define BYTEBITS() \ + do { \ + hold >>= bits & 7; \ + bits -= bits & 7; \ + } while (0) + + /* Assure that some output space is available, by writing out the window + if it's full. If the write fails, return from inflateBack() with a + Z_BUF_ERROR. */ + #define ROOM() \ + do { \ + if (left == 0) { \ + put = state->window; \ + left = state->wsize; \ + state->whave = left; \ + if (out(out_desc, put, left)) { \ + ret = Z_BUF_ERROR; \ + goto inf_leave; \ + } \ + } \ + } while (0) + + /* + strm provides the memory allocation functions and window buffer on input, + and provides information on the unused input on return. For Z_DATA_ERROR + returns, strm will also provide an error message. + + in() and out() are the call-back input and output functions. When + inflateBack() needs more input, it calls in(). When inflateBack() has + filled the window with output, or when it completes with data in the + window, it calls out() to write out the data. The application must not + change the provided input until in() is called again or inflateBack() + returns. The application must not change the window/output buffer until + inflateBack() returns. + + in() and out() are called with a descriptor parameter provided in the + inflateBack() call. This parameter can be a structure that provides the + information required to do the read or write, as well as accumulated + information on the input and output such as totals and check values. + + in() should return zero on failure. out() should return non-zero on + failure. If either in() or out() fails, than inflateBack() returns a + Z_BUF_ERROR. strm->next_in can be checked for Z_NULL to see whether it + was in() or out() that caused in the error. Otherwise, inflateBack() + returns Z_STREAM_END on success, Z_DATA_ERROR for an deflate format + error, or Z_MEM_ERROR if it could not allocate memory for the state. + inflateBack() can also return Z_STREAM_ERROR if the input parameters + are not correct, i.e. strm is Z_NULL or the state was not initialized. + */ + int ZEXPORT inflateBack(strm, in, in_desc, out, out_desc) + z_stream FAR *strm; + in_func in; + void FAR *in_desc; + out_func out; + void FAR *out_desc; + { + struct inflate_state FAR *state; + unsigned char FAR *next; /* next input */ + unsigned char FAR *put; /* next output */ + unsigned have, left; /* available input and output */ + unsigned long hold; /* bit buffer */ + unsigned bits; /* bits in bit buffer */ + unsigned copy; /* number of stored or match bytes to copy */ + unsigned char FAR *from; /* where to copy match bytes from */ + code this; /* current decoding table entry */ + code last; /* parent table entry */ + unsigned len; /* length to copy for repeats, bits to drop */ + int ret; /* return code */ + static const unsigned short order[19] = /* permutation of code lengths */ + {16, 17, 18, 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15}; + + /* Check that the strm exists and that the state was initialized */ + if (strm == Z_NULL || strm->state == Z_NULL) + return Z_STREAM_ERROR; + state = (struct inflate_state FAR *)strm->state; + + /* Reset the state */ + strm->msg = Z_NULL; + state->mode = TYPE; + state->last = 0; + state->whave = 0; + next = strm->next_in; + have = next != Z_NULL ? strm->avail_in : 0; + hold = 0; + bits = 0; + put = state->window; + left = state->wsize; + + /* Inflate until end of block marked as last */ + for (;;) + switch (state->mode) { + case TYPE: + /* determine and dispatch block type */ + if (state->last) { + BYTEBITS(); + state->mode = DONE; + break; + } + NEEDBITS(3); + state->last = BITS(1); + DROPBITS(1); + switch (BITS(2)) { + case 0: /* stored block */ + Tracev((stderr, "inflate: stored block%s\n", + state->last ? " (last)" : "")); + state->mode = STORED; + break; + case 1: /* fixed block */ + fixedtables(state); + Tracev((stderr, "inflate: fixed codes block%s\n", + state->last ? " (last)" : "")); + state->mode = LEN; /* decode codes */ + break; + case 2: /* dynamic block */ + Tracev((stderr, "inflate: dynamic codes block%s\n", + state->last ? " (last)" : "")); + state->mode = TABLE; + break; + case 3: + strm->msg = (char *)"invalid block type"; + state->mode = BAD; + } + DROPBITS(2); + break; + + case STORED: + /* get and verify stored block length */ + BYTEBITS(); /* go to byte boundary */ + NEEDBITS(32); + if ((hold & 0xffff) != ((hold >> 16) ^ 0xffff)) { + strm->msg = (char *)"invalid stored block lengths"; + state->mode = BAD; + break; + } + state->length = (unsigned)hold & 0xffff; + Tracev((stderr, "inflate: stored length %u\n", + state->length)); + INITBITS(); + + /* copy stored block from input to output */ + while (state->length != 0) { + copy = state->length; + PULL(); + ROOM(); + if (copy > have) copy = have; + if (copy > left) copy = left; + zmemcpy(put, next, copy); + have -= copy; + next += copy; + left -= copy; + put += copy; + state->length -= copy; + } + Tracev((stderr, "inflate: stored end\n")); + state->mode = TYPE; + break; + + case TABLE: + /* get dynamic table entries descriptor */ + NEEDBITS(14); + state->nlen = BITS(5) + 257; + DROPBITS(5); + state->ndist = BITS(5) + 1; + DROPBITS(5); + state->ncode = BITS(4) + 4; + DROPBITS(4); + #ifndef PKZIP_BUG_WORKAROUND + if (state->nlen > 286 || state->ndist > 30) { + strm->msg = (char *)"too many length or distance symbols"; + state->mode = BAD; + break; + } + #endif + Tracev((stderr, "inflate: table sizes ok\n")); + + /* get code length code lengths (not a typo) */ + state->have = 0; + while (state->have < state->ncode) { + NEEDBITS(3); + state->lens[order[state->have++]] = (unsigned short)BITS(3); + DROPBITS(3); + } + while (state->have < 19) + state->lens[order[state->have++]] = 0; + state->next = state->codes; + state->lencode = (code const FAR *)(state->next); + state->lenbits = 7; + ret = inflate_table(CODES, state->lens, 19, &(state->next), + &(state->lenbits), state->work); + if (ret) { + strm->msg = (char *)"invalid code lengths set"; + state->mode = BAD; + break; + } + Tracev((stderr, "inflate: code lengths ok\n")); + + /* get length and distance code code lengths */ + state->have = 0; + while (state->have < state->nlen + state->ndist) { + for (;;) { + this = state->lencode[BITS(state->lenbits)]; + if ((unsigned)(this.bits) <= bits) break; + PULLBYTE(); + } + if (this.val < 16) { + NEEDBITS(this.bits); + DROPBITS(this.bits); + state->lens[state->have++] = this.val; + } + else { + if (this.val == 16) { + NEEDBITS(this.bits + 2); + DROPBITS(this.bits); + if (state->have == 0) { + strm->msg = (char *)"invalid bit length repeat"; + state->mode = BAD; + break; + } + len = (unsigned)(state->lens[state->have - 1]); + copy = 3 + BITS(2); + DROPBITS(2); + } + else if (this.val == 17) { + NEEDBITS(this.bits + 3); + DROPBITS(this.bits); + len = 0; + copy = 3 + BITS(3); + DROPBITS(3); + } + else { + NEEDBITS(this.bits + 7); + DROPBITS(this.bits); + len = 0; + copy = 11 + BITS(7); + DROPBITS(7); + } + if (state->have + copy > state->nlen + state->ndist) { + strm->msg = (char *)"invalid bit length repeat"; + state->mode = BAD; + break; + } + while (copy--) + state->lens[state->have++] = (unsigned short)len; + } + } + + /* build code tables */ + state->next = state->codes; + state->lencode = (code const FAR *)(state->next); + state->lenbits = 9; + ret = inflate_table(LENS, state->lens, state->nlen, &(state->next), + &(state->lenbits), state->work); + if (ret) { + strm->msg = (char *)"invalid literal/lengths set"; + state->mode = BAD; + break; + } + state->distcode = (code const FAR *)(state->next); + state->distbits = 6; + ret = inflate_table(DISTS, state->lens + state->nlen, state->ndist, + &(state->next), &(state->distbits), state->work); + if (ret) { + strm->msg = (char *)"invalid distances set"; + state->mode = BAD; + break; + } + Tracev((stderr, "inflate: codes ok\n")); + state->mode = LEN; + + case LEN: + /* use inflate_fast() if we have enough input and output */ + if (have >= 6 && left >= 258) { + RESTORE(); + if (state->whave < state->wsize) + state->whave = state->wsize - left; + inflate_fast(strm, state->wsize); + LOAD(); + break; + } + + /* get a literal, length, or end-of-block code */ + for (;;) { + this = state->lencode[BITS(state->lenbits)]; + if ((unsigned)(this.bits) <= bits) break; + PULLBYTE(); + } + if (this.op && (this.op & 0xf0) == 0) { + last = this; + for (;;) { + this = state->lencode[last.val + + (BITS(last.bits + last.op) >> last.bits)]; + if ((unsigned)(last.bits + this.bits) <= bits) break; + PULLBYTE(); + } + DROPBITS(last.bits); + } + DROPBITS(this.bits); + state->length = (unsigned)this.val; + + /* process literal */ + if (this.op == 0) { + Tracevv((stderr, this.val >= 0x20 && this.val < 0x7f ? + "inflate: literal '%c'\n" : + "inflate: literal 0x%02x\n", this.val)); + ROOM(); + *put++ = (unsigned char)(state->length); + left--; + state->mode = LEN; + break; + } + + /* process end of block */ + if (this.op & 32) { + Tracevv((stderr, "inflate: end of block\n")); + state->mode = TYPE; + break; + } + + /* invalid code */ + if (this.op & 64) { + strm->msg = (char *)"invalid literal/length code"; + state->mode = BAD; + break; + } + + /* length code -- get extra bits, if any */ + state->extra = (unsigned)(this.op) & 15; + if (state->extra != 0) { + NEEDBITS(state->extra); + state->length += BITS(state->extra); + DROPBITS(state->extra); + } + Tracevv((stderr, "inflate: length %u\n", state->length)); + + /* get distance code */ + for (;;) { + this = state->distcode[BITS(state->distbits)]; + if ((unsigned)(this.bits) <= bits) break; + PULLBYTE(); + } + if ((this.op & 0xf0) == 0) { + last = this; + for (;;) { + this = state->distcode[last.val + + (BITS(last.bits + last.op) >> last.bits)]; + if ((unsigned)(last.bits + this.bits) <= bits) break; + PULLBYTE(); + } + DROPBITS(last.bits); + } + DROPBITS(this.bits); + if (this.op & 64) { + strm->msg = (char *)"invalid distance code"; + state->mode = BAD; + break; + } + state->offset = (unsigned)this.val; + + /* get distance extra bits, if any */ + state->extra = (unsigned)(this.op) & 15; + if (state->extra != 0) { + NEEDBITS(state->extra); + state->offset += BITS(state->extra); + DROPBITS(state->extra); + } + if (state->offset > state->wsize - (state->whave < state->wsize ? + left : 0)) { + strm->msg = (char *)"invalid distance too far back"; + state->mode = BAD; + break; + } + Tracevv((stderr, "inflate: distance %u\n", state->offset)); + + /* copy match from window to output */ + do { + ROOM(); + copy = state->wsize - state->offset; + if (copy < left) { + from = put + copy; + copy = left - copy; + } + else { + from = put - state->offset; + copy = left; + } + if (copy > state->length) copy = state->length; + state->length -= copy; + left -= copy; + do { + *put++ = *from++; + } while (--copy); + } while (state->length != 0); + break; + + case DONE: + /* inflate stream terminated properly -- write leftover output */ + ret = Z_STREAM_END; + if (left < state->wsize) { + if (out(out_desc, state->window, state->wsize - left)) + ret = Z_BUF_ERROR; + } + goto inf_leave; + + case BAD: + ret = Z_DATA_ERROR; + goto inf_leave; + + default: /* can't happen, but makes compilers happy */ + ret = Z_STREAM_ERROR; + goto inf_leave; + } + + /* Return unused input */ + inf_leave: + strm->next_in = next; + strm->avail_in = have; + return ret; + } + + int ZEXPORT inflateBackEnd(strm) + z_stream FAR *strm; + { + if (strm == Z_NULL || strm->state == Z_NULL || strm->zfree == (free_func)0) + return Z_STREAM_ERROR; + ZFREE(strm, strm->state); + strm->state = Z_NULL; + Tracev((stderr, "inflate: end\n")); + return Z_OK; + } Index: llvm-test/Runtime/zlib/inffast.c diff -c /dev/null llvm-test/Runtime/zlib/inffast.c:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/inffast.c Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,305 ---- + /* inffast.c -- fast decoding + * Copyright (C) 1995-2003 Mark Adler + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + #include "zutil.h" + #include "inftrees.h" + #include "inflate.h" + #include "inffast.h" + + #ifndef ASMINF + + /* Allow machine dependent optimization for post-increment or pre-increment. + Based on testing to date, + Pre-increment preferred for: + - PowerPC G3 (Adler) + - MIPS R5000 (Randers-Pehrson) + Post-increment preferred for: + - none + No measurable difference: + - Pentium III (Anderson) + - 68060 (Nikl) + */ + #ifdef POSTINC + # define OFF 0 + # define PUP(a) *(a)++ + #else + # define OFF 1 + # define PUP(a) *++(a) + #endif + + /* + Decode literal, length, and distance codes and write out the resulting + literal and match bytes until either not enough input or output is + available, an end-of-block is encountered, or a data error is encountered. + When large enough input and output buffers are supplied to inflate(), for + example, a 16K input buffer and a 64K output buffer, more than 95% of the + inflate execution time is spent in this routine. + + Entry assumptions: + + state->mode == LEN + strm->avail_in >= 6 + strm->avail_out >= 258 + start >= strm->avail_out + state->bits < 8 + + On return, state->mode is one of: + + LEN -- ran out of enough output space or enough available input + TYPE -- reached end of block code, inflate() to interpret next block + BAD -- error in block data + + Notes: + + - The maximum input bits used by a length/distance pair is 15 bits for the + length code, 5 bits for the length extra, 15 bits for the distance code, + and 13 bits for the distance extra. This totals 48 bits, or six bytes. + Therefore if strm->avail_in >= 6, then there is enough input to avoid + checking for available input while decoding. + + - The maximum bytes that a single length/distance pair can output is 258 + bytes, which is the maximum length that can be coded. inflate_fast() + requires strm->avail_out >= 258 for each loop to avoid checking for + output space. + */ + void inflate_fast(strm, start) + z_streamp strm; + unsigned start; /* inflate()'s starting value for strm->avail_out */ + { + struct inflate_state FAR *state; + unsigned char FAR *in; /* local strm->next_in */ + unsigned char FAR *last; /* while in < last, enough input available */ + unsigned char FAR *out; /* local strm->next_out */ + unsigned char FAR *beg; /* inflate()'s initial strm->next_out */ + unsigned char FAR *end; /* while out < end, enough space available */ + unsigned wsize; /* window size or zero if not using window */ + unsigned whave; /* valid bytes in the window */ + unsigned write; /* window write index */ + unsigned char FAR *window; /* allocated sliding window, if wsize != 0 */ + unsigned long hold; /* local strm->hold */ + unsigned bits; /* local strm->bits */ + code const FAR *lcode; /* local strm->lencode */ + code const FAR *dcode; /* local strm->distcode */ + unsigned lmask; /* mask for first level of length codes */ + unsigned dmask; /* mask for first level of distance codes */ + code this; /* retrieved table entry */ + unsigned op; /* code bits, operation, extra bits, or */ + /* window position, window bytes to copy */ + unsigned len; /* match length, unused bytes */ + unsigned dist; /* match distance */ + unsigned char FAR *from; /* where to copy match from */ + + /* copy state to local variables */ + state = (struct inflate_state FAR *)strm->state; + in = strm->next_in - OFF; + last = in + (strm->avail_in - 5); + out = strm->next_out - OFF; + beg = out - (start - strm->avail_out); + end = out + (strm->avail_out - 257); + wsize = state->wsize; + whave = state->whave; + write = state->write; + window = state->window; + hold = state->hold; + bits = state->bits; + lcode = state->lencode; + dcode = state->distcode; + lmask = (1U << state->lenbits) - 1; + dmask = (1U << state->distbits) - 1; + + /* decode literals and length/distances until end-of-block or not enough + input data or output space */ + do { + if (bits < 15) { + hold += (unsigned long)(PUP(in)) << bits; + bits += 8; + hold += (unsigned long)(PUP(in)) << bits; + bits += 8; + } + this = lcode[hold & lmask]; + dolen: + op = (unsigned)(this.bits); + hold >>= op; + bits -= op; + op = (unsigned)(this.op); + if (op == 0) { /* literal */ + Tracevv((stderr, this.val >= 0x20 && this.val < 0x7f ? + "inflate: literal '%c'\n" : + "inflate: literal 0x%02x\n", this.val)); + PUP(out) = (unsigned char)(this.val); + } + else if (op & 16) { /* length base */ + len = (unsigned)(this.val); + op &= 15; /* number of extra bits */ + if (op) { + if (bits < op) { + hold += (unsigned long)(PUP(in)) << bits; + bits += 8; + } + len += (unsigned)hold & ((1U << op) - 1); + hold >>= op; + bits -= op; + } + Tracevv((stderr, "inflate: length %u\n", len)); + if (bits < 15) { + hold += (unsigned long)(PUP(in)) << bits; + bits += 8; + hold += (unsigned long)(PUP(in)) << bits; + bits += 8; + } + this = dcode[hold & dmask]; + dodist: + op = (unsigned)(this.bits); + hold >>= op; + bits -= op; + op = (unsigned)(this.op); + if (op & 16) { /* distance base */ + dist = (unsigned)(this.val); + op &= 15; /* number of extra bits */ + if (bits < op) { + hold += (unsigned long)(PUP(in)) << bits; + bits += 8; + if (bits < op) { + hold += (unsigned long)(PUP(in)) << bits; + bits += 8; + } + } + dist += (unsigned)hold & ((1U << op) - 1); + hold >>= op; + bits -= op; + Tracevv((stderr, "inflate: distance %u\n", dist)); + op = (unsigned)(out - beg); /* max distance in output */ + if (dist > op) { /* see if copy from window */ + op = dist - op; /* distance back in window */ + if (op > whave) { + strm->msg = (char *)"invalid distance too far back"; + state->mode = BAD; + break; + } + from = window - OFF; + if (write == 0) { /* very common case */ + from += wsize - op; + if (op < len) { /* some from window */ + len -= op; + do { + PUP(out) = PUP(from); + } while (--op); + from = out - dist; /* rest from output */ + } + } + else if (write < op) { /* wrap around window */ + from += wsize + write - op; + op -= write; + if (op < len) { /* some from end of window */ + len -= op; + do { + PUP(out) = PUP(from); + } while (--op); + from = window - OFF; + if (write < len) { /* some from start of window */ + op = write; + len -= op; + do { + PUP(out) = PUP(from); + } while (--op); + from = out - dist; /* rest from output */ + } + } + } + else { /* contiguous in window */ + from += write - op; + if (op < len) { /* some from window */ + len -= op; + do { + PUP(out) = PUP(from); + } while (--op); + from = out - dist; /* rest from output */ + } + } + while (len > 2) { + PUP(out) = PUP(from); + PUP(out) = PUP(from); + PUP(out) = PUP(from); + len -= 3; + } + if (len) { + PUP(out) = PUP(from); + if (len > 1) + PUP(out) = PUP(from); + } + } + else { + from = out - dist; /* copy direct from output */ + do { /* minimum length is three */ + PUP(out) = PUP(from); + PUP(out) = PUP(from); + PUP(out) = PUP(from); + len -= 3; + } while (len > 2); + if (len) { + PUP(out) = PUP(from); + if (len > 1) + PUP(out) = PUP(from); + } + } + } + else if ((op & 64) == 0) { /* 2nd level distance code */ + this = dcode[this.val + (hold & ((1U << op) - 1))]; + goto dodist; + } + else { + strm->msg = (char *)"invalid distance code"; + state->mode = BAD; + break; + } + } + else if ((op & 64) == 0) { /* 2nd level length code */ + this = lcode[this.val + (hold & ((1U << op) - 1))]; + goto dolen; + } + else if (op & 32) { /* end-of-block */ + Tracevv((stderr, "inflate: end of block\n")); + state->mode = TYPE; + break; + } + else { + strm->msg = (char *)"invalid literal/length code"; + state->mode = BAD; + break; + } + } while (in < last && out < end); + + /* return unused bytes (on entry, bits < 8, so in won't go too far back) */ + len = bits >> 3; + in -= len; + bits -= len << 3; + hold &= (1U << bits) - 1; + + /* update state and return */ + strm->next_in = in + OFF; + strm->next_out = out + OFF; + strm->avail_in = (unsigned)(in < last ? 5 + (last - in) : 5 - (in - last)); + strm->avail_out = (unsigned)(out < end ? + 257 + (end - out) : 257 - (out - end)); + state->hold = hold; + state->bits = bits; + return; + } + + /* + inflate_fast() speedups that turned out slower (on a PowerPC G3 750CXe): + - Using bit fields for code structure + - Different op definition to avoid & for extra bits (do & for table bits) + - Three separate decoding do-loops for direct, window, and write == 0 + - Special case for distance > 1 copies to do overlapped load and store copy + - Explicit branch predictions (based on measured branch probabilities) + - Deferring match copy and interspersed it with decoding subsequent codes + - Swapping literal/length else + - Swapping window/direct else + - Larger unrolled copy loops (three is about right) + - Moving len -= 3 statement into middle of loop + */ + + #endif /* !ASMINF */ Index: llvm-test/Runtime/zlib/inffast.h diff -c /dev/null llvm-test/Runtime/zlib/inffast.h:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/inffast.h Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,11 ---- + /* inffast.h -- header to use inffast.c + * Copyright (C) 1995-2003 Mark Adler + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* WARNING: this file should *not* be used by applications. It is + part of the implementation of the compression library and is + subject to change. Applications should only use zlib.h. + */ + + void inflate_fast OF((z_streamp strm, unsigned start)); Index: llvm-test/Runtime/zlib/inffixed.h diff -c /dev/null llvm-test/Runtime/zlib/inffixed.h:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/inffixed.h Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,94 ---- + /* inffixed.h -- table for decoding fixed codes + * Generated automatically by makefixed(). + */ + + /* WARNING: this file should *not* be used by applications. It + is part of the implementation of the compression library and + is subject to change. Applications should only use zlib.h. + */ + + static const code lenfix[512] = { + {96,7,0},{0,8,80},{0,8,16},{20,8,115},{18,7,31},{0,8,112},{0,8,48}, + {0,9,192},{16,7,10},{0,8,96},{0,8,32},{0,9,160},{0,8,0},{0,8,128}, + {0,8,64},{0,9,224},{16,7,6},{0,8,88},{0,8,24},{0,9,144},{19,7,59}, + {0,8,120},{0,8,56},{0,9,208},{17,7,17},{0,8,104},{0,8,40},{0,9,176}, + {0,8,8},{0,8,136},{0,8,72},{0,9,240},{16,7,4},{0,8,84},{0,8,20}, + {21,8,227},{19,7,43},{0,8,116},{0,8,52},{0,9,200},{17,7,13},{0,8,100}, + {0,8,36},{0,9,168},{0,8,4},{0,8,132},{0,8,68},{0,9,232},{16,7,8}, + {0,8,92},{0,8,28},{0,9,152},{20,7,83},{0,8,124},{0,8,60},{0,9,216}, + {18,7,23},{0,8,108},{0,8,44},{0,9,184},{0,8,12},{0,8,140},{0,8,76}, + {0,9,248},{16,7,3},{0,8,82},{0,8,18},{21,8,163},{19,7,35},{0,8,114}, + {0,8,50},{0,9,196},{17,7,11},{0,8,98},{0,8,34},{0,9,164},{0,8,2}, + {0,8,130},{0,8,66},{0,9,228},{16,7,7},{0,8,90},{0,8,26},{0,9,148}, + {20,7,67},{0,8,122},{0,8,58},{0,9,212},{18,7,19},{0,8,106},{0,8,42}, + {0,9,180},{0,8,10},{0,8,138},{0,8,74},{0,9,244},{16,7,5},{0,8,86}, + {0,8,22},{64,8,0},{19,7,51},{0,8,118},{0,8,54},{0,9,204},{17,7,15}, + {0,8,102},{0,8,38},{0,9,172},{0,8,6},{0,8,134},{0,8,70},{0,9,236}, + {16,7,9},{0,8,94},{0,8,30},{0,9,156},{20,7,99},{0,8,126},{0,8,62}, + {0,9,220},{18,7,27},{0,8,110},{0,8,46},{0,9,188},{0,8,14},{0,8,142}, + {0,8,78},{0,9,252},{96,7,0},{0,8,81},{0,8,17},{21,8,131},{18,7,31}, + {0,8,113},{0,8,49},{0,9,194},{16,7,10},{0,8,97},{0,8,33},{0,9,162}, + {0,8,1},{0,8,129},{0,8,65},{0,9,226},{16,7,6},{0,8,89},{0,8,25}, + {0,9,146},{19,7,59},{0,8,121},{0,8,57},{0,9,210},{17,7,17},{0,8,105}, + {0,8,41},{0,9,178},{0,8,9},{0,8,137},{0,8,73},{0,9,242},{16,7,4}, + {0,8,85},{0,8,21},{16,8,258},{19,7,43},{0,8,117},{0,8,53},{0,9,202}, + {17,7,13},{0,8,101},{0,8,37},{0,9,170},{0,8,5},{0,8,133},{0,8,69}, + {0,9,234},{16,7,8},{0,8,93},{0,8,29},{0,9,154},{20,7,83},{0,8,125}, + {0,8,61},{0,9,218},{18,7,23},{0,8,109},{0,8,45},{0,9,186},{0,8,13}, + {0,8,141},{0,8,77},{0,9,250},{16,7,3},{0,8,83},{0,8,19},{21,8,195}, + {19,7,35},{0,8,115},{0,8,51},{0,9,198},{17,7,11},{0,8,99},{0,8,35}, + {0,9,166},{0,8,3},{0,8,131},{0,8,67},{0,9,230},{16,7,7},{0,8,91}, + {0,8,27},{0,9,150},{20,7,67},{0,8,123},{0,8,59},{0,9,214},{18,7,19}, + {0,8,107},{0,8,43},{0,9,182},{0,8,11},{0,8,139},{0,8,75},{0,9,246}, + {16,7,5},{0,8,87},{0,8,23},{64,8,0},{19,7,51},{0,8,119},{0,8,55}, + {0,9,206},{17,7,15},{0,8,103},{0,8,39},{0,9,174},{0,8,7},{0,8,135}, + {0,8,71},{0,9,238},{16,7,9},{0,8,95},{0,8,31},{0,9,158},{20,7,99}, + {0,8,127},{0,8,63},{0,9,222},{18,7,27},{0,8,111},{0,8,47},{0,9,190}, + {0,8,15},{0,8,143},{0,8,79},{0,9,254},{96,7,0},{0,8,80},{0,8,16}, + {20,8,115},{18,7,31},{0,8,112},{0,8,48},{0,9,193},{16,7,10},{0,8,96}, + {0,8,32},{0,9,161},{0,8,0},{0,8,128},{0,8,64},{0,9,225},{16,7,6}, + {0,8,88},{0,8,24},{0,9,145},{19,7,59},{0,8,120},{0,8,56},{0,9,209}, + {17,7,17},{0,8,104},{0,8,40},{0,9,177},{0,8,8},{0,8,136},{0,8,72}, + {0,9,241},{16,7,4},{0,8,84},{0,8,20},{21,8,227},{19,7,43},{0,8,116}, + {0,8,52},{0,9,201},{17,7,13},{0,8,100},{0,8,36},{0,9,169},{0,8,4}, + {0,8,132},{0,8,68},{0,9,233},{16,7,8},{0,8,92},{0,8,28},{0,9,153}, + {20,7,83},{0,8,124},{0,8,60},{0,9,217},{18,7,23},{0,8,108},{0,8,44}, + {0,9,185},{0,8,12},{0,8,140},{0,8,76},{0,9,249},{16,7,3},{0,8,82}, + {0,8,18},{21,8,163},{19,7,35},{0,8,114},{0,8,50},{0,9,197},{17,7,11}, + {0,8,98},{0,8,34},{0,9,165},{0,8,2},{0,8,130},{0,8,66},{0,9,229}, + {16,7,7},{0,8,90},{0,8,26},{0,9,149},{20,7,67},{0,8,122},{0,8,58}, + {0,9,213},{18,7,19},{0,8,106},{0,8,42},{0,9,181},{0,8,10},{0,8,138}, + {0,8,74},{0,9,245},{16,7,5},{0,8,86},{0,8,22},{64,8,0},{19,7,51}, + {0,8,118},{0,8,54},{0,9,205},{17,7,15},{0,8,102},{0,8,38},{0,9,173}, + {0,8,6},{0,8,134},{0,8,70},{0,9,237},{16,7,9},{0,8,94},{0,8,30}, + {0,9,157},{20,7,99},{0,8,126},{0,8,62},{0,9,221},{18,7,27},{0,8,110}, + {0,8,46},{0,9,189},{0,8,14},{0,8,142},{0,8,78},{0,9,253},{96,7,0}, + {0,8,81},{0,8,17},{21,8,131},{18,7,31},{0,8,113},{0,8,49},{0,9,195}, + {16,7,10},{0,8,97},{0,8,33},{0,9,163},{0,8,1},{0,8,129},{0,8,65}, + {0,9,227},{16,7,6},{0,8,89},{0,8,25},{0,9,147},{19,7,59},{0,8,121}, + {0,8,57},{0,9,211},{17,7,17},{0,8,105},{0,8,41},{0,9,179},{0,8,9}, + {0,8,137},{0,8,73},{0,9,243},{16,7,4},{0,8,85},{0,8,21},{16,8,258}, + {19,7,43},{0,8,117},{0,8,53},{0,9,203},{17,7,13},{0,8,101},{0,8,37}, + {0,9,171},{0,8,5},{0,8,133},{0,8,69},{0,9,235},{16,7,8},{0,8,93}, + {0,8,29},{0,9,155},{20,7,83},{0,8,125},{0,8,61},{0,9,219},{18,7,23}, + {0,8,109},{0,8,45},{0,9,187},{0,8,13},{0,8,141},{0,8,77},{0,9,251}, + {16,7,3},{0,8,83},{0,8,19},{21,8,195},{19,7,35},{0,8,115},{0,8,51}, + {0,9,199},{17,7,11},{0,8,99},{0,8,35},{0,9,167},{0,8,3},{0,8,131}, + {0,8,67},{0,9,231},{16,7,7},{0,8,91},{0,8,27},{0,9,151},{20,7,67}, + {0,8,123},{0,8,59},{0,9,215},{18,7,19},{0,8,107},{0,8,43},{0,9,183}, + {0,8,11},{0,8,139},{0,8,75},{0,9,247},{16,7,5},{0,8,87},{0,8,23}, + {64,8,0},{19,7,51},{0,8,119},{0,8,55},{0,9,207},{17,7,15},{0,8,103}, + {0,8,39},{0,9,175},{0,8,7},{0,8,135},{0,8,71},{0,9,239},{16,7,9}, + {0,8,95},{0,8,31},{0,9,159},{20,7,99},{0,8,127},{0,8,63},{0,9,223}, + {18,7,27},{0,8,111},{0,8,47},{0,9,191},{0,8,15},{0,8,143},{0,8,79}, + {0,9,255} + }; + + static const code distfix[32] = { + {16,5,1},{23,5,257},{19,5,17},{27,5,4097},{17,5,5},{25,5,1025}, + {21,5,65},{29,5,16385},{16,5,3},{24,5,513},{20,5,33},{28,5,8193}, + {18,5,9},{26,5,2049},{22,5,129},{64,5,0},{16,5,2},{23,5,385}, + {19,5,25},{27,5,6145},{17,5,7},{25,5,1537},{21,5,97},{29,5,24577}, + {16,5,4},{24,5,769},{20,5,49},{28,5,12289},{18,5,13},{26,5,3073}, + {22,5,193},{64,5,0} + }; Index: llvm-test/Runtime/zlib/inflate.c diff -c /dev/null llvm-test/Runtime/zlib/inflate.c:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/inflate.c Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,1270 ---- + /* inflate.c -- zlib decompression + * Copyright (C) 1995-2003 Mark Adler + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* + * Change history: + * + * 1.2.beta0 24 Nov 2002 + * - First version -- complete rewrite of inflate to simplify code, avoid + * creation of window when not needed, minimize use of window when it is + * needed, make inffast.c even faster, implement gzip decoding, and to + * improve code readability and style over the previous zlib inflate code + * + * 1.2.beta1 25 Nov 2002 + * - Use pointers for available input and output checking in inffast.c + * - Remove input and output counters in inffast.c + * - Change inffast.c entry and loop from avail_in >= 7 to >= 6 + * - Remove unnecessary second byte pull from length extra in inffast.c + * - Unroll direct copy to three copies per loop in inffast.c + * + * 1.2.beta2 4 Dec 2002 + * - Change external routine names to reduce potential conflicts + * - Correct filename to inffixed.h for fixed tables in inflate.c + * - Make hbuf[] unsigned char to match parameter type in inflate.c + * - Change strm->next_out[-state->offset] to *(strm->next_out - state->offset) + * to avoid negation problem on Alphas (64 bit) in inflate.c + * + * 1.2.beta3 22 Dec 2002 + * - Add comments on state->bits assertion in inffast.c + * - Add comments on op field in inftrees.h + * - Fix bug in reuse of allocated window after inflateReset() + * - Remove bit fields--back to byte structure for speed + * - Remove distance extra == 0 check in inflate_fast()--only helps for lengths + * - Change post-increments to pre-increments in inflate_fast(), PPC biased? + * - Add compile time option, POSTINC, to use post-increments instead (Intel?) + * - Make MATCH copy in inflate() much faster for when inflate_fast() not used + * - Use local copies of stream next and avail values, as well as local bit + * buffer and bit count in inflate()--for speed when inflate_fast() not used + * + * 1.2.beta4 1 Jan 2003 + * - Split ptr - 257 statements in inflate_table() to avoid compiler warnings + * - Move a comment on output buffer sizes from inffast.c to inflate.c + * - Add comments in inffast.c to introduce the inflate_fast() routine + * - Rearrange window copies in inflate_fast() for speed and simplification + * - Unroll last copy for window match in inflate_fast() + * - Use local copies of window variables in inflate_fast() for speed + * - Pull out common write == 0 case for speed in inflate_fast() + * - Make op and len in inflate_fast() unsigned for consistency + * - Add FAR to lcode and dcode declarations in inflate_fast() + * - Simplified bad distance check in inflate_fast() + * - Added inflateBackInit(), inflateBack(), and inflateBackEnd() in new + * source file infback.c to provide a call-back interface to inflate for + * programs like gzip and unzip -- uses window as output buffer to avoid + * window copying + * + * 1.2.beta5 1 Jan 2003 + * - Improved inflateBack() interface to allow the caller to provide initial + * input in strm. + * - Fixed stored blocks bug in inflateBack() + * + * 1.2.beta6 4 Jan 2003 + * - Added comments in inffast.c on effectiveness of POSTINC + * - Typecasting all around to reduce compiler warnings + * - Changed loops from while (1) or do {} while (1) to for (;;), again to + * make compilers happy + * - Changed type of window in inflateBackInit() to unsigned char * + * + * 1.2.beta7 27 Jan 2003 + * - Changed many types to unsigned or unsigned short to avoid warnings + * - Added inflateCopy() function + * + * 1.2.0 9 Mar 2003 + * - Changed inflateBack() interface to provide separate opaque descriptors + * for the in() and out() functions + * - Changed inflateBack() argument and in_func typedef to swap the length + * and buffer address return values for the input function + * - Check next_in and next_out for Z_NULL on entry to inflate() + * + * The history for versions after 1.2.0 are in ChangeLog in zlib distribution. + */ + + #include "zutil.h" + #include "inftrees.h" + #include "inflate.h" + #include "inffast.h" + + #ifdef MAKEFIXED + # ifndef BUILDFIXED + # define BUILDFIXED + # endif + #endif + + /* function prototypes */ + local void fixedtables OF((struct inflate_state FAR *state)); + local int updatewindow OF((z_streamp strm, unsigned out)); + #ifdef BUILDFIXED + void makefixed OF((void)); + #endif + local unsigned syncsearch OF((unsigned FAR *have, unsigned char FAR *buf, + unsigned len)); + + int ZEXPORT inflateReset(strm) + z_streamp strm; + { + struct inflate_state FAR *state; + + if (strm == Z_NULL || strm->state == Z_NULL) return Z_STREAM_ERROR; + state = (struct inflate_state FAR *)strm->state; + strm->total_in = strm->total_out = state->total = 0; + strm->msg = Z_NULL; + state->mode = HEAD; + state->last = 0; + state->havedict = 0; + state->wsize = 0; + state->whave = 0; + state->hold = 0; + state->bits = 0; + state->lencode = state->distcode = state->next = state->codes; + Tracev((stderr, "inflate: reset\n")); + return Z_OK; + } + + int ZEXPORT inflateInit2_(strm, windowBits, version, stream_size) + z_streamp strm; + int windowBits; + const char *version; + int stream_size; + { + struct inflate_state FAR *state; + + if (version == Z_NULL || version[0] != ZLIB_VERSION[0] || + stream_size != (int)(sizeof(z_stream))) + return Z_VERSION_ERROR; + if (strm == Z_NULL) return Z_STREAM_ERROR; + strm->msg = Z_NULL; /* in case we return an error */ + if (strm->zalloc == (alloc_func)0) { + strm->zalloc = zcalloc; + strm->opaque = (voidpf)0; + } + if (strm->zfree == (free_func)0) strm->zfree = zcfree; + state = (struct inflate_state FAR *) + ZALLOC(strm, 1, sizeof(struct inflate_state)); + if (state == Z_NULL) return Z_MEM_ERROR; + Tracev((stderr, "inflate: allocated\n")); + strm->state = (voidpf)state; + if (windowBits < 0) { + state->wrap = 0; + windowBits = -windowBits; + } + else { + state->wrap = (windowBits >> 4) + 1; + #ifdef GUNZIP + if (windowBits < 48) windowBits &= 15; + #endif + } + if (windowBits < 8 || windowBits > 15) { + ZFREE(strm, state); + strm->state = Z_NULL; + return Z_STREAM_ERROR; + } + state->wbits = (unsigned)windowBits; + state->window = Z_NULL; + return inflateReset(strm); + } + + int ZEXPORT inflateInit_(strm, version, stream_size) + z_streamp strm; + const char *version; + int stream_size; + { + return inflateInit2_(strm, DEF_WBITS, version, stream_size); + } + + /* + Return state with length and distance decoding tables and index sizes set to + fixed code decoding. Normally this returns fixed tables from inffixed.h. + If BUILDFIXED is defined, then instead this routine builds the tables the + first time it's called, and returns those tables the first time and + thereafter. This reduces the size of the code by about 2K bytes, in + exchange for a little execution time. However, BUILDFIXED should not be + used for threaded applications, since the rewriting of the tables and virgin + may not be thread-safe. + */ + local void fixedtables(state) + struct inflate_state FAR *state; + { + #ifdef BUILDFIXED + static int virgin = 1; + static code *lenfix, *distfix; + static code fixed[544]; + + /* build fixed huffman tables if first call (may not be thread safe) */ + if (virgin) { + unsigned sym, bits; + static code *next; + + /* literal/length table */ + sym = 0; + while (sym < 144) state->lens[sym++] = 8; + while (sym < 256) state->lens[sym++] = 9; + while (sym < 280) state->lens[sym++] = 7; + while (sym < 288) state->lens[sym++] = 8; + next = fixed; + lenfix = next; + bits = 9; + inflate_table(LENS, state->lens, 288, &(next), &(bits), state->work); + + /* distance table */ + sym = 0; + while (sym < 32) state->lens[sym++] = 5; + distfix = next; + bits = 5; + inflate_table(DISTS, state->lens, 32, &(next), &(bits), state->work); + + /* do this just once */ + virgin = 0; + } + #else /* !BUILDFIXED */ + # include "inffixed.h" + #endif /* BUILDFIXED */ + state->lencode = lenfix; + state->lenbits = 9; + state->distcode = distfix; + state->distbits = 5; + } + + #ifdef MAKEFIXED + #include + + /* + Write out the inffixed.h that is #include'd above. Defining MAKEFIXED also + defines BUILDFIXED, so the tables are built on the fly. makefixed() writes + those tables to stdout, which would be piped to inffixed.h. A small program + can simply call makefixed to do this: + + void makefixed(void); + + int main(void) + { + makefixed(); + return 0; + } + + Then that can be linked with zlib built with MAKEFIXED defined and run: + + a.out > inffixed.h + */ + void makefixed() + { + unsigned low, size; + struct inflate_state state; + + fixedtables(&state); + puts(" /* inffixed.h -- table for decoding fixed codes"); + puts(" * Generated automatically by makefixed()."); + puts(" */"); + puts(""); + puts(" /* WARNING: this file should *not* be used by applications."); + puts(" It is part of the implementation of this library and is"); + puts(" subject to change. Applications should only use zlib.h."); + puts(" */"); + puts(""); + size = 1U << 9; + printf(" static const code lenfix[%u] = {", size); + low = 0; + for (;;) { + if ((low % 7) == 0) printf("\n "); + printf("{%u,%u,%d}", state.lencode[low].op, state.lencode[low].bits, + state.lencode[low].val); + if (++low == size) break; + putchar(','); + } + puts("\n };"); + size = 1U << 5; + printf("\n static const code distfix[%u] = {", size); + low = 0; + for (;;) { + if ((low % 6) == 0) printf("\n "); + printf("{%u,%u,%d}", state.distcode[low].op, state.distcode[low].bits, + state.distcode[low].val); + if (++low == size) break; + putchar(','); + } + puts("\n };"); + } + #endif /* MAKEFIXED */ + + /* + Update the window with the last wsize (normally 32K) bytes written before + returning. If window does not exist yet, create it. This is only called + when a window is already in use, or when output has been written during this + inflate call, but the end of the deflate stream has not been reached yet. + It is also called to create a window for dictionary data when a dictionary + is loaded. + + Providing output buffers larger than 32K to inflate() should provide a speed + advantage, since only the last 32K of output is copied to the sliding window + upon return from inflate(), and since all distances after the first 32K of + output will fall in the output data, making match copies simpler and faster. + The advantage may be dependent on the size of the processor's data caches. + */ + local int updatewindow(strm, out) + z_streamp strm; + unsigned out; + { + struct inflate_state FAR *state; + unsigned copy, dist; + + state = (struct inflate_state FAR *)strm->state; + + /* if it hasn't been done already, allocate space for the window */ + if (state->window == Z_NULL) { + state->window = (unsigned char FAR *) + ZALLOC(strm, 1U << state->wbits, + sizeof(unsigned char)); + if (state->window == Z_NULL) return 1; + } + + /* if window not in use yet, initialize */ + if (state->wsize == 0) { + state->wsize = 1U << state->wbits; + state->write = 0; + state->whave = 0; + } + + /* copy state->wsize or less output bytes into the circular window */ + copy = out - strm->avail_out; + if (copy >= state->wsize) { + zmemcpy(state->window, strm->next_out - state->wsize, state->wsize); + state->write = 0; + state->whave = state->wsize; + } + else { + dist = state->wsize - state->write; + if (dist > copy) dist = copy; + zmemcpy(state->window + state->write, strm->next_out - copy, dist); + copy -= dist; + if (copy) { + zmemcpy(state->window, strm->next_out - copy, copy); + state->write = copy; + state->whave = state->wsize; + } + else { + state->write += dist; + if (state->write == state->wsize) state->write = 0; + if (state->whave < state->wsize) state->whave += dist; + } + } + return 0; + } + + /* Macros for inflate(): */ + + /* check function to use adler32() for zlib or crc32() for gzip */ + #ifdef GUNZIP + # define UPDATE(check, buf, len) \ + (state->flags ? crc32(check, buf, len) : adler32(check, buf, len)) + #else + # define UPDATE(check, buf, len) adler32(check, buf, len) + #endif + + /* check macros for header crc */ + #ifdef GUNZIP + # define CRC2(check, word) \ + do { \ + hbuf[0] = (unsigned char)(word); \ + hbuf[1] = (unsigned char)((word) >> 8); \ + check = crc32(check, hbuf, 2); \ + } while (0) + + # define CRC4(check, word) \ + do { \ + hbuf[0] = (unsigned char)(word); \ + hbuf[1] = (unsigned char)((word) >> 8); \ + hbuf[2] = (unsigned char)((word) >> 16); \ + hbuf[3] = (unsigned char)((word) >> 24); \ + check = crc32(check, hbuf, 4); \ + } while (0) + #endif + + /* Load registers with state in inflate() for speed */ + #define LOAD() \ + do { \ + put = strm->next_out; \ + left = strm->avail_out; \ + next = strm->next_in; \ + have = strm->avail_in; \ + hold = state->hold; \ + bits = state->bits; \ + } while (0) + + /* Restore state from registers in inflate() */ + #define RESTORE() \ + do { \ + strm->next_out = put; \ + strm->avail_out = left; \ + strm->next_in = next; \ + strm->avail_in = have; \ + state->hold = hold; \ + state->bits = bits; \ + } while (0) + + /* Clear the input bit accumulator */ + #define INITBITS() \ + do { \ + hold = 0; \ + bits = 0; \ + } while (0) + + /* Get a byte of input into the bit accumulator, or return from inflate() + if there is no input available. */ + #define PULLBYTE() \ + do { \ + if (have == 0) goto inf_leave; \ + have--; \ + hold += (unsigned long)(*next++) << bits; \ + bits += 8; \ + } while (0) + + /* Assure that there are at least n bits in the bit accumulator. If there is + not enough available input to do that, then return from inflate(). */ + #define NEEDBITS(n) \ + do { \ + while (bits < (unsigned)(n)) \ + PULLBYTE(); \ + } while (0) + + /* Return the low n bits of the bit accumulator (n < 16) */ + #define BITS(n) \ + ((unsigned)hold & ((1U << (n)) - 1)) + + /* Remove n bits from the bit accumulator */ + #define DROPBITS(n) \ + do { \ + hold >>= (n); \ + bits -= (unsigned)(n); \ + } while (0) + + /* Remove zero to seven bits as needed to go to a byte boundary */ + #define BYTEBITS() \ + do { \ + hold >>= bits & 7; \ + bits -= bits & 7; \ + } while (0) + + /* Reverse the bytes in a 32-bit value */ + #define REVERSE(q) \ + ((((q) >> 24) & 0xff) + (((q) >> 8) & 0xff00) + \ + (((q) & 0xff00) << 8) + (((q) & 0xff) << 24)) + + /* + inflate() uses a state machine to process as much input data and generate as + much output data as possible before returning. The state machine is + structured roughly as follows: + + for (;;) switch (state) { + ... + case STATEn: + if (not enough input data or output space to make progress) + return; + ... make progress ... + state = STATEm; + break; + ... + } + + so when inflate() is called again, the same case is attempted again, and + if the appropriate resources are provided, the machine proceeds to the + next state. The NEEDBITS() macro is usually the way the state evaluates + whether it can proceed or should return. NEEDBITS() does the return if + the requested bits are not available. The typical use of the BITS macros + is: + + NEEDBITS(n); + ... do something with BITS(n) ... + DROPBITS(n); + + where NEEDBITS(n) either returns from inflate() if there isn't enough + input left to load n bits into the accumulator, or it continues. BITS(n) + gives the low n bits in the accumulator. When done, DROPBITS(n) drops + the low n bits off the accumulator. INITBITS() clears the accumulator + and sets the number of available bits to zero. BYTEBITS() discards just + enough bits to put the accumulator on a byte boundary. After BYTEBITS() + and a NEEDBITS(8), then BITS(8) would return the next byte in the stream. + + NEEDBITS(n) uses PULLBYTE() to get an available byte of input, or to return + if there is no input available. The decoding of variable length codes uses + PULLBYTE() directly in order to pull just enough bytes to decode the next + code, and no more. + + Some states loop until they get enough input, making sure that enough + state information is maintained to continue the loop where it left off + if NEEDBITS() returns in the loop. For example, want, need, and keep + would all have to actually be part of the saved state in case NEEDBITS() + returns: + + case STATEw: + while (want < need) { + NEEDBITS(n); + keep[want++] = BITS(n); + DROPBITS(n); + } + state = STATEx; + case STATEx: + + As shown above, if the next state is also the next case, then the break + is omitted. + + A state may also return if there is not enough output space available to + complete that state. Those states are copying stored data, writing a + literal byte, and copying a matching string. + + When returning, a "goto inf_leave" is used to update the total counters, + update the check value, and determine whether any progress has been made + during that inflate() call in order to return the proper return code. + Progress is defined as a change in either strm->avail_in or strm->avail_out. + When there is a window, goto inf_leave will update the window with the last + output written. If a goto inf_leave occurs in the middle of decompression + and there is no window currently, goto inf_leave will create one and copy + output to the window for the next call of inflate(). + + In this implementation, the flush parameter of inflate() only affects the + return code (per zlib.h). inflate() always writes as much as possible to + strm->next_out, given the space available and the provided input--the effect + documented in zlib.h of Z_SYNC_FLUSH. Furthermore, inflate() always defers + the allocation of and copying into a sliding window until necessary, which + provides the effect documented in zlib.h for Z_FINISH when the entire input + stream available. So the only thing the flush parameter actually does is: + when flush is set to Z_FINISH, inflate() cannot return Z_OK. Instead it + will return Z_BUF_ERROR if it has not reached the end of the stream. + */ + + int ZEXPORT inflate(strm, flush) + z_streamp strm; + int flush; + { + struct inflate_state FAR *state; + unsigned char FAR *next; /* next input */ + unsigned char FAR *put; /* next output */ + unsigned have, left; /* available input and output */ + unsigned long hold; /* bit buffer */ + unsigned bits; /* bits in bit buffer */ + unsigned in, out; /* save starting available input and output */ + unsigned copy; /* number of stored or match bytes to copy */ + unsigned char FAR *from; /* where to copy match bytes from */ + code this; /* current decoding table entry */ + code last; /* parent table entry */ + unsigned len; /* length to copy for repeats, bits to drop */ + int ret; /* return code */ + #ifdef GUNZIP + unsigned char hbuf[4]; /* buffer for gzip header crc calculation */ + #endif + static const unsigned short order[19] = /* permutation of code lengths */ + {16, 17, 18, 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15}; + + if (strm == Z_NULL || strm->state == Z_NULL || strm->next_out == Z_NULL || + (strm->next_in == Z_NULL && strm->avail_in != 0)) + return Z_STREAM_ERROR; + + state = (struct inflate_state FAR *)strm->state; + if (state->mode == TYPE) state->mode = TYPEDO; /* skip check */ + LOAD(); + in = have; + out = left; + ret = Z_OK; + for (;;) + switch (state->mode) { + case HEAD: + if (state->wrap == 0) { + state->mode = TYPEDO; + break; + } + NEEDBITS(16); + #ifdef GUNZIP + if ((state->wrap & 2) && hold == 0x8b1f) { /* gzip header */ + state->check = crc32(0L, Z_NULL, 0); + CRC2(state->check, hold); + INITBITS(); + state->mode = FLAGS; + break; + } + state->flags = 0; /* expect zlib header */ + if (!(state->wrap & 1) || /* check if zlib header allowed */ + #else + if ( + #endif + ((BITS(8) << 8) + (hold >> 8)) % 31) { + strm->msg = (char *)"incorrect header check"; + state->mode = BAD; + break; + } + if (BITS(4) != Z_DEFLATED) { + strm->msg = (char *)"unknown compression method"; + state->mode = BAD; + break; + } + DROPBITS(4); + if (BITS(4) + 8 > state->wbits) { + strm->msg = (char *)"invalid window size"; + state->mode = BAD; + break; + } + Tracev((stderr, "inflate: zlib header ok\n")); + strm->adler = state->check = adler32(0L, Z_NULL, 0); + state->mode = hold & 0x200 ? DICTID : TYPE; + INITBITS(); + break; + #ifdef GUNZIP + case FLAGS: + NEEDBITS(16); + state->flags = (int)(hold); + if ((state->flags & 0xff) != Z_DEFLATED) { + strm->msg = (char *)"unknown compression method"; + state->mode = BAD; + break; + } + if (state->flags & 0xe000) { + strm->msg = (char *)"unknown header flags set"; + state->mode = BAD; + break; + } + if (state->flags & 0x0200) CRC2(state->check, hold); + INITBITS(); + state->mode = TIME; + case TIME: + NEEDBITS(32); + if (state->flags & 0x0200) CRC4(state->check, hold); + INITBITS(); + state->mode = OS; + case OS: + NEEDBITS(16); + if (state->flags & 0x0200) CRC2(state->check, hold); + INITBITS(); + state->mode = EXLEN; + case EXLEN: + if (state->flags & 0x0400) { + NEEDBITS(16); + state->length = (unsigned)(hold); + if (state->flags & 0x0200) CRC2(state->check, hold); + INITBITS(); + } + state->mode = EXTRA; + case EXTRA: + if (state->flags & 0x0400) { + copy = state->length; + if (copy > have) copy = have; + if (copy) { + if (state->flags & 0x0200) + state->check = crc32(state->check, next, copy); + have -= copy; + next += copy; + state->length -= copy; + } + if (state->length) goto inf_leave; + } + state->mode = NAME; + case NAME: + if (state->flags & 0x0800) { + if (have == 0) goto inf_leave; + copy = 0; + do { + len = (unsigned)(next[copy++]); + } while (len && copy < have); + if (state->flags & 0x02000) + state->check = crc32(state->check, next, copy); + have -= copy; + next += copy; + if (len) goto inf_leave; + } + state->mode = COMMENT; + case COMMENT: + if (state->flags & 0x1000) { + if (have == 0) goto inf_leave; + copy = 0; + do { + len = (unsigned)(next[copy++]); + } while (len && copy < have); + if (state->flags & 0x02000) + state->check = crc32(state->check, next, copy); + have -= copy; + next += copy; + if (len) goto inf_leave; + } + state->mode = HCRC; + case HCRC: + if (state->flags & 0x0200) { + NEEDBITS(16); + if (hold != (state->check & 0xffff)) { + strm->msg = (char *)"header crc mismatch"; + state->mode = BAD; + break; + } + INITBITS(); + } + strm->adler = state->check = crc32(0L, Z_NULL, 0); + state->mode = TYPE; + break; + #endif + case DICTID: + NEEDBITS(32); + strm->adler = state->check = REVERSE(hold); + INITBITS(); + state->mode = DICT; + case DICT: + if (state->havedict == 0) { + RESTORE(); + return Z_NEED_DICT; + } + strm->adler = state->check = adler32(0L, Z_NULL, 0); + state->mode = TYPE; + case TYPE: + if (flush == Z_BLOCK) goto inf_leave; + case TYPEDO: + if (state->last) { + BYTEBITS(); + state->mode = CHECK; + break; + } + NEEDBITS(3); + state->last = BITS(1); + DROPBITS(1); + switch (BITS(2)) { + case 0: /* stored block */ + Tracev((stderr, "inflate: stored block%s\n", + state->last ? " (last)" : "")); + state->mode = STORED; + break; + case 1: /* fixed block */ + fixedtables(state); + Tracev((stderr, "inflate: fixed codes block%s\n", + state->last ? " (last)" : "")); + state->mode = LEN; /* decode codes */ + break; + case 2: /* dynamic block */ + Tracev((stderr, "inflate: dynamic codes block%s\n", + state->last ? " (last)" : "")); + state->mode = TABLE; + break; + case 3: + strm->msg = (char *)"invalid block type"; + state->mode = BAD; + } + DROPBITS(2); + break; + case STORED: + BYTEBITS(); /* go to byte boundary */ + NEEDBITS(32); + if ((hold & 0xffff) != ((hold >> 16) ^ 0xffff)) { + strm->msg = (char *)"invalid stored block lengths"; + state->mode = BAD; + break; + } + state->length = (unsigned)hold & 0xffff; + Tracev((stderr, "inflate: stored length %u\n", + state->length)); + INITBITS(); + state->mode = COPY; + case COPY: + copy = state->length; + if (copy) { + if (copy > have) copy = have; + if (copy > left) copy = left; + if (copy == 0) goto inf_leave; + zmemcpy(put, next, copy); + have -= copy; + next += copy; + left -= copy; + put += copy; + state->length -= copy; + break; + } + Tracev((stderr, "inflate: stored end\n")); + state->mode = TYPE; + break; + case TABLE: + NEEDBITS(14); + state->nlen = BITS(5) + 257; + DROPBITS(5); + state->ndist = BITS(5) + 1; + DROPBITS(5); + state->ncode = BITS(4) + 4; + DROPBITS(4); + #ifndef PKZIP_BUG_WORKAROUND + if (state->nlen > 286 || state->ndist > 30) { + strm->msg = (char *)"too many length or distance symbols"; + state->mode = BAD; + break; + } + #endif + Tracev((stderr, "inflate: table sizes ok\n")); + state->have = 0; + state->mode = LENLENS; + case LENLENS: + while (state->have < state->ncode) { + NEEDBITS(3); + state->lens[order[state->have++]] = (unsigned short)BITS(3); + DROPBITS(3); + } + while (state->have < 19) + state->lens[order[state->have++]] = 0; + state->next = state->codes; + state->lencode = (code const FAR *)(state->next); + state->lenbits = 7; + ret = inflate_table(CODES, state->lens, 19, &(state->next), + &(state->lenbits), state->work); + if (ret) { + strm->msg = (char *)"invalid code lengths set"; + state->mode = BAD; + break; + } + Tracev((stderr, "inflate: code lengths ok\n")); + state->have = 0; + state->mode = CODELENS; + case CODELENS: + while (state->have < state->nlen + state->ndist) { + for (;;) { + this = state->lencode[BITS(state->lenbits)]; + if ((unsigned)(this.bits) <= bits) break; + PULLBYTE(); + } + if (this.val < 16) { + NEEDBITS(this.bits); + DROPBITS(this.bits); + state->lens[state->have++] = this.val; + } + else { + if (this.val == 16) { + NEEDBITS(this.bits + 2); + DROPBITS(this.bits); + if (state->have == 0) { + strm->msg = (char *)"invalid bit length repeat"; + state->mode = BAD; + break; + } + len = state->lens[state->have - 1]; + copy = 3 + BITS(2); + DROPBITS(2); + } + else if (this.val == 17) { + NEEDBITS(this.bits + 3); + DROPBITS(this.bits); + len = 0; + copy = 3 + BITS(3); + DROPBITS(3); + } + else { + NEEDBITS(this.bits + 7); + DROPBITS(this.bits); + len = 0; + copy = 11 + BITS(7); + DROPBITS(7); + } + if (state->have + copy > state->nlen + state->ndist) { + strm->msg = (char *)"invalid bit length repeat"; + state->mode = BAD; + break; + } + while (copy--) + state->lens[state->have++] = (unsigned short)len; + } + } + + /* build code tables */ + state->next = state->codes; + state->lencode = (code const FAR *)(state->next); + state->lenbits = 9; + ret = inflate_table(LENS, state->lens, state->nlen, &(state->next), + &(state->lenbits), state->work); + if (ret) { + strm->msg = (char *)"invalid literal/lengths set"; + state->mode = BAD; + break; + } + state->distcode = (code const FAR *)(state->next); + state->distbits = 6; + ret = inflate_table(DISTS, state->lens + state->nlen, state->ndist, + &(state->next), &(state->distbits), state->work); + if (ret) { + strm->msg = (char *)"invalid distances set"; + state->mode = BAD; + break; + } + Tracev((stderr, "inflate: codes ok\n")); + state->mode = LEN; + case LEN: + if (have >= 6 && left >= 258) { + RESTORE(); + inflate_fast(strm, out); + LOAD(); + break; + } + for (;;) { + this = state->lencode[BITS(state->lenbits)]; + if ((unsigned)(this.bits) <= bits) break; + PULLBYTE(); + } + if (this.op && (this.op & 0xf0) == 0) { + last = this; + for (;;) { + this = state->lencode[last.val + + (BITS(last.bits + last.op) >> last.bits)]; + if ((unsigned)(last.bits + this.bits) <= bits) break; + PULLBYTE(); + } + DROPBITS(last.bits); + } + DROPBITS(this.bits); + state->length = (unsigned)this.val; + if ((int)(this.op) == 0) { + Tracevv((stderr, this.val >= 0x20 && this.val < 0x7f ? + "inflate: literal '%c'\n" : + "inflate: literal 0x%02x\n", this.val)); + state->mode = LIT; + break; + } + if (this.op & 32) { + Tracevv((stderr, "inflate: end of block\n")); + state->mode = TYPE; + break; + } + if (this.op & 64) { + strm->msg = (char *)"invalid literal/length code"; + state->mode = BAD; + break; + } + state->extra = (unsigned)(this.op) & 15; + state->mode = LENEXT; + case LENEXT: + if (state->extra) { + NEEDBITS(state->extra); + state->length += BITS(state->extra); + DROPBITS(state->extra); + } + Tracevv((stderr, "inflate: length %u\n", state->length)); + state->mode = DIST; + case DIST: + for (;;) { + this = state->distcode[BITS(state->distbits)]; + if ((unsigned)(this.bits) <= bits) break; + PULLBYTE(); + } + if ((this.op & 0xf0) == 0) { + last = this; + for (;;) { + this = state->distcode[last.val + + (BITS(last.bits + last.op) >> last.bits)]; + if ((unsigned)(last.bits + this.bits) <= bits) break; + PULLBYTE(); + } + DROPBITS(last.bits); + } + DROPBITS(this.bits); + if (this.op & 64) { + strm->msg = (char *)"invalid distance code"; + state->mode = BAD; + break; + } + state->offset = (unsigned)this.val; + state->extra = (unsigned)(this.op) & 15; + state->mode = DISTEXT; + case DISTEXT: + if (state->extra) { + NEEDBITS(state->extra); + state->offset += BITS(state->extra); + DROPBITS(state->extra); + } + if (state->offset > state->whave + out - left) { + strm->msg = (char *)"invalid distance too far back"; + state->mode = BAD; + break; + } + Tracevv((stderr, "inflate: distance %u\n", state->offset)); + state->mode = MATCH; + case MATCH: + if (left == 0) goto inf_leave; + copy = out - left; + if (state->offset > copy) { /* copy from window */ + copy = state->offset - copy; + if (copy > state->write) { + copy -= state->write; + from = state->window + (state->wsize - copy); + } + else + from = state->window + (state->write - copy); + if (copy > state->length) copy = state->length; + } + else { /* copy from output */ + from = put - state->offset; + copy = state->length; + } + if (copy > left) copy = left; + left -= copy; + state->length -= copy; + do { + *put++ = *from++; + } while (--copy); + if (state->length == 0) state->mode = LEN; + break; + case LIT: + if (left == 0) goto inf_leave; + *put++ = (unsigned char)(state->length); + left--; + state->mode = LEN; + break; + case CHECK: + if (state->wrap) { + NEEDBITS(32); + out -= left; + strm->total_out += out; + state->total += out; + if (out) + strm->adler = state->check = + UPDATE(state->check, put - out, out); + out = left; + if (( + #ifdef GUNZIP + state->flags ? hold : + #endif + REVERSE(hold)) != state->check) { + strm->msg = (char *)"incorrect data check"; + state->mode = BAD; + break; + } + INITBITS(); + Tracev((stderr, "inflate: check matches trailer\n")); + } + #ifdef GUNZIP + state->mode = LENGTH; + case LENGTH: + if (state->wrap && state->flags) { + NEEDBITS(32); + if (hold != (state->total & 0xffffffffUL)) { + strm->msg = (char *)"incorrect length check"; + state->mode = BAD; + break; + } + INITBITS(); + Tracev((stderr, "inflate: length matches trailer\n")); + } + #endif + state->mode = DONE; + case DONE: + ret = Z_STREAM_END; + goto inf_leave; + case BAD: + ret = Z_DATA_ERROR; + goto inf_leave; + case MEM: + return Z_MEM_ERROR; + case SYNC: + default: + return Z_STREAM_ERROR; + } + + /* + Return from inflate(), updating the total counts and the check value. + If there was no progress during the inflate() call, return a buffer + error. Call updatewindow() to create and/or update the window state. + Note: a memory error from inflate() is non-recoverable. + */ + inf_leave: + RESTORE(); + if (state->wsize || (state->mode < CHECK && out != strm->avail_out)) + if (updatewindow(strm, out)) { + state->mode = MEM; + return Z_MEM_ERROR; + } + in -= strm->avail_in; + out -= strm->avail_out; + strm->total_in += in; + strm->total_out += out; + state->total += out; + if (state->wrap && out) + strm->adler = state->check = + UPDATE(state->check, strm->next_out - out, out); + strm->data_type = state->bits + (state->last ? 64 : 0) + + (state->mode == TYPE ? 128 : 0); + if (((in == 0 && out == 0) || flush == Z_FINISH) && ret == Z_OK) + ret = Z_BUF_ERROR; + return ret; + } + + int ZEXPORT inflateEnd(strm) + z_streamp strm; + { + struct inflate_state FAR *state; + if (strm == Z_NULL || strm->state == Z_NULL || strm->zfree == (free_func)0) + return Z_STREAM_ERROR; + state = (struct inflate_state FAR *)strm->state; + if (state->window != Z_NULL) ZFREE(strm, state->window); + ZFREE(strm, strm->state); + strm->state = Z_NULL; + Tracev((stderr, "inflate: end\n")); + return Z_OK; + } + + int ZEXPORT inflateSetDictionary(strm, dictionary, dictLength) + z_streamp strm; + const Bytef *dictionary; + uInt dictLength; + { + struct inflate_state FAR *state; + unsigned long id; + + /* check state */ + if (strm == Z_NULL || strm->state == Z_NULL) return Z_STREAM_ERROR; + state = (struct inflate_state FAR *)strm->state; + if (state->mode != DICT) return Z_STREAM_ERROR; + + /* check for correct dictionary id */ + id = adler32(0L, Z_NULL, 0); + id = adler32(id, dictionary, dictLength); + if (id != state->check) return Z_DATA_ERROR; + + /* copy dictionary to window */ + if (updatewindow(strm, strm->avail_out)) { + state->mode = MEM; + return Z_MEM_ERROR; + } + if (dictLength > state->wsize) { + zmemcpy(state->window, dictionary + dictLength - state->wsize, + state->wsize); + state->whave = state->wsize; + } + else { + zmemcpy(state->window + state->wsize - dictLength, dictionary, + dictLength); + state->whave = dictLength; + } + state->havedict = 1; + Tracev((stderr, "inflate: dictionary set\n")); + return Z_OK; + } + + /* + Search buf[0..len-1] for the pattern: 0, 0, 0xff, 0xff. Return when found + or when out of input. When called, *have is the number of pattern bytes + found in order so far, in 0..3. On return *have is updated to the new + state. If on return *have equals four, then the pattern was found and the + return value is how many bytes were read including the last byte of the + pattern. If *have is less than four, then the pattern has not been found + yet and the return value is len. In the latter case, syncsearch() can be + called again with more data and the *have state. *have is initialized to + zero for the first call. + */ + local unsigned syncsearch(have, buf, len) + unsigned FAR *have; + unsigned char FAR *buf; + unsigned len; + { + unsigned got; + unsigned next; + + got = *have; + next = 0; + while (next < len && got < 4) { + if ((int)(buf[next]) == (got < 2 ? 0 : 0xff)) + got++; + else if (buf[next]) + got = 0; + else + got = 4 - got; + next++; + } + *have = got; + return next; + } + + int ZEXPORT inflateSync(strm) + z_streamp strm; + { + unsigned len; /* number of bytes to look at or looked at */ + unsigned long in, out; /* temporary to save total_in and total_out */ + unsigned char buf[4]; /* to restore bit buffer to byte string */ + struct inflate_state FAR *state; + + /* check parameters */ + if (strm == Z_NULL || strm->state == Z_NULL) return Z_STREAM_ERROR; + state = (struct inflate_state FAR *)strm->state; + if (strm->avail_in == 0 && state->bits < 8) return Z_BUF_ERROR; + + /* if first time, start search in bit buffer */ + if (state->mode != SYNC) { + state->mode = SYNC; + state->hold <<= state->bits & 7; + state->bits -= state->bits & 7; + len = 0; + while (state->bits >= 8) { + buf[len++] = (unsigned char)(state->hold); + state->hold >>= 8; + state->bits -= 8; + } + state->have = 0; + syncsearch(&(state->have), buf, len); + } + + /* search available input */ + len = syncsearch(&(state->have), strm->next_in, strm->avail_in); + strm->avail_in -= len; + strm->next_in += len; + strm->total_in += len; + + /* return no joy or set up to restart inflate() on a new block */ + if (state->have != 4) return Z_DATA_ERROR; + in = strm->total_in; out = strm->total_out; + inflateReset(strm); + strm->total_in = in; strm->total_out = out; + state->mode = TYPE; + return Z_OK; + } + + /* + Returns true if inflate is currently at the end of a block generated by + Z_SYNC_FLUSH or Z_FULL_FLUSH. This function is used by one PPP + implementation to provide an additional safety check. PPP uses + Z_SYNC_FLUSH but removes the length bytes of the resulting empty stored + block. When decompressing, PPP checks that at the end of input packet, + inflate is waiting for these length bytes. + */ + int ZEXPORT inflateSyncPoint(strm) + z_streamp strm; + { + struct inflate_state FAR *state; + + if (strm == Z_NULL || strm->state == Z_NULL) return Z_STREAM_ERROR; + state = (struct inflate_state FAR *)strm->state; + return state->mode == STORED && state->bits == 0; + } + + int ZEXPORT inflateCopy(dest, source) + z_streamp dest; + z_streamp source; + { + struct inflate_state FAR *state; + struct inflate_state FAR *copy; + unsigned char FAR *window; + + /* check input */ + if (dest == Z_NULL || source == Z_NULL || source->state == Z_NULL || + source->zalloc == (alloc_func)0 || source->zfree == (free_func)0) + return Z_STREAM_ERROR; + state = (struct inflate_state FAR *)source->state; + + /* allocate space */ + copy = (struct inflate_state FAR *) + ZALLOC(source, 1, sizeof(struct inflate_state)); + if (copy == Z_NULL) return Z_MEM_ERROR; + window = Z_NULL; + if (state->window != Z_NULL) { + window = (unsigned char FAR *) + ZALLOC(source, 1U << state->wbits, sizeof(unsigned char)); + if (window == Z_NULL) { + ZFREE(source, copy); + return Z_MEM_ERROR; + } + } + + /* copy state */ + *dest = *source; + *copy = *state; + copy->lencode = copy->codes + (state->lencode - state->codes); + copy->distcode = copy->codes + (state->distcode - state->codes); + copy->next = copy->codes + (state->next - state->codes); + if (window != Z_NULL) + zmemcpy(window, state->window, 1U << state->wbits); + copy->window = window; + dest->state = (voidpf)copy; + return Z_OK; + } Index: llvm-test/Runtime/zlib/inflate.h diff -c /dev/null llvm-test/Runtime/zlib/inflate.h:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/inflate.h Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,117 ---- + /* inflate.h -- internal inflate state definition + * Copyright (C) 1995-2003 Mark Adler + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* WARNING: this file should *not* be used by applications. It is + part of the implementation of the compression library and is + subject to change. Applications should only use zlib.h. + */ + + /* define NO_GZIP when compiling if you want to disable gzip header and + trailer decoding by inflate(). NO_GZIP would be used to avoid linking in + the crc code when it is not needed. For shared libraries, gzip decoding + should be left enabled. */ + #ifndef NO_GZIP + # define GUNZIP + #endif + + /* Possible inflate modes between inflate() calls */ + typedef enum { + HEAD, /* i: waiting for magic header */ + #ifdef GUNZIP + FLAGS, /* i: waiting for method and flags (gzip) */ + TIME, /* i: waiting for modification time (gzip) */ + OS, /* i: waiting for extra flags and operating system (gzip) */ + EXLEN, /* i: waiting for extra length (gzip) */ + EXTRA, /* i: waiting for extra bytes (gzip) */ + NAME, /* i: waiting for end of file name (gzip) */ + COMMENT, /* i: waiting for end of comment (gzip) */ + HCRC, /* i: waiting for header crc (gzip) */ + #endif + DICTID, /* i: waiting for dictionary check value */ + DICT, /* waiting for inflateSetDictionary() call */ + TYPE, /* i: waiting for type bits, including last-flag bit */ + TYPEDO, /* i: same, but skip check to exit inflate on new block */ + STORED, /* i: waiting for stored size (length and complement) */ + COPY, /* i/o: waiting for input or output to copy stored block */ + TABLE, /* i: waiting for dynamic block table lengths */ + LENLENS, /* i: waiting for code length code lengths */ + CODELENS, /* i: waiting for length/lit and distance code lengths */ + LEN, /* i: waiting for length/lit code */ + LENEXT, /* i: waiting for length extra bits */ + DIST, /* i: waiting for distance code */ + DISTEXT, /* i: waiting for distance extra bits */ + MATCH, /* o: waiting for output space to copy string */ + LIT, /* o: waiting for output space to write literal */ + CHECK, /* i: waiting for 32-bit check value */ + #ifdef GUNZIP + LENGTH, /* i: waiting for 32-bit length (gzip) */ + #endif + DONE, /* finished check, done -- remain here until reset */ + BAD, /* got a data error -- remain here until reset */ + MEM, /* got an inflate() memory error -- remain here until reset */ + SYNC /* looking for synchronization bytes to restart inflate() */ + } inflate_mode; + + /* + State transitions between above modes - + + (most modes can go to the BAD or MEM mode -- not shown for clarity) + + Process header: + HEAD -> (gzip) or (zlib) + (gzip) -> FLAGS -> TIME -> OS -> EXLEN -> EXTRA -> NAME + NAME -> COMMENT -> HCRC -> TYPE + (zlib) -> DICTID or TYPE + DICTID -> DICT -> TYPE + Read deflate blocks: + TYPE -> STORED or TABLE or LEN or CHECK + STORED -> COPY -> TYPE + TABLE -> LENLENS -> CODELENS -> LEN + Read deflate codes: + LEN -> LENEXT or LIT or TYPE + LENEXT -> DIST -> DISTEXT -> MATCH -> LEN + LIT -> LEN + Process trailer: + CHECK -> LENGTH -> DONE + */ + + /* state maintained between inflate() calls. Approximately 7K bytes. */ + struct inflate_state { + inflate_mode mode; /* current inflate mode */ + int last; /* true if processing last block */ + int wrap; /* bit 0 true for zlib, bit 1 true for gzip */ + int havedict; /* true if dictionary provided */ + int flags; /* gzip header method and flags (0 if zlib) */ + unsigned long check; /* protected copy of check value */ + unsigned long total; /* protected copy of output count */ + /* sliding window */ + unsigned wbits; /* log base 2 of requested window size */ + unsigned wsize; /* window size or zero if not using window */ + unsigned whave; /* valid bytes in the window */ + unsigned write; /* window write index */ + unsigned char FAR *window; /* allocated sliding window, if needed */ + /* bit accumulator */ + unsigned long hold; /* input bit accumulator */ + unsigned bits; /* number of bits in "in" */ + /* for string and stored block copying */ + unsigned length; /* literal or length of data to copy */ + unsigned offset; /* distance back to copy string from */ + /* for table and code decoding */ + unsigned extra; /* extra bits needed */ + /* fixed and dynamic code tables */ + code const FAR *lencode; /* starting table for length/literal codes */ + code const FAR *distcode; /* starting table for distance codes */ + unsigned lenbits; /* index bits for lencode */ + unsigned distbits; /* index bits for distcode */ + /* dynamic table building */ + unsigned ncode; /* number of code length code lengths */ + unsigned nlen; /* number of length code lengths */ + unsigned ndist; /* number of distance code lengths */ + unsigned have; /* number of code lengths in lens[] */ + code FAR *next; /* next available space in codes[] */ + unsigned short lens[320]; /* temporary storage for code lengths */ + unsigned short work[288]; /* work area for code table building */ + code codes[ENOUGH]; /* space for code tables */ + }; Index: llvm-test/Runtime/zlib/inftrees.c diff -c /dev/null llvm-test/Runtime/zlib/inftrees.c:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/inftrees.c Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,321 ---- + /* inftrees.c -- generate Huffman trees for efficient decoding + * Copyright (C) 1995-2003 Mark Adler + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + #include "zutil.h" + #include "inftrees.h" + + #define MAXBITS 15 + + const char inflate_copyright[] = + " inflate 1.2.1 Copyright 1995-2003 Mark Adler "; + /* + If you use the zlib library in a product, an acknowledgment is welcome + in the documentation of your product. If for some reason you cannot + include such an acknowledgment, I would appreciate that you keep this + copyright string in the executable of your product. + */ + + /* + Build a set of tables to decode the provided canonical Huffman code. + The code lengths are lens[0..codes-1]. The result starts at *table, + whose indices are 0..2^bits-1. work is a writable array of at least + lens shorts, which is used as a work area. type is the type of code + to be generated, CODES, LENS, or DISTS. On return, zero is success, + -1 is an invalid code, and +1 means that ENOUGH isn't enough. table + on return points to the next available entry's address. bits is the + requested root table index bits, and on return it is the actual root + table index bits. It will differ if the request is greater than the + longest code or if it is less than the shortest code. + */ + int inflate_table(type, lens, codes, table, bits, work) + codetype type; + unsigned short FAR *lens; + unsigned codes; + code FAR * FAR *table; + unsigned FAR *bits; + unsigned short FAR *work; + { + unsigned len; /* a code's length in bits */ + unsigned sym; /* index of code symbols */ + unsigned min, max; /* minimum and maximum code lengths */ + unsigned root; /* number of index bits for root table */ + unsigned curr; /* number of index bits for current table */ + unsigned drop; /* code bits to drop for sub-table */ + int left; /* number of prefix codes available */ + unsigned used; /* code entries in table used */ + unsigned huff; /* Huffman code */ + unsigned incr; /* for incrementing code, index */ + unsigned fill; /* index for replicating entries */ + unsigned low; /* low bits for current root entry */ + unsigned mask; /* mask for low root bits */ + code this; /* table entry for duplication */ + code FAR *next; /* next available space in table */ + const unsigned short FAR *base; /* base value table to use */ + const unsigned short FAR *extra; /* extra bits table to use */ + int end; /* use base and extra for symbol > end */ + unsigned short count[MAXBITS+1]; /* number of codes of each length */ + unsigned short offs[MAXBITS+1]; /* offsets in table for each length */ + static const unsigned short lbase[31] = { /* Length codes 257..285 base */ + 3, 4, 5, 6, 7, 8, 9, 10, 11, 13, 15, 17, 19, 23, 27, 31, + 35, 43, 51, 59, 67, 83, 99, 115, 131, 163, 195, 227, 258, 0, 0}; + static const unsigned short lext[31] = { /* Length codes 257..285 extra */ + 16, 16, 16, 16, 16, 16, 16, 16, 17, 17, 17, 17, 18, 18, 18, 18, + 19, 19, 19, 19, 20, 20, 20, 20, 21, 21, 21, 21, 16, 76, 66}; + static const unsigned short dbase[32] = { /* Distance codes 0..29 base */ + 1, 2, 3, 4, 5, 7, 9, 13, 17, 25, 33, 49, 65, 97, 129, 193, + 257, 385, 513, 769, 1025, 1537, 2049, 3073, 4097, 6145, + 8193, 12289, 16385, 24577, 0, 0}; + static const unsigned short dext[32] = { /* Distance codes 0..29 extra */ + 16, 16, 16, 16, 17, 17, 18, 18, 19, 19, 20, 20, 21, 21, 22, 22, + 23, 23, 24, 24, 25, 25, 26, 26, 27, 27, + 28, 28, 29, 29, 64, 64}; + + /* + Process a set of code lengths to create a canonical Huffman code. The + code lengths are lens[0..codes-1]. Each length corresponds to the + symbols 0..codes-1. The Huffman code is generated by first sorting the + symbols by length from short to long, and retaining the symbol order + for codes with equal lengths. Then the code starts with all zero bits + for the first code of the shortest length, and the codes are integer + increments for the same length, and zeros are appended as the length + increases. For the deflate format, these bits are stored backwards + from their more natural integer increment ordering, and so when the + decoding tables are built in the large loop below, the integer codes + are incremented backwards. + + This routine assumes, but does not check, that all of the entries in + lens[] are in the range 0..MAXBITS. The caller must assure this. + 1..MAXBITS is interpreted as that code length. zero means that that + symbol does not occur in this code. + + The codes are sorted by computing a count of codes for each length, + creating from that a table of starting indices for each length in the + sorted table, and then entering the symbols in order in the sorted + table. The sorted table is work[], with that space being provided by + the caller. + + The length counts are used for other purposes as well, i.e. finding + the minimum and maximum length codes, determining if there are any + codes at all, checking for a valid set of lengths, and looking ahead + at length counts to determine sub-table sizes when building the + decoding tables. + */ + + /* accumulate lengths for codes (assumes lens[] all in 0..MAXBITS) */ + for (len = 0; len <= MAXBITS; len++) + count[len] = 0; + for (sym = 0; sym < codes; sym++) + count[lens[sym]]++; + + /* bound code lengths, force root to be within code lengths */ + root = *bits; + for (max = MAXBITS; max >= 1; max--) + if (count[max] != 0) break; + if (root > max) root = max; + if (max == 0) return -1; /* no codes! */ + for (min = 1; min <= MAXBITS; min++) + if (count[min] != 0) break; + if (root < min) root = min; + + /* check for an over-subscribed or incomplete set of lengths */ + left = 1; + for (len = 1; len <= MAXBITS; len++) { + left <<= 1; + left -= count[len]; + if (left < 0) return -1; /* over-subscribed */ + } + if (left > 0 && (type == CODES || (codes - count[0] != 1))) + return -1; /* incomplete set */ + + /* generate offsets into symbol table for each length for sorting */ + offs[1] = 0; + for (len = 1; len < MAXBITS; len++) + offs[len + 1] = offs[len] + count[len]; + + /* sort symbols by length, by symbol order within each length */ + for (sym = 0; sym < codes; sym++) + if (lens[sym] != 0) work[offs[lens[sym]]++] = (unsigned short)sym; + + /* + Create and fill in decoding tables. In this loop, the table being + filled is at next and has curr index bits. The code being used is huff + with length len. That code is converted to an index by dropping drop + bits off of the bottom. For codes where len is less than drop + curr, + those top drop + curr - len bits are incremented through all values to + fill the table with replicated entries. + + root is the number of index bits for the root table. When len exceeds + root, sub-tables are created pointed to by the root entry with an index + of the low root bits of huff. This is saved in low to check for when a + new sub-table should be started. drop is zero when the root table is + being filled, and drop is root when sub-tables are being filled. + + When a new sub-table is needed, it is necessary to look ahead in the + code lengths to determine what size sub-table is needed. The length + counts are used for this, and so count[] is decremented as codes are + entered in the tables. + + used keeps track of how many table entries have been allocated from the + provided *table space. It is checked when a LENS table is being made + against the space in *table, ENOUGH, minus the maximum space needed by + the worst case distance code, MAXD. This should never happen, but the + sufficiency of ENOUGH has not been proven exhaustively, hence the check. + This assumes that when type == LENS, bits == 9. + + sym increments through all symbols, and the loop terminates when + all codes of length max, i.e. all codes, have been processed. This + routine permits incomplete codes, so another loop after this one fills + in the rest of the decoding tables with invalid code markers. + */ + + /* set up for code type */ + switch (type) { + case CODES: + base = extra = work; /* dummy value--not used */ + end = 19; + break; + case LENS: + base = lbase; + base -= 257; + extra = lext; + extra -= 257; + end = 256; + break; + default: /* DISTS */ + base = dbase; + extra = dext; + end = -1; + } + + /* initialize state for loop */ + huff = 0; /* starting code */ + sym = 0; /* starting code symbol */ + len = min; /* starting code length */ + next = *table; /* current table to fill in */ + curr = root; /* current table index bits */ + drop = 0; /* current bits to drop from code for index */ + low = (unsigned)(-1); /* trigger new sub-table when len > root */ + used = 1U << root; /* use root table entries */ + mask = used - 1; /* mask for comparing low */ + + /* check available table space */ + if (type == LENS && used >= ENOUGH - MAXD) + return 1; + + /* process all codes and make table entries */ + for (;;) { + /* create table entry */ + this.bits = (unsigned char)(len - drop); + if ((int)(work[sym]) < end) { + this.op = (unsigned char)0; + this.val = work[sym]; + } + else if ((int)(work[sym]) > end) { + this.op = (unsigned char)(extra[work[sym]]); + this.val = base[work[sym]]; + } + else { + this.op = (unsigned char)(32 + 64); /* end of block */ + this.val = 0; + } + + /* replicate for those indices with low len bits equal to huff */ + incr = 1U << (len - drop); + fill = 1U << curr; + do { + fill -= incr; + next[(huff >> drop) + fill] = this; + } while (fill != 0); + + /* backwards increment the len-bit code huff */ + incr = 1U << (len - 1); + while (huff & incr) + incr >>= 1; + if (incr != 0) { + huff &= incr - 1; + huff += incr; + } + else + huff = 0; + + /* go to next symbol, update count, len */ + sym++; + if (--(count[len]) == 0) { + if (len == max) break; + len = lens[work[sym]]; + } + + /* create new sub-table if needed */ + if (len > root && (huff & mask) != low) { + /* if first time, transition to sub-tables */ + if (drop == 0) + drop = root; + + /* increment past last table */ + next += 1U << curr; + + /* determine length of next table */ + curr = len - drop; + left = (int)(1 << curr); + while (curr + drop < max) { + left -= count[curr + drop]; + if (left <= 0) break; + curr++; + left <<= 1; + } + + /* check for enough space */ + used += 1U << curr; + if (type == LENS && used >= ENOUGH - MAXD) + return 1; + + /* point entry in root table to sub-table */ + low = huff & mask; + (*table)[low].op = (unsigned char)curr; + (*table)[low].bits = (unsigned char)root; + (*table)[low].val = (unsigned short)(next - *table); + } + } + + /* + Fill in rest of table for incomplete codes. This loop is similar to the + loop above in incrementing huff for table indices. It is assumed that + len is equal to curr + drop, so there is no loop needed to increment + through high index bits. When the current sub-table is filled, the loop + drops back to the root table to fill in any remaining entries there. + */ + this.op = (unsigned char)64; /* invalid code marker */ + this.bits = (unsigned char)(len - drop); + this.val = (unsigned short)0; + while (huff != 0) { + /* when done with sub-table, drop back to root table */ + if (drop != 0 && (huff & mask) != low) { + drop = 0; + len = root; + next = *table; + curr = root; + this.bits = (unsigned char)len; + } + + /* put invalid code marker in table */ + next[huff >> drop] = this; + + /* backwards increment the len-bit code huff */ + incr = 1U << (len - 1); + while (huff & incr) + incr >>= 1; + if (incr != 0) { + huff &= incr - 1; + huff += incr; + } + else + huff = 0; + } + + /* set return parameters */ + *table += used; + *bits = root; + return 0; + } Index: llvm-test/Runtime/zlib/inftrees.h diff -c /dev/null llvm-test/Runtime/zlib/inftrees.h:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/inftrees.h Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,55 ---- + /* inftrees.h -- header to use inftrees.c + * Copyright (C) 1995-2003 Mark Adler + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* WARNING: this file should *not* be used by applications. It is + part of the implementation of the compression library and is + subject to change. Applications should only use zlib.h. + */ + + /* Structure for decoding tables. Each entry provides either the + information needed to do the operation requested by the code that + indexed that table entry, or it provides a pointer to another + table that indexes more bits of the code. op indicates whether + the entry is a pointer to another table, a literal, a length or + distance, an end-of-block, or an invalid code. For a table + pointer, the low four bits of op is the number of index bits of + that table. For a length or distance, the low four bits of op + is the number of extra bits to get after the code. bits is + the number of bits in this code or part of the code to drop off + of the bit buffer. val is the actual byte to output in the case + of a literal, the base length or distance, or the offset from + the current table to the next table. Each entry is four bytes. */ + typedef struct { + unsigned char op; /* operation, extra bits, table bits */ + unsigned char bits; /* bits in this part of the code */ + unsigned short val; /* offset in table or code value */ + } code; + + /* op values as set by inflate_table(): + 00000000 - literal + 0000tttt - table link, tttt != 0 is the number of table index bits + 0001eeee - length or distance, eeee is the number of extra bits + 01100000 - end of block + 01000000 - invalid code + */ + + /* Maximum size of dynamic tree. The maximum found in a long but non- + exhaustive search was 1004 code structures (850 for length/literals + and 154 for distances, the latter actually the result of an + exhaustive search). The true maximum is not known, but the value + below is more than safe. */ + #define ENOUGH 1440 + #define MAXD 154 + + /* Type of code to build for inftable() */ + typedef enum { + CODES, + LENS, + DISTS + } codetype; + + extern int inflate_table OF((codetype type, unsigned short FAR *lens, + unsigned codes, code FAR * FAR *table, + unsigned FAR *bits, unsigned short FAR *work)); Index: llvm-test/Runtime/zlib/minigzip.c diff -c /dev/null llvm-test/Runtime/zlib/minigzip.c:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/minigzip.c Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,322 ---- + /* minigzip.c -- simulate gzip using the zlib compression library + * Copyright (C) 1995-2002 Jean-loup Gailly. + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* + * minigzip is a minimal implementation of the gzip utility. This is + * only an example of using zlib and isn't meant to replace the + * full-featured gzip. No attempt is made to deal with file systems + * limiting names to 14 or 8+3 characters, etc... Error checking is + * very limited. So use minigzip only for testing; use gzip for the + * real thing. On MSDOS, use only on file names without extension + * or in pipe mode. + */ + + /* @(#) $Id: minigzip.c,v 1.1 2004/12/06 21:19:39 criswell Exp $ */ + + #include + #include "zlib.h" + + #ifdef STDC + # include + # include + #else + extern void exit OF((int)); + #endif + + #ifdef USE_MMAP + # include + # include + # include + #endif + + #if defined(MSDOS) || defined(OS2) || defined(WIN32) || defined(__CYGWIN__) + # include + # include + # define SET_BINARY_MODE(file) setmode(fileno(file), O_BINARY) + #else + # define SET_BINARY_MODE(file) + #endif + + #ifdef VMS + # define unlink delete + # define GZ_SUFFIX "-gz" + #endif + #ifdef RISCOS + # define unlink remove + # define GZ_SUFFIX "-gz" + # define fileno(file) file->__file + #endif + #if defined(__MWERKS__) && __dest_os != __be_os && __dest_os != __win32_os + # include /* for fileno */ + #endif + + #ifndef WIN32 /* unlink already in stdio.h for WIN32 */ + extern int unlink OF((const char *)); + #endif + + #ifndef GZ_SUFFIX + # define GZ_SUFFIX ".gz" + #endif + #define SUFFIX_LEN (sizeof(GZ_SUFFIX)-1) + + #define BUFLEN 16384 + #define MAX_NAME_LEN 1024 + + #ifdef MAXSEG_64K + # define local static + /* Needed for systems with limitation on stack size. */ + #else + # define local + #endif + + char *prog; + + void error OF((const char *msg)); + void gz_compress OF((FILE *in, gzFile out)); + #ifdef USE_MMAP + int gz_compress_mmap OF((FILE *in, gzFile out)); + #endif + void gz_uncompress OF((gzFile in, FILE *out)); + void file_compress OF((char *file, char *mode)); + void file_uncompress OF((char *file)); + int main OF((int argc, char *argv[])); + + /* =========================================================================== + * Display error message and exit + */ + void error(msg) + const char *msg; + { + fprintf(stderr, "%s: %s\n", prog, msg); + exit(1); + } + + /* =========================================================================== + * Compress input to output then close both files. + */ + + void gz_compress(in, out) + FILE *in; + gzFile out; + { + local char buf[BUFLEN]; + int len; + int err; + + #ifdef USE_MMAP + /* Try first compressing with mmap. If mmap fails (minigzip used in a + * pipe), use the normal fread loop. + */ + if (gz_compress_mmap(in, out) == Z_OK) return; + #endif + for (;;) { + len = (int)fread(buf, 1, sizeof(buf), in); + if (ferror(in)) { + perror("fread"); + exit(1); + } + if (len == 0) break; + + if (gzwrite(out, buf, (unsigned)len) != len) error(gzerror(out, &err)); + } + fclose(in); + if (gzclose(out) != Z_OK) error("failed gzclose"); + } + + #ifdef USE_MMAP /* MMAP version, Miguel Albrecht */ + + /* Try compressing the input file at once using mmap. Return Z_OK if + * if success, Z_ERRNO otherwise. + */ + int gz_compress_mmap(in, out) + FILE *in; + gzFile out; + { + int len; + int err; + int ifd = fileno(in); + caddr_t buf; /* mmap'ed buffer for the entire input file */ + off_t buf_len; /* length of the input file */ + struct stat sb; + + /* Determine the size of the file, needed for mmap: */ + if (fstat(ifd, &sb) < 0) return Z_ERRNO; + buf_len = sb.st_size; + if (buf_len <= 0) return Z_ERRNO; + + /* Now do the actual mmap: */ + buf = mmap((caddr_t) 0, buf_len, PROT_READ, MAP_SHARED, ifd, (off_t)0); + if (buf == (caddr_t)(-1)) return Z_ERRNO; + + /* Compress the whole file at once: */ + len = gzwrite(out, (char *)buf, (unsigned)buf_len); + + if (len != (int)buf_len) error(gzerror(out, &err)); + + munmap(buf, buf_len); + fclose(in); + if (gzclose(out) != Z_OK) error("failed gzclose"); + return Z_OK; + } + #endif /* USE_MMAP */ + + /* =========================================================================== + * Uncompress input to output then close both files. + */ + void gz_uncompress(in, out) + gzFile in; + FILE *out; + { + local char buf[BUFLEN]; + int len; + int err; + + for (;;) { + len = gzread(in, buf, sizeof(buf)); + if (len < 0) error (gzerror(in, &err)); + if (len == 0) break; + + if ((int)fwrite(buf, 1, (unsigned)len, out) != len) { + error("failed fwrite"); + } + } + if (fclose(out)) error("failed fclose"); + + if (gzclose(in) != Z_OK) error("failed gzclose"); + } + + + /* =========================================================================== + * Compress the given file: create a corresponding .gz file and remove the + * original. + */ + void file_compress(file, mode) + char *file; + char *mode; + { + local char outfile[MAX_NAME_LEN]; + FILE *in; + gzFile out; + + strcpy(outfile, file); + strcat(outfile, GZ_SUFFIX); + + in = fopen(file, "rb"); + if (in == NULL) { + perror(file); + exit(1); + } + out = gzopen(outfile, mode); + if (out == NULL) { + fprintf(stderr, "%s: can't gzopen %s\n", prog, outfile); + exit(1); + } + gz_compress(in, out); + + unlink(file); + } + + + /* =========================================================================== + * Uncompress the given file and remove the original. + */ + void file_uncompress(file) + char *file; + { + local char buf[MAX_NAME_LEN]; + char *infile, *outfile; + FILE *out; + gzFile in; + uInt len = (uInt)strlen(file); + + strcpy(buf, file); + + if (len > SUFFIX_LEN && strcmp(file+len-SUFFIX_LEN, GZ_SUFFIX) == 0) { + infile = file; + outfile = buf; + outfile[len-3] = '\0'; + } else { + outfile = file; + infile = buf; + strcat(infile, GZ_SUFFIX); + } + in = gzopen(infile, "rb"); + if (in == NULL) { + fprintf(stderr, "%s: can't gzopen %s\n", prog, infile); + exit(1); + } + out = fopen(outfile, "wb"); + if (out == NULL) { + perror(file); + exit(1); + } + + gz_uncompress(in, out); + + unlink(infile); + } + + + /* =========================================================================== + * Usage: minigzip [-d] [-f] [-h] [-r] [-1 to -9] [files...] + * -d : decompress + * -f : compress with Z_FILTERED + * -h : compress with Z_HUFFMAN_ONLY + * -r : compress with Z_RLE + * -1 to -9 : compression level + */ + + int main(argc, argv) + int argc; + char *argv[]; + { + int uncompr = 0; + gzFile file; + char outmode[20]; + + strcpy(outmode, "wb6 "); + + prog = argv[0]; + argc--, argv++; + + while (argc > 0) { + if (strcmp(*argv, "-d") == 0) + uncompr = 1; + else if (strcmp(*argv, "-f") == 0) + outmode[3] = 'f'; + else if (strcmp(*argv, "-h") == 0) + outmode[3] = 'h'; + else if (strcmp(*argv, "-r") == 0) + outmode[3] = 'R'; + else if ((*argv)[0] == '-' && (*argv)[1] >= '1' && (*argv)[1] <= '9' && + (*argv)[2] == 0) + outmode[2] = (*argv)[1]; + else + break; + argc--, argv++; + } + if (argc == 0) { + SET_BINARY_MODE(stdin); + SET_BINARY_MODE(stdout); + if (uncompr) { + file = gzdopen(fileno(stdin), "rb"); + if (file == NULL) error("can't gzdopen stdin"); + gz_uncompress(file, stdout); + } else { + file = gzdopen(fileno(stdout), outmode); + if (file == NULL) error("can't gzdopen stdout"); + gz_compress(stdin, file); + } + } else { + do { + if (uncompr) { + file_uncompress(*argv); + } else { + file_compress(*argv, outmode); + } + } while (argv++, --argc); + } + return 0; + } Index: llvm-test/Runtime/zlib/trees.c diff -c /dev/null llvm-test/Runtime/zlib/trees.c:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/trees.c Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,1215 ---- + /* trees.c -- output deflated data using Huffman coding + * Copyright (C) 1995-2003 Jean-loup Gailly + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* + * ALGORITHM + * + * The "deflation" process uses several Huffman trees. The more + * common source values are represented by shorter bit sequences. + * + * Each code tree is stored in a compressed form which is itself + * a Huffman encoding of the lengths of all the code strings (in + * ascending order by source values). The actual code strings are + * reconstructed from the lengths in the inflate process, as described + * in the deflate specification. + * + * REFERENCES + * + * Deutsch, L.P.,"'Deflate' Compressed Data Format Specification". + * Available in ftp.uu.net:/pub/archiving/zip/doc/deflate-1.1.doc + * + * Storer, James A. + * Data Compression: Methods and Theory, pp. 49-50. + * Computer Science Press, 1988. ISBN 0-7167-8156-5. + * + * Sedgewick, R. + * Algorithms, p290. + * Addison-Wesley, 1983. ISBN 0-201-06672-6. + */ + + /* @(#) $Id: trees.c,v 1.1 2004/12/06 21:19:39 criswell Exp $ */ + + /* #define GEN_TREES_H */ + + #include "deflate.h" + + #ifdef DEBUG + # include + #endif + + /* =========================================================================== + * Constants + */ + + #define MAX_BL_BITS 7 + /* Bit length codes must not exceed MAX_BL_BITS bits */ + + #define END_BLOCK 256 + /* end of block literal code */ + + #define REP_3_6 16 + /* repeat previous bit length 3-6 times (2 bits of repeat count) */ + + #define REPZ_3_10 17 + /* repeat a zero length 3-10 times (3 bits of repeat count) */ + + #define REPZ_11_138 18 + /* repeat a zero length 11-138 times (7 bits of repeat count) */ + + local const int extra_lbits[LENGTH_CODES] /* extra bits for each length code */ + = {0,0,0,0,0,0,0,0,1,1,1,1,2,2,2,2,3,3,3,3,4,4,4,4,5,5,5,5,0}; + + local const int extra_dbits[D_CODES] /* extra bits for each distance code */ + = {0,0,0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7,8,8,9,9,10,10,11,11,12,12,13,13}; + + local const int extra_blbits[BL_CODES]/* extra bits for each bit length code */ + = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2,3,7}; + + local const uch bl_order[BL_CODES] + = {16,17,18,0,8,7,9,6,10,5,11,4,12,3,13,2,14,1,15}; + /* The lengths of the bit length codes are sent in order of decreasing + * probability, to avoid transmitting the lengths for unused bit length codes. + */ + + #define Buf_size (8 * 2*sizeof(char)) + /* Number of bits used within bi_buf. (bi_buf might be implemented on + * more than 16 bits on some systems.) + */ + + /* =========================================================================== + * Local data. These are initialized only once. + */ + + #define DIST_CODE_LEN 512 /* see definition of array dist_code below */ + + #if defined(GEN_TREES_H) || !defined(STDC) + /* non ANSI compilers may not accept trees.h */ + + local ct_data static_ltree[L_CODES+2]; + /* The static literal tree. Since the bit lengths are imposed, there is no + * need for the L_CODES extra codes used during heap construction. However + * The codes 286 and 287 are needed to build a canonical tree (see _tr_init + * below). + */ + + local ct_data static_dtree[D_CODES]; + /* The static distance tree. (Actually a trivial tree since all codes use + * 5 bits.) + */ + + uch _dist_code[DIST_CODE_LEN]; + /* Distance codes. The first 256 values correspond to the distances + * 3 .. 258, the last 256 values correspond to the top 8 bits of + * the 15 bit distances. + */ + + uch _length_code[MAX_MATCH-MIN_MATCH+1]; + /* length code for each normalized match length (0 == MIN_MATCH) */ + + local int base_length[LENGTH_CODES]; + /* First normalized length for each code (0 = MIN_MATCH) */ + + local int base_dist[D_CODES]; + /* First normalized distance for each code (0 = distance of 1) */ + + #else + # include "trees.h" + #endif /* GEN_TREES_H */ + + struct static_tree_desc_s { + const ct_data *static_tree; /* static tree or NULL */ + const intf *extra_bits; /* extra bits for each code or NULL */ + int extra_base; /* base index for extra_bits */ + int elems; /* max number of elements in the tree */ + int max_length; /* max bit length for the codes */ + }; + + local static_tree_desc static_l_desc = + {static_ltree, extra_lbits, LITERALS+1, L_CODES, MAX_BITS}; + + local static_tree_desc static_d_desc = + {static_dtree, extra_dbits, 0, D_CODES, MAX_BITS}; + + local static_tree_desc static_bl_desc = + {(const ct_data *)0, extra_blbits, 0, BL_CODES, MAX_BL_BITS}; + + /* =========================================================================== + * Local (static) routines in this file. + */ + + local void tr_static_init OF((void)); + local void init_block OF((deflate_state *s)); + local void pqdownheap OF((deflate_state *s, ct_data *tree, int k)); + local void gen_bitlen OF((deflate_state *s, tree_desc *desc)); + local void gen_codes OF((ct_data *tree, int max_code, ushf *bl_count)); + local void build_tree OF((deflate_state *s, tree_desc *desc)); + local void scan_tree OF((deflate_state *s, ct_data *tree, int max_code)); + local void send_tree OF((deflate_state *s, ct_data *tree, int max_code)); + local int build_bl_tree OF((deflate_state *s)); + local void send_all_trees OF((deflate_state *s, int lcodes, int dcodes, + int blcodes)); + local void compress_block OF((deflate_state *s, ct_data *ltree, + ct_data *dtree)); + local void set_data_type OF((deflate_state *s)); + local unsigned bi_reverse OF((unsigned value, int length)); + local void bi_windup OF((deflate_state *s)); + local void bi_flush OF((deflate_state *s)); + local void copy_block OF((deflate_state *s, charf *buf, unsigned len, + int header)); + + #ifdef GEN_TREES_H + local void gen_trees_header OF((void)); + #endif + + #ifndef DEBUG + # define send_code(s, c, tree) send_bits(s, tree[c].Code, tree[c].Len) + /* Send a code of the given tree. c and tree must not have side effects */ + + #else /* DEBUG */ + # define send_code(s, c, tree) \ + { if (z_verbose>2) fprintf(stderr,"\ncd %3d ",(c)); \ + send_bits(s, tree[c].Code, tree[c].Len); } + #endif + + /* =========================================================================== + * Output a short LSB first on the stream. + * IN assertion: there is enough room in pendingBuf. + */ + #define put_short(s, w) { \ + put_byte(s, (uch)((w) & 0xff)); \ + put_byte(s, (uch)((ush)(w) >> 8)); \ + } + + /* =========================================================================== + * Send a value on a given number of bits. + * IN assertion: length <= 16 and value fits in length bits. + */ + #ifdef DEBUG + local void send_bits OF((deflate_state *s, int value, int length)); + + local void send_bits(s, value, length) + deflate_state *s; + int value; /* value to send */ + int length; /* number of bits */ + { + Tracevv((stderr," l %2d v %4x ", length, value)); + Assert(length > 0 && length <= 15, "invalid length"); + s->bits_sent += (ulg)length; + + /* If not enough room in bi_buf, use (valid) bits from bi_buf and + * (16 - bi_valid) bits from value, leaving (width - (16-bi_valid)) + * unused bits in value. + */ + if (s->bi_valid > (int)Buf_size - length) { + s->bi_buf |= (value << s->bi_valid); + put_short(s, s->bi_buf); + s->bi_buf = (ush)value >> (Buf_size - s->bi_valid); + s->bi_valid += length - Buf_size; + } else { + s->bi_buf |= value << s->bi_valid; + s->bi_valid += length; + } + } + #else /* !DEBUG */ + + #define send_bits(s, value, length) \ + { int len = length;\ + if (s->bi_valid > (int)Buf_size - len) {\ + int val = value;\ + s->bi_buf |= (val << s->bi_valid);\ + put_short(s, s->bi_buf);\ + s->bi_buf = (ush)val >> (Buf_size - s->bi_valid);\ + s->bi_valid += len - Buf_size;\ + } else {\ + s->bi_buf |= (value) << s->bi_valid;\ + s->bi_valid += len;\ + }\ + } + #endif /* DEBUG */ + + + /* the arguments must not have side effects */ + + /* =========================================================================== + * Initialize the various 'constant' tables. + */ + local void tr_static_init() + { + #if defined(GEN_TREES_H) || !defined(STDC) + static int static_init_done = 0; + int n; /* iterates over tree elements */ + int bits; /* bit counter */ + int length; /* length value */ + int code; /* code value */ + int dist; /* distance index */ + ush bl_count[MAX_BITS+1]; + /* number of codes at each bit length for an optimal tree */ + + if (static_init_done) return; + + /* For some embedded targets, global variables are not initialized: */ + static_l_desc.static_tree = static_ltree; + static_l_desc.extra_bits = extra_lbits; + static_d_desc.static_tree = static_dtree; + static_d_desc.extra_bits = extra_dbits; + static_bl_desc.extra_bits = extra_blbits; + + /* Initialize the mapping length (0..255) -> length code (0..28) */ + length = 0; + for (code = 0; code < LENGTH_CODES-1; code++) { + base_length[code] = length; + for (n = 0; n < (1< dist code (0..29) */ + dist = 0; + for (code = 0 ; code < 16; code++) { + base_dist[code] = dist; + for (n = 0; n < (1<>= 7; /* from now on, all distances are divided by 128 */ + for ( ; code < D_CODES; code++) { + base_dist[code] = dist << 7; + for (n = 0; n < (1<<(extra_dbits[code]-7)); n++) { + _dist_code[256 + dist++] = (uch)code; + } + } + Assert (dist == 256, "tr_static_init: 256+dist != 512"); + + /* Construct the codes of the static literal tree */ + for (bits = 0; bits <= MAX_BITS; bits++) bl_count[bits] = 0; + n = 0; + while (n <= 143) static_ltree[n++].Len = 8, bl_count[8]++; + while (n <= 255) static_ltree[n++].Len = 9, bl_count[9]++; + while (n <= 279) static_ltree[n++].Len = 7, bl_count[7]++; + while (n <= 287) static_ltree[n++].Len = 8, bl_count[8]++; + /* Codes 286 and 287 do not exist, but we must include them in the + * tree construction to get a canonical Huffman tree (longest code + * all ones) + */ + gen_codes((ct_data *)static_ltree, L_CODES+1, bl_count); + + /* The static distance tree is trivial: */ + for (n = 0; n < D_CODES; n++) { + static_dtree[n].Len = 5; + static_dtree[n].Code = bi_reverse((unsigned)n, 5); + } + static_init_done = 1; + + # ifdef GEN_TREES_H + gen_trees_header(); + # endif + #endif /* defined(GEN_TREES_H) || !defined(STDC) */ + } + + /* =========================================================================== + * Genererate the file trees.h describing the static trees. + */ + #ifdef GEN_TREES_H + # ifndef DEBUG + # include + # endif + + # define SEPARATOR(i, last, width) \ + ((i) == (last)? "\n};\n\n" : \ + ((i) % (width) == (width)-1 ? ",\n" : ", ")) + + void gen_trees_header() + { + FILE *header = fopen("trees.h", "w"); + int i; + + Assert (header != NULL, "Can't open trees.h"); + fprintf(header, + "/* header created automatically with -DGEN_TREES_H */\n\n"); + + fprintf(header, "local const ct_data static_ltree[L_CODES+2] = {\n"); + for (i = 0; i < L_CODES+2; i++) { + fprintf(header, "{{%3u},{%3u}}%s", static_ltree[i].Code, + static_ltree[i].Len, SEPARATOR(i, L_CODES+1, 5)); + } + + fprintf(header, "local const ct_data static_dtree[D_CODES] = {\n"); + for (i = 0; i < D_CODES; i++) { + fprintf(header, "{{%2u},{%2u}}%s", static_dtree[i].Code, + static_dtree[i].Len, SEPARATOR(i, D_CODES-1, 5)); + } + + fprintf(header, "const uch _dist_code[DIST_CODE_LEN] = {\n"); + for (i = 0; i < DIST_CODE_LEN; i++) { + fprintf(header, "%2u%s", _dist_code[i], + SEPARATOR(i, DIST_CODE_LEN-1, 20)); + } + + fprintf(header, "const uch _length_code[MAX_MATCH-MIN_MATCH+1]= {\n"); + for (i = 0; i < MAX_MATCH-MIN_MATCH+1; i++) { + fprintf(header, "%2u%s", _length_code[i], + SEPARATOR(i, MAX_MATCH-MIN_MATCH, 20)); + } + + fprintf(header, "local const int base_length[LENGTH_CODES] = {\n"); + for (i = 0; i < LENGTH_CODES; i++) { + fprintf(header, "%1u%s", base_length[i], + SEPARATOR(i, LENGTH_CODES-1, 20)); + } + + fprintf(header, "local const int base_dist[D_CODES] = {\n"); + for (i = 0; i < D_CODES; i++) { + fprintf(header, "%5u%s", base_dist[i], + SEPARATOR(i, D_CODES-1, 10)); + } + + fclose(header); + } + #endif /* GEN_TREES_H */ + + /* =========================================================================== + * Initialize the tree data structures for a new zlib stream. + */ + void _tr_init(s) + deflate_state *s; + { + tr_static_init(); + + s->l_desc.dyn_tree = s->dyn_ltree; + s->l_desc.stat_desc = &static_l_desc; + + s->d_desc.dyn_tree = s->dyn_dtree; + s->d_desc.stat_desc = &static_d_desc; + + s->bl_desc.dyn_tree = s->bl_tree; + s->bl_desc.stat_desc = &static_bl_desc; + + s->bi_buf = 0; + s->bi_valid = 0; + s->last_eob_len = 8; /* enough lookahead for inflate */ + #ifdef DEBUG + s->compressed_len = 0L; + s->bits_sent = 0L; + #endif + + /* Initialize the first block of the first file: */ + init_block(s); + } + + /* =========================================================================== + * Initialize a new block. + */ + local void init_block(s) + deflate_state *s; + { + int n; /* iterates over tree elements */ + + /* Initialize the trees. */ + for (n = 0; n < L_CODES; n++) s->dyn_ltree[n].Freq = 0; + for (n = 0; n < D_CODES; n++) s->dyn_dtree[n].Freq = 0; + for (n = 0; n < BL_CODES; n++) s->bl_tree[n].Freq = 0; + + s->dyn_ltree[END_BLOCK].Freq = 1; + s->opt_len = s->static_len = 0L; + s->last_lit = s->matches = 0; + } + + #define SMALLEST 1 + /* Index within the heap array of least frequent node in the Huffman tree */ + + + /* =========================================================================== + * Remove the smallest element from the heap and recreate the heap with + * one less element. Updates heap and heap_len. + */ + #define pqremove(s, tree, top) \ + {\ + top = s->heap[SMALLEST]; \ + s->heap[SMALLEST] = s->heap[s->heap_len--]; \ + pqdownheap(s, tree, SMALLEST); \ + } + + /* =========================================================================== + * Compares to subtrees, using the tree depth as tie breaker when + * the subtrees have equal frequency. This minimizes the worst case length. + */ + #define smaller(tree, n, m, depth) \ + (tree[n].Freq < tree[m].Freq || \ + (tree[n].Freq == tree[m].Freq && depth[n] <= depth[m])) + + /* =========================================================================== + * Restore the heap property by moving down the tree starting at node k, + * exchanging a node with the smallest of its two sons if necessary, stopping + * when the heap property is re-established (each father smaller than its + * two sons). + */ + local void pqdownheap(s, tree, k) + deflate_state *s; + ct_data *tree; /* the tree to restore */ + int k; /* node to move down */ + { + int v = s->heap[k]; + int j = k << 1; /* left son of k */ + while (j <= s->heap_len) { + /* Set j to the smallest of the two sons: */ + if (j < s->heap_len && + smaller(tree, s->heap[j+1], s->heap[j], s->depth)) { + j++; + } + /* Exit if v is smaller than both sons */ + if (smaller(tree, v, s->heap[j], s->depth)) break; + + /* Exchange v with the smallest son */ + s->heap[k] = s->heap[j]; k = j; + + /* And continue down the tree, setting j to the left son of k */ + j <<= 1; + } + s->heap[k] = v; + } + + /* =========================================================================== + * Compute the optimal bit lengths for a tree and update the total bit length + * for the current block. + * IN assertion: the fields freq and dad are set, heap[heap_max] and + * above are the tree nodes sorted by increasing frequency. + * OUT assertions: the field len is set to the optimal bit length, the + * array bl_count contains the frequencies for each bit length. + * The length opt_len is updated; static_len is also updated if stree is + * not null. + */ + local void gen_bitlen(s, desc) + deflate_state *s; + tree_desc *desc; /* the tree descriptor */ + { + ct_data *tree = desc->dyn_tree; + int max_code = desc->max_code; + const ct_data *stree = desc->stat_desc->static_tree; + const intf *extra = desc->stat_desc->extra_bits; + int base = desc->stat_desc->extra_base; + int max_length = desc->stat_desc->max_length; + int h; /* heap index */ + int n, m; /* iterate over the tree elements */ + int bits; /* bit length */ + int xbits; /* extra bits */ + ush f; /* frequency */ + int overflow = 0; /* number of elements with bit length too large */ + + for (bits = 0; bits <= MAX_BITS; bits++) s->bl_count[bits] = 0; + + /* In a first pass, compute the optimal bit lengths (which may + * overflow in the case of the bit length tree). + */ + tree[s->heap[s->heap_max]].Len = 0; /* root of the heap */ + + for (h = s->heap_max+1; h < HEAP_SIZE; h++) { + n = s->heap[h]; + bits = tree[tree[n].Dad].Len + 1; + if (bits > max_length) bits = max_length, overflow++; + tree[n].Len = (ush)bits; + /* We overwrite tree[n].Dad which is no longer needed */ + + if (n > max_code) continue; /* not a leaf node */ + + s->bl_count[bits]++; + xbits = 0; + if (n >= base) xbits = extra[n-base]; + f = tree[n].Freq; + s->opt_len += (ulg)f * (bits + xbits); + if (stree) s->static_len += (ulg)f * (stree[n].Len + xbits); + } + if (overflow == 0) return; + + Trace((stderr,"\nbit length overflow\n")); + /* This happens for example on obj2 and pic of the Calgary corpus */ + + /* Find the first bit length which could increase: */ + do { + bits = max_length-1; + while (s->bl_count[bits] == 0) bits--; + s->bl_count[bits]--; /* move one leaf down the tree */ + s->bl_count[bits+1] += 2; /* move one overflow item as its brother */ + s->bl_count[max_length]--; + /* The brother of the overflow item also moves one step up, + * but this does not affect bl_count[max_length] + */ + overflow -= 2; + } while (overflow > 0); + + /* Now recompute all bit lengths, scanning in increasing frequency. + * h is still equal to HEAP_SIZE. (It is simpler to reconstruct all + * lengths instead of fixing only the wrong ones. This idea is taken + * from 'ar' written by Haruhiko Okumura.) + */ + for (bits = max_length; bits != 0; bits--) { + n = s->bl_count[bits]; + while (n != 0) { + m = s->heap[--h]; + if (m > max_code) continue; + if (tree[m].Len != (unsigned) bits) { + Trace((stderr,"code %d bits %d->%d\n", m, tree[m].Len, bits)); + s->opt_len += ((long)bits - (long)tree[m].Len) + *(long)tree[m].Freq; + tree[m].Len = (ush)bits; + } + n--; + } + } + } + + /* =========================================================================== + * Generate the codes for a given tree and bit counts (which need not be + * optimal). + * IN assertion: the array bl_count contains the bit length statistics for + * the given tree and the field len is set for all tree elements. + * OUT assertion: the field code is set for all tree elements of non + * zero code length. + */ + local void gen_codes (tree, max_code, bl_count) + ct_data *tree; /* the tree to decorate */ + int max_code; /* largest code with non zero frequency */ + ushf *bl_count; /* number of codes at each bit length */ + { + ush next_code[MAX_BITS+1]; /* next code value for each bit length */ + ush code = 0; /* running code value */ + int bits; /* bit index */ + int n; /* code index */ + + /* The distribution counts are first used to generate the code values + * without bit reversal. + */ + for (bits = 1; bits <= MAX_BITS; bits++) { + next_code[bits] = code = (code + bl_count[bits-1]) << 1; + } + /* Check that the bit counts in bl_count are consistent. The last code + * must be all ones. + */ + Assert (code + bl_count[MAX_BITS]-1 == (1<dyn_tree; + const ct_data *stree = desc->stat_desc->static_tree; + int elems = desc->stat_desc->elems; + int n, m; /* iterate over heap elements */ + int max_code = -1; /* largest code with non zero frequency */ + int node; /* new node being created */ + + /* Construct the initial heap, with least frequent element in + * heap[SMALLEST]. The sons of heap[n] are heap[2*n] and heap[2*n+1]. + * heap[0] is not used. + */ + s->heap_len = 0, s->heap_max = HEAP_SIZE; + + for (n = 0; n < elems; n++) { + if (tree[n].Freq != 0) { + s->heap[++(s->heap_len)] = max_code = n; + s->depth[n] = 0; + } else { + tree[n].Len = 0; + } + } + + /* The pkzip format requires that at least one distance code exists, + * and that at least one bit should be sent even if there is only one + * possible code. So to avoid special checks later on we force at least + * two codes of non zero frequency. + */ + while (s->heap_len < 2) { + node = s->heap[++(s->heap_len)] = (max_code < 2 ? ++max_code : 0); + tree[node].Freq = 1; + s->depth[node] = 0; + s->opt_len--; if (stree) s->static_len -= stree[node].Len; + /* node is 0 or 1 so it does not have extra bits */ + } + desc->max_code = max_code; + + /* The elements heap[heap_len/2+1 .. heap_len] are leaves of the tree, + * establish sub-heaps of increasing lengths: + */ + for (n = s->heap_len/2; n >= 1; n--) pqdownheap(s, tree, n); + + /* Construct the Huffman tree by repeatedly combining the least two + * frequent nodes. + */ + node = elems; /* next internal node of the tree */ + do { + pqremove(s, tree, n); /* n = node of least frequency */ + m = s->heap[SMALLEST]; /* m = node of next least frequency */ + + s->heap[--(s->heap_max)] = n; /* keep the nodes sorted by frequency */ + s->heap[--(s->heap_max)] = m; + + /* Create a new node father of n and m */ + tree[node].Freq = tree[n].Freq + tree[m].Freq; + s->depth[node] = (uch)((s->depth[n] >= s->depth[m] ? + s->depth[n] : s->depth[m]) + 1); + tree[n].Dad = tree[m].Dad = (ush)node; + #ifdef DUMP_BL_TREE + if (tree == s->bl_tree) { + fprintf(stderr,"\nnode %d(%d), sons %d(%d) %d(%d)", + node, tree[node].Freq, n, tree[n].Freq, m, tree[m].Freq); + } + #endif + /* and insert the new node in the heap */ + s->heap[SMALLEST] = node++; + pqdownheap(s, tree, SMALLEST); + + } while (s->heap_len >= 2); + + s->heap[--(s->heap_max)] = s->heap[SMALLEST]; + + /* At this point, the fields freq and dad are set. We can now + * generate the bit lengths. + */ + gen_bitlen(s, (tree_desc *)desc); + + /* The field len is now set, we can generate the bit codes */ + gen_codes ((ct_data *)tree, max_code, s->bl_count); + } + + /* =========================================================================== + * Scan a literal or distance tree to determine the frequencies of the codes + * in the bit length tree. + */ + local void scan_tree (s, tree, max_code) + deflate_state *s; + ct_data *tree; /* the tree to be scanned */ + int max_code; /* and its largest code of non zero frequency */ + { + int n; /* iterates over all tree elements */ + int prevlen = -1; /* last emitted length */ + int curlen; /* length of current code */ + int nextlen = tree[0].Len; /* length of next code */ + int count = 0; /* repeat count of the current code */ + int max_count = 7; /* max repeat count */ + int min_count = 4; /* min repeat count */ + + if (nextlen == 0) max_count = 138, min_count = 3; + tree[max_code+1].Len = (ush)0xffff; /* guard */ + + for (n = 0; n <= max_code; n++) { + curlen = nextlen; nextlen = tree[n+1].Len; + if (++count < max_count && curlen == nextlen) { + continue; + } else if (count < min_count) { + s->bl_tree[curlen].Freq += count; + } else if (curlen != 0) { + if (curlen != prevlen) s->bl_tree[curlen].Freq++; + s->bl_tree[REP_3_6].Freq++; + } else if (count <= 10) { + s->bl_tree[REPZ_3_10].Freq++; + } else { + s->bl_tree[REPZ_11_138].Freq++; + } + count = 0; prevlen = curlen; + if (nextlen == 0) { + max_count = 138, min_count = 3; + } else if (curlen == nextlen) { + max_count = 6, min_count = 3; + } else { + max_count = 7, min_count = 4; + } + } + } + + /* =========================================================================== + * Send a literal or distance tree in compressed form, using the codes in + * bl_tree. + */ + local void send_tree (s, tree, max_code) + deflate_state *s; + ct_data *tree; /* the tree to be scanned */ + int max_code; /* and its largest code of non zero frequency */ + { + int n; /* iterates over all tree elements */ + int prevlen = -1; /* last emitted length */ + int curlen; /* length of current code */ + int nextlen = tree[0].Len; /* length of next code */ + int count = 0; /* repeat count of the current code */ + int max_count = 7; /* max repeat count */ + int min_count = 4; /* min repeat count */ + + /* tree[max_code+1].Len = -1; */ /* guard already set */ + if (nextlen == 0) max_count = 138, min_count = 3; + + for (n = 0; n <= max_code; n++) { + curlen = nextlen; nextlen = tree[n+1].Len; + if (++count < max_count && curlen == nextlen) { + continue; + } else if (count < min_count) { + do { send_code(s, curlen, s->bl_tree); } while (--count != 0); + + } else if (curlen != 0) { + if (curlen != prevlen) { + send_code(s, curlen, s->bl_tree); count--; + } + Assert(count >= 3 && count <= 6, " 3_6?"); + send_code(s, REP_3_6, s->bl_tree); send_bits(s, count-3, 2); + + } else if (count <= 10) { + send_code(s, REPZ_3_10, s->bl_tree); send_bits(s, count-3, 3); + + } else { + send_code(s, REPZ_11_138, s->bl_tree); send_bits(s, count-11, 7); + } + count = 0; prevlen = curlen; + if (nextlen == 0) { + max_count = 138, min_count = 3; + } else if (curlen == nextlen) { + max_count = 6, min_count = 3; + } else { + max_count = 7, min_count = 4; + } + } + } + + /* =========================================================================== + * Construct the Huffman tree for the bit lengths and return the index in + * bl_order of the last bit length code to send. + */ + local int build_bl_tree(s) + deflate_state *s; + { + int max_blindex; /* index of last bit length code of non zero freq */ + + /* Determine the bit length frequencies for literal and distance trees */ + scan_tree(s, (ct_data *)s->dyn_ltree, s->l_desc.max_code); + scan_tree(s, (ct_data *)s->dyn_dtree, s->d_desc.max_code); + + /* Build the bit length tree: */ + build_tree(s, (tree_desc *)(&(s->bl_desc))); + /* opt_len now includes the length of the tree representations, except + * the lengths of the bit lengths codes and the 5+5+4 bits for the counts. + */ + + /* Determine the number of bit length codes to send. The pkzip format + * requires that at least 4 bit length codes be sent. (appnote.txt says + * 3 but the actual value used is 4.) + */ + for (max_blindex = BL_CODES-1; max_blindex >= 3; max_blindex--) { + if (s->bl_tree[bl_order[max_blindex]].Len != 0) break; + } + /* Update opt_len to include the bit length tree and counts */ + s->opt_len += 3*(max_blindex+1) + 5+5+4; + Tracev((stderr, "\ndyn trees: dyn %ld, stat %ld", + s->opt_len, s->static_len)); + + return max_blindex; + } + + /* =========================================================================== + * Send the header for a block using dynamic Huffman trees: the counts, the + * lengths of the bit length codes, the literal tree and the distance tree. + * IN assertion: lcodes >= 257, dcodes >= 1, blcodes >= 4. + */ + local void send_all_trees(s, lcodes, dcodes, blcodes) + deflate_state *s; + int lcodes, dcodes, blcodes; /* number of codes for each tree */ + { + int rank; /* index in bl_order */ + + Assert (lcodes >= 257 && dcodes >= 1 && blcodes >= 4, "not enough codes"); + Assert (lcodes <= L_CODES && dcodes <= D_CODES && blcodes <= BL_CODES, + "too many codes"); + Tracev((stderr, "\nbl counts: ")); + send_bits(s, lcodes-257, 5); /* not +255 as stated in appnote.txt */ + send_bits(s, dcodes-1, 5); + send_bits(s, blcodes-4, 4); /* not -3 as stated in appnote.txt */ + for (rank = 0; rank < blcodes; rank++) { + Tracev((stderr, "\nbl code %2d ", bl_order[rank])); + send_bits(s, s->bl_tree[bl_order[rank]].Len, 3); + } + Tracev((stderr, "\nbl tree: sent %ld", s->bits_sent)); + + send_tree(s, (ct_data *)s->dyn_ltree, lcodes-1); /* literal tree */ + Tracev((stderr, "\nlit tree: sent %ld", s->bits_sent)); + + send_tree(s, (ct_data *)s->dyn_dtree, dcodes-1); /* distance tree */ + Tracev((stderr, "\ndist tree: sent %ld", s->bits_sent)); + } + + /* =========================================================================== + * Send a stored block + */ + void _tr_stored_block(s, buf, stored_len, eof) + deflate_state *s; + charf *buf; /* input block */ + ulg stored_len; /* length of input block */ + int eof; /* true if this is the last block for a file */ + { + send_bits(s, (STORED_BLOCK<<1)+eof, 3); /* send block type */ + #ifdef DEBUG + s->compressed_len = (s->compressed_len + 3 + 7) & (ulg)~7L; + s->compressed_len += (stored_len + 4) << 3; + #endif + copy_block(s, buf, (unsigned)stored_len, 1); /* with header */ + } + + /* =========================================================================== + * Send one empty static block to give enough lookahead for inflate. + * This takes 10 bits, of which 7 may remain in the bit buffer. + * The current inflate code requires 9 bits of lookahead. If the + * last two codes for the previous block (real code plus EOB) were coded + * on 5 bits or less, inflate may have only 5+3 bits of lookahead to decode + * the last real code. In this case we send two empty static blocks instead + * of one. (There are no problems if the previous block is stored or fixed.) + * To simplify the code, we assume the worst case of last real code encoded + * on one bit only. + */ + void _tr_align(s) + deflate_state *s; + { + send_bits(s, STATIC_TREES<<1, 3); + send_code(s, END_BLOCK, static_ltree); + #ifdef DEBUG + s->compressed_len += 10L; /* 3 for block type, 7 for EOB */ + #endif + bi_flush(s); + /* Of the 10 bits for the empty block, we have already sent + * (10 - bi_valid) bits. The lookahead for the last real code (before + * the EOB of the previous block) was thus at least one plus the length + * of the EOB plus what we have just sent of the empty static block. + */ + if (1 + s->last_eob_len + 10 - s->bi_valid < 9) { + send_bits(s, STATIC_TREES<<1, 3); + send_code(s, END_BLOCK, static_ltree); + #ifdef DEBUG + s->compressed_len += 10L; + #endif + bi_flush(s); + } + s->last_eob_len = 7; + } + + /* =========================================================================== + * Determine the best encoding for the current block: dynamic trees, static + * trees or store, and output the encoded block to the zip file. + */ + void _tr_flush_block(s, buf, stored_len, eof) + deflate_state *s; + charf *buf; /* input block, or NULL if too old */ + ulg stored_len; /* length of input block */ + int eof; /* true if this is the last block for a file */ + { + ulg opt_lenb, static_lenb; /* opt_len and static_len in bytes */ + int max_blindex = 0; /* index of last bit length code of non zero freq */ + + /* Build the Huffman trees unless a stored block is forced */ + if (s->level > 0) { + + /* Check if the file is ascii or binary */ + if (s->data_type == Z_UNKNOWN) set_data_type(s); + + /* Construct the literal and distance trees */ + build_tree(s, (tree_desc *)(&(s->l_desc))); + Tracev((stderr, "\nlit data: dyn %ld, stat %ld", s->opt_len, + s->static_len)); + + build_tree(s, (tree_desc *)(&(s->d_desc))); + Tracev((stderr, "\ndist data: dyn %ld, stat %ld", s->opt_len, + s->static_len)); + /* At this point, opt_len and static_len are the total bit lengths of + * the compressed block data, excluding the tree representations. + */ + + /* Build the bit length tree for the above two trees, and get the index + * in bl_order of the last bit length code to send. + */ + max_blindex = build_bl_tree(s); + + /* Determine the best encoding. Compute the block lengths in bytes. */ + opt_lenb = (s->opt_len+3+7)>>3; + static_lenb = (s->static_len+3+7)>>3; + + Tracev((stderr, "\nopt %lu(%lu) stat %lu(%lu) stored %lu lit %u ", + opt_lenb, s->opt_len, static_lenb, s->static_len, stored_len, + s->last_lit)); + + if (static_lenb <= opt_lenb) opt_lenb = static_lenb; + + } else { + Assert(buf != (char*)0, "lost buf"); + opt_lenb = static_lenb = stored_len + 5; /* force a stored block */ + } + + #ifdef FORCE_STORED + if (buf != (char*)0) { /* force stored block */ + #else + if (stored_len+4 <= opt_lenb && buf != (char*)0) { + /* 4: two words for the lengths */ + #endif + /* The test buf != NULL is only necessary if LIT_BUFSIZE > WSIZE. + * Otherwise we can't have processed more than WSIZE input bytes since + * the last block flush, because compression would have been + * successful. If LIT_BUFSIZE <= WSIZE, it is never too late to + * transform a block into a stored block. + */ + _tr_stored_block(s, buf, stored_len, eof); + + #ifdef FORCE_STATIC + } else if (static_lenb >= 0) { /* force static trees */ + #else + } else if (static_lenb == opt_lenb) { + #endif + send_bits(s, (STATIC_TREES<<1)+eof, 3); + compress_block(s, (ct_data *)static_ltree, (ct_data *)static_dtree); + #ifdef DEBUG + s->compressed_len += 3 + s->static_len; + #endif + } else { + send_bits(s, (DYN_TREES<<1)+eof, 3); + send_all_trees(s, s->l_desc.max_code+1, s->d_desc.max_code+1, + max_blindex+1); + compress_block(s, (ct_data *)s->dyn_ltree, (ct_data *)s->dyn_dtree); + #ifdef DEBUG + s->compressed_len += 3 + s->opt_len; + #endif + } + Assert (s->compressed_len == s->bits_sent, "bad compressed size"); + /* The above check is made mod 2^32, for files larger than 512 MB + * and uLong implemented on 32 bits. + */ + init_block(s); + + if (eof) { + bi_windup(s); + #ifdef DEBUG + s->compressed_len += 7; /* align on byte boundary */ + #endif + } + Tracev((stderr,"\ncomprlen %lu(%lu) ", s->compressed_len>>3, + s->compressed_len-7*eof)); + } + + /* =========================================================================== + * Save the match info and tally the frequency counts. Return true if + * the current block must be flushed. + */ + int _tr_tally (s, dist, lc) + deflate_state *s; + unsigned dist; /* distance of matched string */ + unsigned lc; /* match length-MIN_MATCH or unmatched char (if dist==0) */ + { + s->d_buf[s->last_lit] = (ush)dist; + s->l_buf[s->last_lit++] = (uch)lc; + if (dist == 0) { + /* lc is the unmatched char */ + s->dyn_ltree[lc].Freq++; + } else { + s->matches++; + /* Here, lc is the match length - MIN_MATCH */ + dist--; /* dist = match distance - 1 */ + Assert((ush)dist < (ush)MAX_DIST(s) && + (ush)lc <= (ush)(MAX_MATCH-MIN_MATCH) && + (ush)d_code(dist) < (ush)D_CODES, "_tr_tally: bad match"); + + s->dyn_ltree[_length_code[lc]+LITERALS+1].Freq++; + s->dyn_dtree[d_code(dist)].Freq++; + } + + #ifdef TRUNCATE_BLOCK + /* Try to guess if it is profitable to stop the current block here */ + if ((s->last_lit & 0x1fff) == 0 && s->level > 2) { + /* Compute an upper bound for the compressed length */ + ulg out_length = (ulg)s->last_lit*8L; + ulg in_length = (ulg)((long)s->strstart - s->block_start); + int dcode; + for (dcode = 0; dcode < D_CODES; dcode++) { + out_length += (ulg)s->dyn_dtree[dcode].Freq * + (5L+extra_dbits[dcode]); + } + out_length >>= 3; + Tracev((stderr,"\nlast_lit %u, in %ld, out ~%ld(%ld%%) ", + s->last_lit, in_length, out_length, + 100L - out_length*100L/in_length)); + if (s->matches < s->last_lit/2 && out_length < in_length/2) return 1; + } + #endif + return (s->last_lit == s->lit_bufsize-1); + /* We avoid equality with lit_bufsize because of wraparound at 64K + * on 16 bit machines and because stored blocks are restricted to + * 64K-1 bytes. + */ + } + + /* =========================================================================== + * Send the block data compressed using the given Huffman trees + */ + local void compress_block(s, ltree, dtree) + deflate_state *s; + ct_data *ltree; /* literal tree */ + ct_data *dtree; /* distance tree */ + { + unsigned dist; /* distance of matched string */ + int lc; /* match length or unmatched char (if dist == 0) */ + unsigned lx = 0; /* running index in l_buf */ + unsigned code; /* the code to send */ + int extra; /* number of extra bits to send */ + + if (s->last_lit != 0) do { + dist = s->d_buf[lx]; + lc = s->l_buf[lx++]; + if (dist == 0) { + send_code(s, lc, ltree); /* send a literal byte */ + Tracecv(isgraph(lc), (stderr," '%c' ", lc)); + } else { + /* Here, lc is the match length - MIN_MATCH */ + code = _length_code[lc]; + send_code(s, code+LITERALS+1, ltree); /* send the length code */ + extra = extra_lbits[code]; + if (extra != 0) { + lc -= base_length[code]; + send_bits(s, lc, extra); /* send the extra length bits */ + } + dist--; /* dist is now the match distance - 1 */ + code = d_code(dist); + Assert (code < D_CODES, "bad d_code"); + + send_code(s, code, dtree); /* send the distance code */ + extra = extra_dbits[code]; + if (extra != 0) { + dist -= base_dist[code]; + send_bits(s, dist, extra); /* send the extra distance bits */ + } + } /* literal or match pair ? */ + + /* Check that the overlay between pending_buf and d_buf+l_buf is ok: */ + Assert((uInt)(s->pending) < s->lit_bufsize + 2*lx, + "pendingBuf overflow"); + + } while (lx < s->last_lit); + + send_code(s, END_BLOCK, ltree); + s->last_eob_len = ltree[END_BLOCK].Len; + } + + /* =========================================================================== + * Set the data type to ASCII or BINARY, using a crude approximation: + * binary if more than 20% of the bytes are <= 6 or >= 128, ascii otherwise. + * IN assertion: the fields freq of dyn_ltree are set and the total of all + * frequencies does not exceed 64K (to fit in an int on 16 bit machines). + */ + local void set_data_type(s) + deflate_state *s; + { + int n = 0; + unsigned ascii_freq = 0; + unsigned bin_freq = 0; + while (n < 7) bin_freq += s->dyn_ltree[n++].Freq; + while (n < 128) ascii_freq += s->dyn_ltree[n++].Freq; + while (n < LITERALS) bin_freq += s->dyn_ltree[n++].Freq; + s->data_type = (Byte)(bin_freq > (ascii_freq >> 2) ? Z_BINARY : Z_ASCII); + } + + /* =========================================================================== + * Reverse the first len bits of a code, using straightforward code (a faster + * method would use a table) + * IN assertion: 1 <= len <= 15 + */ + local unsigned bi_reverse(code, len) + unsigned code; /* the value to invert */ + int len; /* its bit length */ + { + register unsigned res = 0; + do { + res |= code & 1; + code >>= 1, res <<= 1; + } while (--len > 0); + return res >> 1; + } + + /* =========================================================================== + * Flush the bit buffer, keeping at most 7 bits in it. + */ + local void bi_flush(s) + deflate_state *s; + { + if (s->bi_valid == 16) { + put_short(s, s->bi_buf); + s->bi_buf = 0; + s->bi_valid = 0; + } else if (s->bi_valid >= 8) { + put_byte(s, (Byte)s->bi_buf); + s->bi_buf >>= 8; + s->bi_valid -= 8; + } + } + + /* =========================================================================== + * Flush the bit buffer and align the output on a byte boundary + */ + local void bi_windup(s) + deflate_state *s; + { + if (s->bi_valid > 8) { + put_short(s, s->bi_buf); + } else if (s->bi_valid > 0) { + put_byte(s, (Byte)s->bi_buf); + } + s->bi_buf = 0; + s->bi_valid = 0; + #ifdef DEBUG + s->bits_sent = (s->bits_sent+7) & ~7; + #endif + } + + /* =========================================================================== + * Copy a stored block, storing first the length and its + * one's complement if requested. + */ + local void copy_block(s, buf, len, header) + deflate_state *s; + charf *buf; /* the input data */ + unsigned len; /* its length */ + int header; /* true if block header must be written */ + { + bi_windup(s); /* align on byte boundary */ + s->last_eob_len = 8; /* enough lookahead for inflate */ + + if (header) { + put_short(s, (ush)len); + put_short(s, (ush)~len); + #ifdef DEBUG + s->bits_sent += 2*16; + #endif + } + #ifdef DEBUG + s->bits_sent += (ulg)len<<3; + #endif + while (len--) { + put_byte(s, *buf++); + } + } Index: llvm-test/Runtime/zlib/trees.h diff -c /dev/null llvm-test/Runtime/zlib/trees.h:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/trees.h Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,128 ---- + /* header created automatically with -DGEN_TREES_H */ + + local const ct_data static_ltree[L_CODES+2] = { + {{ 12},{ 8}}, {{140},{ 8}}, {{ 76},{ 8}}, {{204},{ 8}}, {{ 44},{ 8}}, + {{172},{ 8}}, {{108},{ 8}}, {{236},{ 8}}, {{ 28},{ 8}}, {{156},{ 8}}, + {{ 92},{ 8}}, {{220},{ 8}}, {{ 60},{ 8}}, {{188},{ 8}}, {{124},{ 8}}, + {{252},{ 8}}, {{ 2},{ 8}}, {{130},{ 8}}, {{ 66},{ 8}}, {{194},{ 8}}, + {{ 34},{ 8}}, {{162},{ 8}}, {{ 98},{ 8}}, {{226},{ 8}}, {{ 18},{ 8}}, + {{146},{ 8}}, {{ 82},{ 8}}, {{210},{ 8}}, {{ 50},{ 8}}, {{178},{ 8}}, + {{114},{ 8}}, {{242},{ 8}}, {{ 10},{ 8}}, {{138},{ 8}}, {{ 74},{ 8}}, + {{202},{ 8}}, {{ 42},{ 8}}, {{170},{ 8}}, {{106},{ 8}}, {{234},{ 8}}, + {{ 26},{ 8}}, {{154},{ 8}}, {{ 90},{ 8}}, {{218},{ 8}}, {{ 58},{ 8}}, + {{186},{ 8}}, {{122},{ 8}}, {{250},{ 8}}, {{ 6},{ 8}}, {{134},{ 8}}, + {{ 70},{ 8}}, {{198},{ 8}}, {{ 38},{ 8}}, {{166},{ 8}}, {{102},{ 8}}, + {{230},{ 8}}, {{ 22},{ 8}}, {{150},{ 8}}, {{ 86},{ 8}}, {{214},{ 8}}, + {{ 54},{ 8}}, {{182},{ 8}}, {{118},{ 8}}, {{246},{ 8}}, {{ 14},{ 8}}, + {{142},{ 8}}, {{ 78},{ 8}}, {{206},{ 8}}, {{ 46},{ 8}}, {{174},{ 8}}, + {{110},{ 8}}, {{238},{ 8}}, {{ 30},{ 8}}, {{158},{ 8}}, {{ 94},{ 8}}, + {{222},{ 8}}, {{ 62},{ 8}}, {{190},{ 8}}, {{126},{ 8}}, {{254},{ 8}}, + {{ 1},{ 8}}, {{129},{ 8}}, {{ 65},{ 8}}, {{193},{ 8}}, {{ 33},{ 8}}, + {{161},{ 8}}, {{ 97},{ 8}}, {{225},{ 8}}, {{ 17},{ 8}}, {{145},{ 8}}, + {{ 81},{ 8}}, {{209},{ 8}}, {{ 49},{ 8}}, {{177},{ 8}}, {{113},{ 8}}, + {{241},{ 8}}, {{ 9},{ 8}}, {{137},{ 8}}, {{ 73},{ 8}}, {{201},{ 8}}, + {{ 41},{ 8}}, {{169},{ 8}}, {{105},{ 8}}, {{233},{ 8}}, {{ 25},{ 8}}, + {{153},{ 8}}, {{ 89},{ 8}}, {{217},{ 8}}, {{ 57},{ 8}}, {{185},{ 8}}, + {{121},{ 8}}, {{249},{ 8}}, {{ 5},{ 8}}, {{133},{ 8}}, {{ 69},{ 8}}, + {{197},{ 8}}, {{ 37},{ 8}}, {{165},{ 8}}, {{101},{ 8}}, {{229},{ 8}}, + {{ 21},{ 8}}, {{149},{ 8}}, {{ 85},{ 8}}, {{213},{ 8}}, {{ 53},{ 8}}, + {{181},{ 8}}, {{117},{ 8}}, {{245},{ 8}}, {{ 13},{ 8}}, {{141},{ 8}}, + {{ 77},{ 8}}, {{205},{ 8}}, {{ 45},{ 8}}, {{173},{ 8}}, {{109},{ 8}}, + {{237},{ 8}}, {{ 29},{ 8}}, {{157},{ 8}}, {{ 93},{ 8}}, {{221},{ 8}}, + {{ 61},{ 8}}, {{189},{ 8}}, {{125},{ 8}}, {{253},{ 8}}, {{ 19},{ 9}}, + {{275},{ 9}}, {{147},{ 9}}, {{403},{ 9}}, {{ 83},{ 9}}, {{339},{ 9}}, + {{211},{ 9}}, {{467},{ 9}}, {{ 51},{ 9}}, {{307},{ 9}}, {{179},{ 9}}, + {{435},{ 9}}, {{115},{ 9}}, {{371},{ 9}}, {{243},{ 9}}, {{499},{ 9}}, + {{ 11},{ 9}}, {{267},{ 9}}, {{139},{ 9}}, {{395},{ 9}}, {{ 75},{ 9}}, + {{331},{ 9}}, {{203},{ 9}}, {{459},{ 9}}, {{ 43},{ 9}}, {{299},{ 9}}, + {{171},{ 9}}, {{427},{ 9}}, {{107},{ 9}}, {{363},{ 9}}, {{235},{ 9}}, + {{491},{ 9}}, {{ 27},{ 9}}, {{283},{ 9}}, {{155},{ 9}}, {{411},{ 9}}, + {{ 91},{ 9}}, {{347},{ 9}}, {{219},{ 9}}, {{475},{ 9}}, {{ 59},{ 9}}, + {{315},{ 9}}, {{187},{ 9}}, {{443},{ 9}}, {{123},{ 9}}, {{379},{ 9}}, + {{251},{ 9}}, {{507},{ 9}}, {{ 7},{ 9}}, {{263},{ 9}}, {{135},{ 9}}, + {{391},{ 9}}, {{ 71},{ 9}}, {{327},{ 9}}, {{199},{ 9}}, {{455},{ 9}}, + {{ 39},{ 9}}, {{295},{ 9}}, {{167},{ 9}}, {{423},{ 9}}, {{103},{ 9}}, + {{359},{ 9}}, {{231},{ 9}}, {{487},{ 9}}, {{ 23},{ 9}}, {{279},{ 9}}, + {{151},{ 9}}, {{407},{ 9}}, {{ 87},{ 9}}, {{343},{ 9}}, {{215},{ 9}}, + {{471},{ 9}}, {{ 55},{ 9}}, {{311},{ 9}}, {{183},{ 9}}, {{439},{ 9}}, + {{119},{ 9}}, {{375},{ 9}}, {{247},{ 9}}, {{503},{ 9}}, {{ 15},{ 9}}, + {{271},{ 9}}, {{143},{ 9}}, {{399},{ 9}}, {{ 79},{ 9}}, {{335},{ 9}}, + {{207},{ 9}}, {{463},{ 9}}, {{ 47},{ 9}}, {{303},{ 9}}, {{175},{ 9}}, + {{431},{ 9}}, {{111},{ 9}}, {{367},{ 9}}, {{239},{ 9}}, {{495},{ 9}}, + {{ 31},{ 9}}, {{287},{ 9}}, {{159},{ 9}}, {{415},{ 9}}, {{ 95},{ 9}}, + {{351},{ 9}}, {{223},{ 9}}, {{479},{ 9}}, {{ 63},{ 9}}, {{319},{ 9}}, + {{191},{ 9}}, {{447},{ 9}}, {{127},{ 9}}, {{383},{ 9}}, {{255},{ 9}}, + {{511},{ 9}}, {{ 0},{ 7}}, {{ 64},{ 7}}, {{ 32},{ 7}}, {{ 96},{ 7}}, + {{ 16},{ 7}}, {{ 80},{ 7}}, {{ 48},{ 7}}, {{112},{ 7}}, {{ 8},{ 7}}, + {{ 72},{ 7}}, {{ 40},{ 7}}, {{104},{ 7}}, {{ 24},{ 7}}, {{ 88},{ 7}}, + {{ 56},{ 7}}, {{120},{ 7}}, {{ 4},{ 7}}, {{ 68},{ 7}}, {{ 36},{ 7}}, + {{100},{ 7}}, {{ 20},{ 7}}, {{ 84},{ 7}}, {{ 52},{ 7}}, {{116},{ 7}}, + {{ 3},{ 8}}, {{131},{ 8}}, {{ 67},{ 8}}, {{195},{ 8}}, {{ 35},{ 8}}, + {{163},{ 8}}, {{ 99},{ 8}}, {{227},{ 8}} + }; + + local const ct_data static_dtree[D_CODES] = { + {{ 0},{ 5}}, {{16},{ 5}}, {{ 8},{ 5}}, {{24},{ 5}}, {{ 4},{ 5}}, + {{20},{ 5}}, {{12},{ 5}}, {{28},{ 5}}, {{ 2},{ 5}}, {{18},{ 5}}, + {{10},{ 5}}, {{26},{ 5}}, {{ 6},{ 5}}, {{22},{ 5}}, {{14},{ 5}}, + {{30},{ 5}}, {{ 1},{ 5}}, {{17},{ 5}}, {{ 9},{ 5}}, {{25},{ 5}}, + {{ 5},{ 5}}, {{21},{ 5}}, {{13},{ 5}}, {{29},{ 5}}, {{ 3},{ 5}}, + {{19},{ 5}}, {{11},{ 5}}, {{27},{ 5}}, {{ 7},{ 5}}, {{23},{ 5}} + }; + + const uch _dist_code[DIST_CODE_LEN] = { + 0, 1, 2, 3, 4, 4, 5, 5, 6, 6, 6, 6, 7, 7, 7, 7, 8, 8, 8, 8, + 8, 8, 8, 8, 9, 9, 9, 9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 10, 10, 10, + 10, 10, 10, 10, 10, 10, 10, 10, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, + 11, 11, 11, 11, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, + 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 13, 13, 13, 13, + 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, + 13, 13, 13, 13, 13, 13, 13, 13, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, + 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, + 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, + 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 15, 15, 15, 15, 15, 15, 15, 15, + 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, + 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, + 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 0, 0, 16, 17, + 18, 18, 19, 19, 20, 20, 20, 20, 21, 21, 21, 21, 22, 22, 22, 22, 22, 22, 22, 22, + 23, 23, 23, 23, 23, 23, 23, 23, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, + 24, 24, 24, 24, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, + 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, + 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 27, 27, 27, 27, 27, 27, 27, 27, + 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, + 27, 27, 27, 27, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, + 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, + 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, + 28, 28, 28, 28, 28, 28, 28, 28, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, + 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, + 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, + 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29 + }; + + const uch _length_code[MAX_MATCH-MIN_MATCH+1]= { + 0, 1, 2, 3, 4, 5, 6, 7, 8, 8, 9, 9, 10, 10, 11, 11, 12, 12, 12, 12, + 13, 13, 13, 13, 14, 14, 14, 14, 15, 15, 15, 15, 16, 16, 16, 16, 16, 16, 16, 16, + 17, 17, 17, 17, 17, 17, 17, 17, 18, 18, 18, 18, 18, 18, 18, 18, 19, 19, 19, 19, + 19, 19, 19, 19, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, + 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 22, 22, 22, 22, + 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 23, 23, 23, 23, 23, 23, 23, 23, + 23, 23, 23, 23, 23, 23, 23, 23, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, + 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, + 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, + 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 26, 26, 26, 26, 26, 26, 26, 26, + 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, + 26, 26, 26, 26, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, + 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 28 + }; + + local const int base_length[LENGTH_CODES] = { + 0, 1, 2, 3, 4, 5, 6, 7, 8, 10, 12, 14, 16, 20, 24, 28, 32, 40, 48, 56, + 64, 80, 96, 112, 128, 160, 192, 224, 0 + }; + + local const int base_dist[D_CODES] = { + 0, 1, 2, 3, 4, 6, 8, 12, 16, 24, + 32, 48, 64, 96, 128, 192, 256, 384, 512, 768, + 1024, 1536, 2048, 3072, 4096, 6144, 8192, 12288, 16384, 24576 + }; + Index: llvm-test/Runtime/zlib/uncompr.c diff -c /dev/null llvm-test/Runtime/zlib/uncompr.c:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/uncompr.c Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,61 ---- + /* uncompr.c -- decompress a memory buffer + * Copyright (C) 1995-2003 Jean-loup Gailly. + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* @(#) $Id: uncompr.c,v 1.1 2004/12/06 21:19:39 criswell Exp $ */ + + #define ZLIB_INTERNAL + #include "zlib.h" + + /* =========================================================================== + Decompresses the source buffer into the destination buffer. sourceLen is + the byte length of the source buffer. Upon entry, destLen is the total + size of the destination buffer, which must be large enough to hold the + entire uncompressed data. (The size of the uncompressed data must have + been saved previously by the compressor and transmitted to the decompressor + by some mechanism outside the scope of this compression library.) + Upon exit, destLen is the actual size of the compressed buffer. + This function can be used to decompress a whole file at once if the + input file is mmap'ed. + + uncompress returns Z_OK if success, Z_MEM_ERROR if there was not + enough memory, Z_BUF_ERROR if there was not enough room in the output + buffer, or Z_DATA_ERROR if the input data was corrupted. + */ + int ZEXPORT uncompress (dest, destLen, source, sourceLen) + Bytef *dest; + uLongf *destLen; + const Bytef *source; + uLong sourceLen; + { + z_stream stream; + int err; + + stream.next_in = (Bytef*)source; + stream.avail_in = (uInt)sourceLen; + /* Check for source > 64K on 16-bit machine: */ + if ((uLong)stream.avail_in != sourceLen) return Z_BUF_ERROR; + + stream.next_out = dest; + stream.avail_out = (uInt)*destLen; + if ((uLong)stream.avail_out != *destLen) return Z_BUF_ERROR; + + stream.zalloc = (alloc_func)0; + stream.zfree = (free_func)0; + + err = inflateInit(&stream); + if (err != Z_OK) return err; + + err = inflate(&stream, Z_FINISH); + if (err != Z_STREAM_END) { + inflateEnd(&stream); + if (err == Z_NEED_DICT || (err == Z_BUF_ERROR && stream.avail_in == 0)) + return Z_DATA_ERROR; + return err; + } + *destLen = stream.total_out; + + err = inflateEnd(&stream); + return err; + } Index: llvm-test/Runtime/zlib/zconf.h diff -c /dev/null llvm-test/Runtime/zlib/zconf.h:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/zconf.h Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,323 ---- + /* zconf.h -- configuration of the zlib compression library + * Copyright (C) 1995-2003 Jean-loup Gailly. + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* @(#) $Id: zconf.h,v 1.1 2004/12/06 21:19:39 criswell Exp $ */ + + #ifndef ZCONF_H + #define ZCONF_H + + /* + * If you *really* need a unique prefix for all types and library functions, + * compile with -DZ_PREFIX. The "standard" zlib should be compiled without it. + */ + #ifdef Z_PREFIX + # define deflateInit_ z_deflateInit_ + # define deflate z_deflate + # define deflateEnd z_deflateEnd + # define inflateInit_ z_inflateInit_ + # define inflate z_inflate + # define inflateEnd z_inflateEnd + # define deflateInit2_ z_deflateInit2_ + # define deflateSetDictionary z_deflateSetDictionary + # define deflateCopy z_deflateCopy + # define deflateReset z_deflateReset + # define deflatePrime z_deflatePrime + # define deflateParams z_deflateParams + # define deflateBound z_deflateBound + # define inflateInit2_ z_inflateInit2_ + # define inflateSetDictionary z_inflateSetDictionary + # define inflateSync z_inflateSync + # define inflateSyncPoint z_inflateSyncPoint + # define inflateCopy z_inflateCopy + # define inflateReset z_inflateReset + # define compress z_compress + # define compress2 z_compress2 + # define compressBound z_compressBound + # define uncompress z_uncompress + # define adler32 z_adler32 + # define crc32 z_crc32 + # define get_crc_table z_get_crc_table + + # define Byte z_Byte + # define uInt z_uInt + # define uLong z_uLong + # define Bytef z_Bytef + # define charf z_charf + # define intf z_intf + # define uIntf z_uIntf + # define uLongf z_uLongf + # define voidpf z_voidpf + # define voidp z_voidp + #endif + + #if defined(__MSDOS__) && !defined(MSDOS) + # define MSDOS + #endif + #if (defined(OS_2) || defined(__OS2__)) && !defined(OS2) + # define OS2 + #endif + #if defined(_WINDOWS) && !defined(WINDOWS) + # define WINDOWS + #endif + #if (defined(_WIN32) || defined(__WIN32__)) && !defined(WIN32) + # define WIN32 + #endif + #if (defined(MSDOS) || defined(OS2) || defined(WINDOWS)) && !defined(WIN32) + # if !defined(__GNUC__) && !defined(__FLAT__) && !defined(__386__) + # ifndef SYS16BIT + # define SYS16BIT + # endif + # endif + #endif + + /* + * Compile with -DMAXSEG_64K if the alloc function cannot allocate more + * than 64k bytes at a time (needed on systems with 16-bit int). + */ + #ifdef SYS16BIT + # define MAXSEG_64K + #endif + #ifdef MSDOS + # define UNALIGNED_OK + #endif + + #ifdef __STDC_VERSION__ + # ifndef STDC + # define STDC + # endif + # if __STDC_VERSION__ >= 199901L + # ifndef STDC99 + # define STDC99 + # endif + # endif + #endif + #if !defined(STDC) && (defined(__STDC__) || defined(__cplusplus)) + # define STDC + #endif + #if !defined(STDC) && (defined(__GNUC__) || defined(__BORLANDC__)) + # define STDC + #endif + #if !defined(STDC) && (defined(MSDOS) || defined(WINDOWS) || defined(WIN32)) + # define STDC + #endif + #if !defined(STDC) && (defined(OS2) || defined(__HOS_AIX__)) + # define STDC + #endif + + #if defined(__OS400__) && !defined(STDC) /* iSeries (formerly AS/400). */ + # define STDC + #endif + + #ifndef STDC + # ifndef const /* cannot use !defined(STDC) && !defined(const) on Mac */ + # define const /* note: need a more gentle solution here */ + # endif + #endif + + /* Some Mac compilers merge all .h files incorrectly: */ + #if defined(__MWERKS__)||defined(applec)||defined(THINK_C)||defined(__SC__) + # define NO_DUMMY_DECL + #endif + + /* Maximum value for memLevel in deflateInit2 */ + #ifndef MAX_MEM_LEVEL + # ifdef MAXSEG_64K + # define MAX_MEM_LEVEL 8 + # else + # define MAX_MEM_LEVEL 9 + # endif + #endif + + /* Maximum value for windowBits in deflateInit2 and inflateInit2. + * WARNING: reducing MAX_WBITS makes minigzip unable to extract .gz files + * created by gzip. (Files created by minigzip can still be extracted by + * gzip.) + */ + #ifndef MAX_WBITS + # define MAX_WBITS 15 /* 32K LZ77 window */ + #endif + + /* The memory requirements for deflate are (in bytes): + (1 << (windowBits+2)) + (1 << (memLevel+9)) + that is: 128K for windowBits=15 + 128K for memLevel = 8 (default values) + plus a few kilobytes for small objects. For example, if you want to reduce + the default memory requirements from 256K to 128K, compile with + make CFLAGS="-O -DMAX_WBITS=14 -DMAX_MEM_LEVEL=7" + Of course this will generally degrade compression (there's no free lunch). + + The memory requirements for inflate are (in bytes) 1 << windowBits + that is, 32K for windowBits=15 (default value) plus a few kilobytes + for small objects. + */ + + /* Type declarations */ + + #ifndef OF /* function prototypes */ + # ifdef STDC + # define OF(args) args + # else + # define OF(args) () + # endif + #endif + + /* The following definitions for FAR are needed only for MSDOS mixed + * model programming (small or medium model with some far allocations). + * This was tested only with MSC; for other MSDOS compilers you may have + * to define NO_MEMCPY in zutil.h. If you don't need the mixed model, + * just define FAR to be empty. + */ + #ifdef SYS16BIT + # if defined(M_I86SM) || defined(M_I86MM) + /* MSC small or medium model */ + # define SMALL_MEDIUM + # ifdef _MSC_VER + # define FAR _far + # else + # define FAR far + # endif + # endif + # if (defined(__SMALL__) || defined(__MEDIUM__)) + /* Turbo C small or medium model */ + # define SMALL_MEDIUM + # ifdef __BORLANDC__ + # define FAR _far + # else + # define FAR far + # endif + # endif + #endif + + #if defined(WINDOWS) || defined(WIN32) + /* If building or using zlib as a DLL, define ZLIB_DLL. + * This is not mandatory, but it offers a little performance increase. + */ + # ifdef ZLIB_DLL + # if defined(WIN32) && (!defined(__BORLANDC__) || (__BORLANDC__ >= 0x500)) + # ifdef ZLIB_INTERNAL + # define ZEXTERN extern __declspec(dllexport) + # else + # define ZEXTERN extern __declspec(dllimport) + # endif + # endif + # endif /* ZLIB_DLL */ + /* If building or using zlib with the WINAPI/WINAPIV calling convention, + * define ZLIB_WINAPI. + * Caution: the standard ZLIB1.DLL is NOT compiled using ZLIB_WINAPI. + */ + # ifdef ZLIB_WINAPI + # ifdef FAR + # undef FAR + # endif + # include + /* No need for _export, use ZLIB.DEF instead. */ + /* For complete Windows compatibility, use WINAPI, not __stdcall. */ + # define ZEXPORT WINAPI + # ifdef WIN32 + # define ZEXPORTVA WINAPIV + # else + # define ZEXPORTVA FAR CDECL + # endif + # endif + #endif + + #if defined (__BEOS__) + # ifdef ZLIB_DLL + # ifdef ZLIB_INTERNAL + # define ZEXPORT __declspec(dllexport) + # define ZEXPORTVA __declspec(dllexport) + # else + # define ZEXPORT __declspec(dllimport) + # define ZEXPORTVA __declspec(dllimport) + # endif + # endif + #endif + + #ifndef ZEXTERN + # define ZEXTERN extern + #endif + #ifndef ZEXPORT + # define ZEXPORT + #endif + #ifndef ZEXPORTVA + # define ZEXPORTVA + #endif + + #ifndef FAR + # define FAR + #endif + + #if !defined(__MACTYPES__) + typedef unsigned char Byte; /* 8 bits */ + #endif + typedef unsigned int uInt; /* 16 bits or more */ + typedef unsigned long uLong; /* 32 bits or more */ + + #ifdef SMALL_MEDIUM + /* Borland C/C++ and some old MSC versions ignore FAR inside typedef */ + # define Bytef Byte FAR + #else + typedef Byte FAR Bytef; + #endif + typedef char FAR charf; + typedef int FAR intf; + typedef uInt FAR uIntf; + typedef uLong FAR uLongf; + + #ifdef STDC + typedef void const *voidpc; + typedef void FAR *voidpf; + typedef void *voidp; + #else + typedef Byte const *voidpc; + typedef Byte FAR *voidpf; + typedef Byte *voidp; + #endif + + #if 0 /* HAVE_UNISTD_H -- this line is updated by ./configure */ + # include /* for off_t */ + # include /* for SEEK_* and off_t */ + # ifdef VMS + # include /* for off_t */ + # endif + # define z_off_t off_t + #endif + #ifndef SEEK_SET + # define SEEK_SET 0 /* Seek from beginning of file. */ + # define SEEK_CUR 1 /* Seek from current position. */ + # define SEEK_END 2 /* Set file pointer to EOF plus "offset" */ + #endif + #ifndef z_off_t + # define z_off_t long + #endif + + #if defined(__OS400__) + #define NO_vsnprintf + #endif + + #if defined(__MVS__) + # define NO_vsnprintf + # ifdef FAR + # undef FAR + # endif + #endif + + /* MVS linker does not support external names larger than 8 bytes */ + #if defined(__MVS__) + # pragma map(deflateInit_,"DEIN") + # pragma map(deflateInit2_,"DEIN2") + # pragma map(deflateEnd,"DEEND") + # pragma map(deflateBound,"DEBND") + # pragma map(inflateInit_,"ININ") + # pragma map(inflateInit2_,"ININ2") + # pragma map(inflateEnd,"INEND") + # pragma map(inflateSync,"INSY") + # pragma map(inflateSetDictionary,"INSEDI") + # pragma map(compressBound,"CMBND") + # pragma map(inflate_table,"INTABL") + # pragma map(inflate_fast,"INFA") + # pragma map(inflate_copyright,"INCOPY") + #endif + + #endif /* ZCONF_H */ Index: llvm-test/Runtime/zlib/zconf.in.h diff -c /dev/null llvm-test/Runtime/zlib/zconf.in.h:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/zconf.in.h Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,323 ---- + /* zconf.h -- configuration of the zlib compression library + * Copyright (C) 1995-2003 Jean-loup Gailly. + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* @(#) $Id: zconf.in.h,v 1.1 2004/12/06 21:19:39 criswell Exp $ */ + + #ifndef ZCONF_H + #define ZCONF_H + + /* + * If you *really* need a unique prefix for all types and library functions, + * compile with -DZ_PREFIX. The "standard" zlib should be compiled without it. + */ + #ifdef Z_PREFIX + # define deflateInit_ z_deflateInit_ + # define deflate z_deflate + # define deflateEnd z_deflateEnd + # define inflateInit_ z_inflateInit_ + # define inflate z_inflate + # define inflateEnd z_inflateEnd + # define deflateInit2_ z_deflateInit2_ + # define deflateSetDictionary z_deflateSetDictionary + # define deflateCopy z_deflateCopy + # define deflateReset z_deflateReset + # define deflatePrime z_deflatePrime + # define deflateParams z_deflateParams + # define deflateBound z_deflateBound + # define inflateInit2_ z_inflateInit2_ + # define inflateSetDictionary z_inflateSetDictionary + # define inflateSync z_inflateSync + # define inflateSyncPoint z_inflateSyncPoint + # define inflateCopy z_inflateCopy + # define inflateReset z_inflateReset + # define compress z_compress + # define compress2 z_compress2 + # define compressBound z_compressBound + # define uncompress z_uncompress + # define adler32 z_adler32 + # define crc32 z_crc32 + # define get_crc_table z_get_crc_table + + # define Byte z_Byte + # define uInt z_uInt + # define uLong z_uLong + # define Bytef z_Bytef + # define charf z_charf + # define intf z_intf + # define uIntf z_uIntf + # define uLongf z_uLongf + # define voidpf z_voidpf + # define voidp z_voidp + #endif + + #if defined(__MSDOS__) && !defined(MSDOS) + # define MSDOS + #endif + #if (defined(OS_2) || defined(__OS2__)) && !defined(OS2) + # define OS2 + #endif + #if defined(_WINDOWS) && !defined(WINDOWS) + # define WINDOWS + #endif + #if (defined(_WIN32) || defined(__WIN32__)) && !defined(WIN32) + # define WIN32 + #endif + #if (defined(MSDOS) || defined(OS2) || defined(WINDOWS)) && !defined(WIN32) + # if !defined(__GNUC__) && !defined(__FLAT__) && !defined(__386__) + # ifndef SYS16BIT + # define SYS16BIT + # endif + # endif + #endif + + /* + * Compile with -DMAXSEG_64K if the alloc function cannot allocate more + * than 64k bytes at a time (needed on systems with 16-bit int). + */ + #ifdef SYS16BIT + # define MAXSEG_64K + #endif + #ifdef MSDOS + # define UNALIGNED_OK + #endif + + #ifdef __STDC_VERSION__ + # ifndef STDC + # define STDC + # endif + # if __STDC_VERSION__ >= 199901L + # ifndef STDC99 + # define STDC99 + # endif + # endif + #endif + #if !defined(STDC) && (defined(__STDC__) || defined(__cplusplus)) + # define STDC + #endif + #if !defined(STDC) && (defined(__GNUC__) || defined(__BORLANDC__)) + # define STDC + #endif + #if !defined(STDC) && (defined(MSDOS) || defined(WINDOWS) || defined(WIN32)) + # define STDC + #endif + #if !defined(STDC) && (defined(OS2) || defined(__HOS_AIX__)) + # define STDC + #endif + + #if defined(__OS400__) && !defined(STDC) /* iSeries (formerly AS/400). */ + # define STDC + #endif + + #ifndef STDC + # ifndef const /* cannot use !defined(STDC) && !defined(const) on Mac */ + # define const /* note: need a more gentle solution here */ + # endif + #endif + + /* Some Mac compilers merge all .h files incorrectly: */ + #if defined(__MWERKS__)||defined(applec)||defined(THINK_C)||defined(__SC__) + # define NO_DUMMY_DECL + #endif + + /* Maximum value for memLevel in deflateInit2 */ + #ifndef MAX_MEM_LEVEL + # ifdef MAXSEG_64K + # define MAX_MEM_LEVEL 8 + # else + # define MAX_MEM_LEVEL 9 + # endif + #endif + + /* Maximum value for windowBits in deflateInit2 and inflateInit2. + * WARNING: reducing MAX_WBITS makes minigzip unable to extract .gz files + * created by gzip. (Files created by minigzip can still be extracted by + * gzip.) + */ + #ifndef MAX_WBITS + # define MAX_WBITS 15 /* 32K LZ77 window */ + #endif + + /* The memory requirements for deflate are (in bytes): + (1 << (windowBits+2)) + (1 << (memLevel+9)) + that is: 128K for windowBits=15 + 128K for memLevel = 8 (default values) + plus a few kilobytes for small objects. For example, if you want to reduce + the default memory requirements from 256K to 128K, compile with + make CFLAGS="-O -DMAX_WBITS=14 -DMAX_MEM_LEVEL=7" + Of course this will generally degrade compression (there's no free lunch). + + The memory requirements for inflate are (in bytes) 1 << windowBits + that is, 32K for windowBits=15 (default value) plus a few kilobytes + for small objects. + */ + + /* Type declarations */ + + #ifndef OF /* function prototypes */ + # ifdef STDC + # define OF(args) args + # else + # define OF(args) () + # endif + #endif + + /* The following definitions for FAR are needed only for MSDOS mixed + * model programming (small or medium model with some far allocations). + * This was tested only with MSC; for other MSDOS compilers you may have + * to define NO_MEMCPY in zutil.h. If you don't need the mixed model, + * just define FAR to be empty. + */ + #ifdef SYS16BIT + # if defined(M_I86SM) || defined(M_I86MM) + /* MSC small or medium model */ + # define SMALL_MEDIUM + # ifdef _MSC_VER + # define FAR _far + # else + # define FAR far + # endif + # endif + # if (defined(__SMALL__) || defined(__MEDIUM__)) + /* Turbo C small or medium model */ + # define SMALL_MEDIUM + # ifdef __BORLANDC__ + # define FAR _far + # else + # define FAR far + # endif + # endif + #endif + + #if defined(WINDOWS) || defined(WIN32) + /* If building or using zlib as a DLL, define ZLIB_DLL. + * This is not mandatory, but it offers a little performance increase. + */ + # ifdef ZLIB_DLL + # if defined(WIN32) && (!defined(__BORLANDC__) || (__BORLANDC__ >= 0x500)) + # ifdef ZLIB_INTERNAL + # define ZEXTERN extern __declspec(dllexport) + # else + # define ZEXTERN extern __declspec(dllimport) + # endif + # endif + # endif /* ZLIB_DLL */ + /* If building or using zlib with the WINAPI/WINAPIV calling convention, + * define ZLIB_WINAPI. + * Caution: the standard ZLIB1.DLL is NOT compiled using ZLIB_WINAPI. + */ + # ifdef ZLIB_WINAPI + # ifdef FAR + # undef FAR + # endif + # include + /* No need for _export, use ZLIB.DEF instead. */ + /* For complete Windows compatibility, use WINAPI, not __stdcall. */ + # define ZEXPORT WINAPI + # ifdef WIN32 + # define ZEXPORTVA WINAPIV + # else + # define ZEXPORTVA FAR CDECL + # endif + # endif + #endif + + #if defined (__BEOS__) + # ifdef ZLIB_DLL + # ifdef ZLIB_INTERNAL + # define ZEXPORT __declspec(dllexport) + # define ZEXPORTVA __declspec(dllexport) + # else + # define ZEXPORT __declspec(dllimport) + # define ZEXPORTVA __declspec(dllimport) + # endif + # endif + #endif + + #ifndef ZEXTERN + # define ZEXTERN extern + #endif + #ifndef ZEXPORT + # define ZEXPORT + #endif + #ifndef ZEXPORTVA + # define ZEXPORTVA + #endif + + #ifndef FAR + # define FAR + #endif + + #if !defined(__MACTYPES__) + typedef unsigned char Byte; /* 8 bits */ + #endif + typedef unsigned int uInt; /* 16 bits or more */ + typedef unsigned long uLong; /* 32 bits or more */ + + #ifdef SMALL_MEDIUM + /* Borland C/C++ and some old MSC versions ignore FAR inside typedef */ + # define Bytef Byte FAR + #else + typedef Byte FAR Bytef; + #endif + typedef char FAR charf; + typedef int FAR intf; + typedef uInt FAR uIntf; + typedef uLong FAR uLongf; + + #ifdef STDC + typedef void const *voidpc; + typedef void FAR *voidpf; + typedef void *voidp; + #else + typedef Byte const *voidpc; + typedef Byte FAR *voidpf; + typedef Byte *voidp; + #endif + + #if 0 /* HAVE_UNISTD_H -- this line is updated by ./configure */ + # include /* for off_t */ + # include /* for SEEK_* and off_t */ + # ifdef VMS + # include /* for off_t */ + # endif + # define z_off_t off_t + #endif + #ifndef SEEK_SET + # define SEEK_SET 0 /* Seek from beginning of file. */ + # define SEEK_CUR 1 /* Seek from current position. */ + # define SEEK_END 2 /* Set file pointer to EOF plus "offset" */ + #endif + #ifndef z_off_t + # define z_off_t long + #endif + + #if defined(__OS400__) + #define NO_vsnprintf + #endif + + #if defined(__MVS__) + # define NO_vsnprintf + # ifdef FAR + # undef FAR + # endif + #endif + + /* MVS linker does not support external names larger than 8 bytes */ + #if defined(__MVS__) + # pragma map(deflateInit_,"DEIN") + # pragma map(deflateInit2_,"DEIN2") + # pragma map(deflateEnd,"DEEND") + # pragma map(deflateBound,"DEBND") + # pragma map(inflateInit_,"ININ") + # pragma map(inflateInit2_,"ININ2") + # pragma map(inflateEnd,"INEND") + # pragma map(inflateSync,"INSY") + # pragma map(inflateSetDictionary,"INSEDI") + # pragma map(compressBound,"CMBND") + # pragma map(inflate_table,"INTABL") + # pragma map(inflate_fast,"INFA") + # pragma map(inflate_copyright,"INCOPY") + #endif + + #endif /* ZCONF_H */ Index: llvm-test/Runtime/zlib/zlib.3 diff -c /dev/null llvm-test/Runtime/zlib/zlib.3:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/zlib.3 Mon Dec 6 15:19:39 2004 *************** *** 0 **** --- 1,159 ---- + .TH ZLIB 3 "17 November 2003" + .SH NAME + zlib \- compression/decompression library + .SH SYNOPSIS + [see + .I zlib.h + for full description] + .SH DESCRIPTION + The + .I zlib + library is a general purpose data compression library. + The code is thread safe. + It provides in-memory compression and decompression functions, + including integrity checks of the uncompressed data. + This version of the library supports only one compression method (deflation) + but other algorithms will be added later + and will have the same stream interface. + .LP + Compression can be done in a single step if the buffers are large enough + (for example if an input file is mmap'ed), + or can be done by repeated calls of the compression function. + In the latter case, + the application must provide more input and/or consume the output + (providing more output space) before each call. + .LP + The library also supports reading and writing files in + .IR gzip (1) + (.gz) format + with an interface similar to that of stdio. + .LP + The library does not install any signal handler. + The decoder checks the consistency of the compressed data, + so the library should never crash even in case of corrupted input. + .LP + All functions of the compression library are documented in the file + .IR zlib.h . + The distribution source includes examples of use of the library + in the files + .I example.c + and + .IR minigzip.c . + .LP + Changes to this version are documented in the file + .I ChangeLog + that accompanies the source, + and are concerned primarily with bug fixes and portability enhancements. + .LP + A Java implementation of + .I zlib + is available in the Java Development Kit 1.1: + .IP + http://www.javasoft.com/products/JDK/1.1/docs/api/Package-java.util.zip.html + .LP + A Perl interface to + .IR zlib , + written by Paul Marquess (pmqs at cpan.org), + is available at CPAN (Comprehensive Perl Archive Network) sites, + including: + .IP + http://www.cpan.org/modules/by-module/Compress/ + .LP + A Python interface to + .IR zlib , + written by A.M. Kuchling (amk at magnet.com), + is available in Python 1.5 and later versions: + .IP + http://www.python.org/doc/lib/module-zlib.html + .LP + A + .I zlib + binding for + .IR tcl (1), + written by Andreas Kupries (a.kupries at westend.com), + is availlable at: + .IP + http://www.westend.com/~kupries/doc/trf/man/man.html + .LP + An experimental package to read and write files in .zip format, + written on top of + .I zlib + by Gilles Vollant (info at winimage.com), + is available at: + .IP + http://www.winimage.com/zLibDll/unzip.html + and also in the + .I contrib/minizip + directory of the main + .I zlib + web site. + .SH "SEE ALSO" + The + .I zlib + web site can be found at either of these locations: + .IP + http://www.zlib.org + .br + http://www.gzip.org/zlib/ + .LP + The data format used by the zlib library is described by RFC + (Request for Comments) 1950 to 1952 in the files: + .IP + http://www.ietf.org/rfc/rfc1950.txt (concerning zlib format) + .br + http://www.ietf.org/rfc/rfc1951.txt (concerning deflate format) + .br + http://www.ietf.org/rfc/rfc1952.txt (concerning gzip format) + .LP + These documents are also available in other formats from: + .IP + ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html + .LP + Mark Nelson (markn at ieee.org) wrote an article about + .I zlib + for the Jan. 1997 issue of Dr. Dobb's Journal; + a copy of the article is available at: + .IP + http://dogma.net/markn/articles/zlibtool/zlibtool.htm + .SH "REPORTING PROBLEMS" + Before reporting a problem, + please check the + .I zlib + web site to verify that you have the latest version of + .IR zlib ; + otherwise, + obtain the latest version and see if the problem still exists. + Please read the + .I zlib + FAQ at: + .IP + http://www.gzip.org/zlib/zlib_faq.html + .LP + before asking for help. + Send questions and/or comments to zlib at gzip.org, + or (for the Windows DLL version) to Gilles Vollant (info at winimage.com). + .SH AUTHORS + Version 1.2.1 + Copyright (C) 1995-2003 Jean-loup Gailly (jloup at gzip.org) + and Mark Adler (madler at alumni.caltech.edu). + .LP + This software is provided "as-is," + without any express or implied warranty. + In no event will the authors be held liable for any damages + arising from the use of this software. + See the distribution directory with respect to requirements + governing redistribution. + The deflate format used by + .I zlib + was defined by Phil Katz. + The deflate and + .I zlib + specifications were written by L. Peter Deutsch. + Thanks to all the people who reported problems and suggested various + improvements in + .IR zlib ; + who are too numerous to cite here. + .LP + UNIX manual page by R. P. C. Rodgers, + U.S. National Library of Medicine (rodgers at nlm.nih.gov). + .\" end of man page Index: llvm-test/Runtime/zlib/zlib.h diff -c /dev/null llvm-test/Runtime/zlib/zlib.h:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/zlib.h Mon Dec 6 15:19:40 2004 *************** *** 0 **** --- 1,1206 ---- + /* + * Changes made by the LLVM Team (llvmdev at cs.uiuc.edu, 2/6/2004): + * 1) Makefile was modified for building with the LLVM build system and tools. + * 2) Version numbers were updated as described in the FAQ. + * 3) LLVM LICENSE.TXT file was added describing licensing information. + */ + /* zlib.h -- interface of the 'zlib' general purpose compression library + version 1.2.1, November 17th, 2003 + + Copyright (C) 1995-2003 Jean-loup Gailly and Mark Adler + + This software is provided 'as-is', without any express or implied + warranty. In no event will the authors be held liable for any damages + arising from the use of this software. + + Permission is granted to anyone to use this software for any purpose, + including commercial applications, and to alter it and redistribute it + freely, subject to the following restrictions: + + 1. The origin of this software must not be misrepresented; you must not + claim that you wrote the original software. If you use this software + in a product, an acknowledgment in the product documentation would be + appreciated but is not required. + 2. Altered source versions must be plainly marked as such, and must not be + misrepresented as being the original software. + 3. This notice may not be removed or altered from any source distribution. + + Jean-loup Gailly Mark Adler + jloup at gzip.org madler at alumni.caltech.edu + + + The data format used by the zlib library is described by RFCs (Request for + Comments) 1950 to 1952 in the files http://www.ietf.org/rfc/rfc1950.txt + (zlib format), rfc1951.txt (deflate format) and rfc1952.txt (gzip format). + */ + + #ifndef ZLIB_H + #define ZLIB_H + + #include "zconf.h" + + #ifdef __cplusplus + extern "C" { + #endif + + #define ZLIB_VERSION "1.2.f-llvm" + #define ZLIB_VERNUM 0x121f + + /* + The 'zlib' compression library provides in-memory compression and + decompression functions, including integrity checks of the uncompressed + data. This version of the library supports only one compression method + (deflation) but other algorithms will be added later and will have the same + stream interface. + + Compression can be done in a single step if the buffers are large + enough (for example if an input file is mmap'ed), or can be done by + repeated calls of the compression function. In the latter case, the + application must provide more input and/or consume the output + (providing more output space) before each call. + + The compressed data format used by the in-memory functions is the zlib + format, which is a zlib wrapper documented in RFC 1950, wrapped around a + deflate stream, which is itself documented in RFC 1951. + + The library also supports reading and writing files in gzip (.gz) format + with an interface similar to that of stdio using the functions that start + with "gz". The gzip format is different from the zlib format. gzip is a + gzip wrapper, documented in RFC 1952, wrapped around a deflate stream. + + The zlib format was designed to be compact and fast for use in memory + and on communications channels. The gzip format was designed for single- + file compression on file systems, has a larger header than zlib to maintain + directory information, and uses a different, slower check method than zlib. + + This library does not provide any functions to write gzip files in memory. + However such functions could be easily written using zlib's deflate function, + the documentation in the gzip RFC, and the examples in gzio.c. + + The library does not install any signal handler. The decoder checks + the consistency of the compressed data, so the library should never + crash even in case of corrupted input. + */ + + typedef voidpf (*alloc_func) OF((voidpf opaque, uInt items, uInt size)); + typedef void (*free_func) OF((voidpf opaque, voidpf address)); + + struct internal_state; + + typedef struct z_stream_s { + Bytef *next_in; /* next input byte */ + uInt avail_in; /* number of bytes available at next_in */ + uLong total_in; /* total nb of input bytes read so far */ + + Bytef *next_out; /* next output byte should be put there */ + uInt avail_out; /* remaining free space at next_out */ + uLong total_out; /* total nb of bytes output so far */ + + char *msg; /* last error message, NULL if no error */ + struct internal_state FAR *state; /* not visible by applications */ + + alloc_func zalloc; /* used to allocate the internal state */ + free_func zfree; /* used to free the internal state */ + voidpf opaque; /* private data object passed to zalloc and zfree */ + + int data_type; /* best guess about the data type: ascii or binary */ + uLong adler; /* adler32 value of the uncompressed data */ + uLong reserved; /* reserved for future use */ + } z_stream; + + typedef z_stream FAR *z_streamp; + + /* + The application must update next_in and avail_in when avail_in has + dropped to zero. It must update next_out and avail_out when avail_out + has dropped to zero. The application must initialize zalloc, zfree and + opaque before calling the init function. All other fields are set by the + compression library and must not be updated by the application. + + The opaque value provided by the application will be passed as the first + parameter for calls of zalloc and zfree. This can be useful for custom + memory management. The compression library attaches no meaning to the + opaque value. + + zalloc must return Z_NULL if there is not enough memory for the object. + If zlib is used in a multi-threaded application, zalloc and zfree must be + thread safe. + + On 16-bit systems, the functions zalloc and zfree must be able to allocate + exactly 65536 bytes, but will not be required to allocate more than this + if the symbol MAXSEG_64K is defined (see zconf.h). WARNING: On MSDOS, + pointers returned by zalloc for objects of exactly 65536 bytes *must* + have their offset normalized to zero. The default allocation function + provided by this library ensures this (see zutil.c). To reduce memory + requirements and avoid any allocation of 64K objects, at the expense of + compression ratio, compile the library with -DMAX_WBITS=14 (see zconf.h). + + The fields total_in and total_out can be used for statistics or + progress reports. After compression, total_in holds the total size of + the uncompressed data and may be saved for use in the decompressor + (particularly if the decompressor wants to decompress everything in + a single step). + */ + + /* constants */ + + #define Z_NO_FLUSH 0 + #define Z_PARTIAL_FLUSH 1 /* will be removed, use Z_SYNC_FLUSH instead */ + #define Z_SYNC_FLUSH 2 + #define Z_FULL_FLUSH 3 + #define Z_FINISH 4 + #define Z_BLOCK 5 + /* Allowed flush values; see deflate() and inflate() below for details */ + + #define Z_OK 0 + #define Z_STREAM_END 1 + #define Z_NEED_DICT 2 + #define Z_ERRNO (-1) + #define Z_STREAM_ERROR (-2) + #define Z_DATA_ERROR (-3) + #define Z_MEM_ERROR (-4) + #define Z_BUF_ERROR (-5) + #define Z_VERSION_ERROR (-6) + /* Return codes for the compression/decompression functions. Negative + * values are errors, positive values are used for special but normal events. + */ + + #define Z_NO_COMPRESSION 0 + #define Z_BEST_SPEED 1 + #define Z_BEST_COMPRESSION 9 + #define Z_DEFAULT_COMPRESSION (-1) + /* compression levels */ + + #define Z_FILTERED 1 + #define Z_HUFFMAN_ONLY 2 + #define Z_RLE 3 + #define Z_DEFAULT_STRATEGY 0 + /* compression strategy; see deflateInit2() below for details */ + + #define Z_BINARY 0 + #define Z_ASCII 1 + #define Z_UNKNOWN 2 + /* Possible values of the data_type field (though see inflate()) */ + + #define Z_DEFLATED 8 + /* The deflate compression method (the only one supported in this version) */ + + #define Z_NULL 0 /* for initializing zalloc, zfree, opaque */ + + #define zlib_version zlibVersion() + /* for compatibility with versions < 1.0.2 */ + + /* basic functions */ + + ZEXTERN const char * ZEXPORT zlibVersion OF((void)); + /* The application can compare zlibVersion and ZLIB_VERSION for consistency. + If the first character differs, the library code actually used is + not compatible with the zlib.h header file used by the application. + This check is automatically made by deflateInit and inflateInit. + */ + + /* + ZEXTERN int ZEXPORT deflateInit OF((z_streamp strm, int level)); + + Initializes the internal stream state for compression. The fields + zalloc, zfree and opaque must be initialized before by the caller. + If zalloc and zfree are set to Z_NULL, deflateInit updates them to + use default allocation functions. + + The compression level must be Z_DEFAULT_COMPRESSION, or between 0 and 9: + 1 gives best speed, 9 gives best compression, 0 gives no compression at + all (the input data is simply copied a block at a time). + Z_DEFAULT_COMPRESSION requests a default compromise between speed and + compression (currently equivalent to level 6). + + deflateInit returns Z_OK if success, Z_MEM_ERROR if there was not + enough memory, Z_STREAM_ERROR if level is not a valid compression level, + Z_VERSION_ERROR if the zlib library version (zlib_version) is incompatible + with the version assumed by the caller (ZLIB_VERSION). + msg is set to null if there is no error message. deflateInit does not + perform any compression: this will be done by deflate(). + */ + + + ZEXTERN int ZEXPORT deflate OF((z_streamp strm, int flush)); + /* + deflate compresses as much data as possible, and stops when the input + buffer becomes empty or the output buffer becomes full. It may introduce some + output latency (reading input without producing any output) except when + forced to flush. + + The detailed semantics are as follows. deflate performs one or both of the + following actions: + + - Compress more input starting at next_in and update next_in and avail_in + accordingly. If not all input can be processed (because there is not + enough room in the output buffer), next_in and avail_in are updated and + processing will resume at this point for the next call of deflate(). + + - Provide more output starting at next_out and update next_out and avail_out + accordingly. This action is forced if the parameter flush is non zero. + Forcing flush frequently degrades the compression ratio, so this parameter + should be set only when necessary (in interactive applications). + Some output may be provided even if flush is not set. + + Before the call of deflate(), the application should ensure that at least + one of the actions is possible, by providing more input and/or consuming + more output, and updating avail_in or avail_out accordingly; avail_out + should never be zero before the call. The application can consume the + compressed output when it wants, for example when the output buffer is full + (avail_out == 0), or after each call of deflate(). If deflate returns Z_OK + and with zero avail_out, it must be called again after making room in the + output buffer because there might be more output pending. + + If the parameter flush is set to Z_SYNC_FLUSH, all pending output is + flushed to the output buffer and the output is aligned on a byte boundary, so + that the decompressor can get all input data available so far. (In particular + avail_in is zero after the call if enough output space has been provided + before the call.) Flushing may degrade compression for some compression + algorithms and so it should be used only when necessary. + + If flush is set to Z_FULL_FLUSH, all output is flushed as with + Z_SYNC_FLUSH, and the compression state is reset so that decompression can + restart from this point if previous compressed data has been damaged or if + random access is desired. Using Z_FULL_FLUSH too often can seriously degrade + the compression. + + If deflate returns with avail_out == 0, this function must be called again + with the same value of the flush parameter and more output space (updated + avail_out), until the flush is complete (deflate returns with non-zero + avail_out). In the case of a Z_FULL_FLUSH or Z_SYNC_FLUSH, make sure that + avail_out is greater than six to avoid repeated flush markers due to + avail_out == 0 on return. + + If the parameter flush is set to Z_FINISH, pending input is processed, + pending output is flushed and deflate returns with Z_STREAM_END if there + was enough output space; if deflate returns with Z_OK, this function must be + called again with Z_FINISH and more output space (updated avail_out) but no + more input data, until it returns with Z_STREAM_END or an error. After + deflate has returned Z_STREAM_END, the only possible operations on the + stream are deflateReset or deflateEnd. + + Z_FINISH can be used immediately after deflateInit if all the compression + is to be done in a single step. In this case, avail_out must be at least + the value returned by deflateBound (see below). If deflate does not return + Z_STREAM_END, then it must be called again as described above. + + deflate() sets strm->adler to the adler32 checksum of all input read + so far (that is, total_in bytes). + + deflate() may update data_type if it can make a good guess about + the input data type (Z_ASCII or Z_BINARY). In doubt, the data is considered + binary. This field is only for information purposes and does not affect + the compression algorithm in any manner. + + deflate() returns Z_OK if some progress has been made (more input + processed or more output produced), Z_STREAM_END if all input has been + consumed and all output has been produced (only when flush is set to + Z_FINISH), Z_STREAM_ERROR if the stream state was inconsistent (for example + if next_in or next_out was NULL), Z_BUF_ERROR if no progress is possible + (for example avail_in or avail_out was zero). Note that Z_BUF_ERROR is not + fatal, and deflate() can be called again with more input and more output + space to continue compressing. + */ + + + ZEXTERN int ZEXPORT deflateEnd OF((z_streamp strm)); + /* + All dynamically allocated data structures for this stream are freed. + This function discards any unprocessed input and does not flush any + pending output. + + deflateEnd returns Z_OK if success, Z_STREAM_ERROR if the + stream state was inconsistent, Z_DATA_ERROR if the stream was freed + prematurely (some input or output was discarded). In the error case, + msg may be set but then points to a static string (which must not be + deallocated). + */ + + + /* + ZEXTERN int ZEXPORT inflateInit OF((z_streamp strm)); + + Initializes the internal stream state for decompression. The fields + next_in, avail_in, zalloc, zfree and opaque must be initialized before by + the caller. If next_in is not Z_NULL and avail_in is large enough (the exact + value depends on the compression method), inflateInit determines the + compression method from the zlib header and allocates all data structures + accordingly; otherwise the allocation will be deferred to the first call of + inflate. If zalloc and zfree are set to Z_NULL, inflateInit updates them to + use default allocation functions. + + inflateInit returns Z_OK if success, Z_MEM_ERROR if there was not enough + memory, Z_VERSION_ERROR if the zlib library version is incompatible with the + version assumed by the caller. msg is set to null if there is no error + message. inflateInit does not perform any decompression apart from reading + the zlib header if present: this will be done by inflate(). (So next_in and + avail_in may be modified, but next_out and avail_out are unchanged.) + */ + + + ZEXTERN int ZEXPORT inflate OF((z_streamp strm, int flush)); + /* + inflate decompresses as much data as possible, and stops when the input + buffer becomes empty or the output buffer becomes full. It may introduce + some output latency (reading input without producing any output) except when + forced to flush. + + The detailed semantics are as follows. inflate performs one or both of the + following actions: + + - Decompress more input starting at next_in and update next_in and avail_in + accordingly. If not all input can be processed (because there is not + enough room in the output buffer), next_in is updated and processing + will resume at this point for the next call of inflate(). + + - Provide more output starting at next_out and update next_out and avail_out + accordingly. inflate() provides as much output as possible, until there + is no more input data or no more space in the output buffer (see below + about the flush parameter). + + Before the call of inflate(), the application should ensure that at least + one of the actions is possible, by providing more input and/or consuming + more output, and updating the next_* and avail_* values accordingly. + The application can consume the uncompressed output when it wants, for + example when the output buffer is full (avail_out == 0), or after each + call of inflate(). If inflate returns Z_OK and with zero avail_out, it + must be called again after making room in the output buffer because there + might be more output pending. + + The flush parameter of inflate() can be Z_NO_FLUSH, Z_SYNC_FLUSH, + Z_FINISH, or Z_BLOCK. Z_SYNC_FLUSH requests that inflate() flush as much + output as possible to the output buffer. Z_BLOCK requests that inflate() stop + if and when it get to the next deflate block boundary. When decoding the zlib + or gzip format, this will cause inflate() to return immediately after the + header and before the first block. When doing a raw inflate, inflate() will + go ahead and process the first block, and will return when it gets to the end + of that block, or when it runs out of data. + + The Z_BLOCK option assists in appending to or combining deflate streams. + Also to assist in this, on return inflate() will set strm->data_type to the + number of unused bits in the last byte taken from strm->next_in, plus 64 + if inflate() is currently decoding the last block in the deflate stream, + plus 128 if inflate() returned immediately after decoding an end-of-block + code or decoding the complete header up to just before the first byte of the + deflate stream. The end-of-block will not be indicated until all of the + uncompressed data from that block has been written to strm->next_out. The + number of unused bits may in general be greater than seven, except when + bit 7 of data_type is set, in which case the number of unused bits will be + less than eight. + + inflate() should normally be called until it returns Z_STREAM_END or an + error. However if all decompression is to be performed in a single step + (a single call of inflate), the parameter flush should be set to + Z_FINISH. In this case all pending input is processed and all pending + output is flushed; avail_out must be large enough to hold all the + uncompressed data. (The size of the uncompressed data may have been saved + by the compressor for this purpose.) The next operation on this stream must + be inflateEnd to deallocate the decompression state. The use of Z_FINISH + is never required, but can be used to inform inflate that a faster approach + may be used for the single inflate() call. + + In this implementation, inflate() always flushes as much output as + possible to the output buffer, and always uses the faster approach on the + first call. So the only effect of the flush parameter in this implementation + is on the return value of inflate(), as noted below, or when it returns early + because Z_BLOCK is used. + + If a preset dictionary is needed after this call (see inflateSetDictionary + below), inflate sets strm-adler to the adler32 checksum of the dictionary + chosen by the compressor and returns Z_NEED_DICT; otherwise it sets + strm->adler to the adler32 checksum of all output produced so far (that is, + total_out bytes) and returns Z_OK, Z_STREAM_END or an error code as described + below. At the end of the stream, inflate() checks that its computed adler32 + checksum is equal to that saved by the compressor and returns Z_STREAM_END + only if the checksum is correct. + + inflate() will decompress and check either zlib-wrapped or gzip-wrapped + deflate data. The header type is detected automatically. Any information + contained in the gzip header is not retained, so applications that need that + information should instead use raw inflate, see inflateInit2() below, or + inflateBack() and perform their own processing of the gzip header and + trailer. + + inflate() returns Z_OK if some progress has been made (more input processed + or more output produced), Z_STREAM_END if the end of the compressed data has + been reached and all uncompressed output has been produced, Z_NEED_DICT if a + preset dictionary is needed at this point, Z_DATA_ERROR if the input data was + corrupted (input stream not conforming to the zlib format or incorrect check + value), Z_STREAM_ERROR if the stream structure was inconsistent (for example + if next_in or next_out was NULL), Z_MEM_ERROR if there was not enough memory, + Z_BUF_ERROR if no progress is possible or if there was not enough room in the + output buffer when Z_FINISH is used. Note that Z_BUF_ERROR is not fatal, and + inflate() can be called again with more input and more output space to + continue decompressing. If Z_DATA_ERROR is returned, the application may then + call inflateSync() to look for a good compression block if a partial recovery + of the data is desired. + */ + + + ZEXTERN int ZEXPORT inflateEnd OF((z_streamp strm)); + /* + All dynamically allocated data structures for this stream are freed. + This function discards any unprocessed input and does not flush any + pending output. + + inflateEnd returns Z_OK if success, Z_STREAM_ERROR if the stream state + was inconsistent. In the error case, msg may be set but then points to a + static string (which must not be deallocated). + */ + + /* Advanced functions */ + + /* + The following functions are needed only in some special applications. + */ + + /* + ZEXTERN int ZEXPORT deflateInit2 OF((z_streamp strm, + int level, + int method, + int windowBits, + int memLevel, + int strategy)); + + This is another version of deflateInit with more compression options. The + fields next_in, zalloc, zfree and opaque must be initialized before by + the caller. + + The method parameter is the compression method. It must be Z_DEFLATED in + this version of the library. + + The windowBits parameter is the base two logarithm of the window size + (the size of the history buffer). It should be in the range 8..15 for this + version of the library. Larger values of this parameter result in better + compression at the expense of memory usage. The default value is 15 if + deflateInit is used instead. + + windowBits can also be -8..-15 for raw deflate. In this case, -windowBits + determines the window size. deflate() will then generate raw deflate data + with no zlib header or trailer, and will not compute an adler32 check value. + + windowBits can also be greater than 15 for optional gzip encoding. Add + 16 to windowBits to write a simple gzip header and trailer around the + compressed data instead of a zlib wrapper. The gzip header will have no + file name, no extra data, no comment, no modification time (set to zero), + no header crc, and the operating system will be set to 255 (unknown). + + The memLevel parameter specifies how much memory should be allocated + for the internal compression state. memLevel=1 uses minimum memory but + is slow and reduces compression ratio; memLevel=9 uses maximum memory + for optimal speed. The default value is 8. See zconf.h for total memory + usage as a function of windowBits and memLevel. + + The strategy parameter is used to tune the compression algorithm. Use the + value Z_DEFAULT_STRATEGY for normal data, Z_FILTERED for data produced by a + filter (or predictor), Z_HUFFMAN_ONLY to force Huffman encoding only (no + string match), or Z_RLE to limit match distances to one (run-length + encoding). Filtered data consists mostly of small values with a somewhat + random distribution. In this case, the compression algorithm is tuned to + compress them better. The effect of Z_FILTERED is to force more Huffman + coding and less string matching; it is somewhat intermediate between + Z_DEFAULT and Z_HUFFMAN_ONLY. Z_RLE is designed to be almost as fast as + Z_HUFFMAN_ONLY, but give better compression for PNG image data. The strategy + parameter only affects the compression ratio but not the correctness of the + compressed output even if it is not set appropriately. + + deflateInit2 returns Z_OK if success, Z_MEM_ERROR if there was not enough + memory, Z_STREAM_ERROR if a parameter is invalid (such as an invalid + method). msg is set to null if there is no error message. deflateInit2 does + not perform any compression: this will be done by deflate(). + */ + + ZEXTERN int ZEXPORT deflateSetDictionary OF((z_streamp strm, + const Bytef *dictionary, + uInt dictLength)); + /* + Initializes the compression dictionary from the given byte sequence + without producing any compressed output. This function must be called + immediately after deflateInit, deflateInit2 or deflateReset, before any + call of deflate. The compressor and decompressor must use exactly the same + dictionary (see inflateSetDictionary). + + The dictionary should consist of strings (byte sequences) that are likely + to be encountered later in the data to be compressed, with the most commonly + used strings preferably put towards the end of the dictionary. Using a + dictionary is most useful when the data to be compressed is short and can be + predicted with good accuracy; the data can then be compressed better than + with the default empty dictionary. + + Depending on the size of the compression data structures selected by + deflateInit or deflateInit2, a part of the dictionary may in effect be + discarded, for example if the dictionary is larger than the window size in + deflate or deflate2. Thus the strings most likely to be useful should be + put at the end of the dictionary, not at the front. + + Upon return of this function, strm->adler is set to the adler32 value + of the dictionary; the decompressor may later use this value to determine + which dictionary has been used by the compressor. (The adler32 value + applies to the whole dictionary even if only a subset of the dictionary is + actually used by the compressor.) If a raw deflate was requested, then the + adler32 value is not computed and strm->adler is not set. + + deflateSetDictionary returns Z_OK if success, or Z_STREAM_ERROR if a + parameter is invalid (such as NULL dictionary) or the stream state is + inconsistent (for example if deflate has already been called for this stream + or if the compression method is bsort). deflateSetDictionary does not + perform any compression: this will be done by deflate(). + */ + + ZEXTERN int ZEXPORT deflateCopy OF((z_streamp dest, + z_streamp source)); + /* + Sets the destination stream as a complete copy of the source stream. + + This function can be useful when several compression strategies will be + tried, for example when there are several ways of pre-processing the input + data with a filter. The streams that will be discarded should then be freed + by calling deflateEnd. Note that deflateCopy duplicates the internal + compression state which can be quite large, so this strategy is slow and + can consume lots of memory. + + deflateCopy returns Z_OK if success, Z_MEM_ERROR if there was not + enough memory, Z_STREAM_ERROR if the source stream state was inconsistent + (such as zalloc being NULL). msg is left unchanged in both source and + destination. + */ + + ZEXTERN int ZEXPORT deflateReset OF((z_streamp strm)); + /* + This function is equivalent to deflateEnd followed by deflateInit, + but does not free and reallocate all the internal compression state. + The stream will keep the same compression level and any other attributes + that may have been set by deflateInit2. + + deflateReset returns Z_OK if success, or Z_STREAM_ERROR if the source + stream state was inconsistent (such as zalloc or state being NULL). + */ + + ZEXTERN int ZEXPORT deflateParams OF((z_streamp strm, + int level, + int strategy)); + /* + Dynamically update the compression level and compression strategy. The + interpretation of level and strategy is as in deflateInit2. This can be + used to switch between compression and straight copy of the input data, or + to switch to a different kind of input data requiring a different + strategy. If the compression level is changed, the input available so far + is compressed with the old level (and may be flushed); the new level will + take effect only at the next call of deflate(). + + Before the call of deflateParams, the stream state must be set as for + a call of deflate(), since the currently available input may have to + be compressed and flushed. In particular, strm->avail_out must be non-zero. + + deflateParams returns Z_OK if success, Z_STREAM_ERROR if the source + stream state was inconsistent or if a parameter was invalid, Z_BUF_ERROR + if strm->avail_out was zero. + */ + + ZEXTERN uLong ZEXPORT deflateBound OF((z_streamp strm, + uLong sourceLen)); + /* + deflateBound() returns an upper bound on the compressed size after + deflation of sourceLen bytes. It must be called after deflateInit() + or deflateInit2(). This would be used to allocate an output buffer + for deflation in a single pass, and so would be called before deflate(). + */ + + ZEXTERN int ZEXPORT deflatePrime OF((z_streamp strm, + int bits, + int value)); + /* + deflatePrime() inserts bits in the deflate output stream. The intent + is that this function is used to start off the deflate output with the + bits leftover from a previous deflate stream when appending to it. As such, + this function can only be used for raw deflate, and must be used before the + first deflate() call after a deflateInit2() or deflateReset(). bits must be + less than or equal to 16, and that many of the least significant bits of + value will be inserted in the output. + + deflatePrime returns Z_OK if success, or Z_STREAM_ERROR if the source + stream state was inconsistent. + */ + + /* + ZEXTERN int ZEXPORT inflateInit2 OF((z_streamp strm, + int windowBits)); + + This is another version of inflateInit with an extra parameter. The + fields next_in, avail_in, zalloc, zfree and opaque must be initialized + before by the caller. + + The windowBits parameter is the base two logarithm of the maximum window + size (the size of the history buffer). It should be in the range 8..15 for + this version of the library. The default value is 15 if inflateInit is used + instead. windowBits must be greater than or equal to the windowBits value + provided to deflateInit2() while compressing, or it must be equal to 15 if + deflateInit2() was not used. If a compressed stream with a larger window + size is given as input, inflate() will return with the error code + Z_DATA_ERROR instead of trying to allocate a larger window. + + windowBits can also be -8..-15 for raw inflate. In this case, -windowBits + determines the window size. inflate() will then process raw deflate data, + not looking for a zlib or gzip header, not generating a check value, and not + looking for any check values for comparison at the end of the stream. This + is for use with other formats that use the deflate compressed data format + such as zip. Those formats provide their own check values. If a custom + format is developed using the raw deflate format for compressed data, it is + recommended that a check value such as an adler32 or a crc32 be applied to + the uncompressed data as is done in the zlib, gzip, and zip formats. For + most applications, the zlib format should be used as is. Note that comments + above on the use in deflateInit2() applies to the magnitude of windowBits. + + windowBits can also be greater than 15 for optional gzip decoding. Add + 32 to windowBits to enable zlib and gzip decoding with automatic header + detection, or add 16 to decode only the gzip format (the zlib format will + return a Z_DATA_ERROR). + + inflateInit2 returns Z_OK if success, Z_MEM_ERROR if there was not enough + memory, Z_STREAM_ERROR if a parameter is invalid (such as a negative + memLevel). msg is set to null if there is no error message. inflateInit2 + does not perform any decompression apart from reading the zlib header if + present: this will be done by inflate(). (So next_in and avail_in may be + modified, but next_out and avail_out are unchanged.) + */ + + ZEXTERN int ZEXPORT inflateSetDictionary OF((z_streamp strm, + const Bytef *dictionary, + uInt dictLength)); + /* + Initializes the decompression dictionary from the given uncompressed byte + sequence. This function must be called immediately after a call of inflate + if this call returned Z_NEED_DICT. The dictionary chosen by the compressor + can be determined from the adler32 value returned by this call of + inflate. The compressor and decompressor must use exactly the same + dictionary (see deflateSetDictionary). + + inflateSetDictionary returns Z_OK if success, Z_STREAM_ERROR if a + parameter is invalid (such as NULL dictionary) or the stream state is + inconsistent, Z_DATA_ERROR if the given dictionary doesn't match the + expected one (incorrect adler32 value). inflateSetDictionary does not + perform any decompression: this will be done by subsequent calls of + inflate(). + */ + + ZEXTERN int ZEXPORT inflateSync OF((z_streamp strm)); + /* + Skips invalid compressed data until a full flush point (see above the + description of deflate with Z_FULL_FLUSH) can be found, or until all + available input is skipped. No output is provided. + + inflateSync returns Z_OK if a full flush point has been found, Z_BUF_ERROR + if no more input was provided, Z_DATA_ERROR if no flush point has been found, + or Z_STREAM_ERROR if the stream structure was inconsistent. In the success + case, the application may save the current current value of total_in which + indicates where valid compressed data was found. In the error case, the + application may repeatedly call inflateSync, providing more input each time, + until success or end of the input data. + */ + + ZEXTERN int ZEXPORT inflateCopy OF((z_streamp dest, + z_streamp source)); + /* + Sets the destination stream as a complete copy of the source stream. + + This function can be useful when randomly accessing a large stream. The + first pass through the stream can periodically record the inflate state, + allowing restarting inflate at those points when randomly accessing the + stream. + + inflateCopy returns Z_OK if success, Z_MEM_ERROR if there was not + enough memory, Z_STREAM_ERROR if the source stream state was inconsistent + (such as zalloc being NULL). msg is left unchanged in both source and + destination. + */ + + ZEXTERN int ZEXPORT inflateReset OF((z_streamp strm)); + /* + This function is equivalent to inflateEnd followed by inflateInit, + but does not free and reallocate all the internal decompression state. + The stream will keep attributes that may have been set by inflateInit2. + + inflateReset returns Z_OK if success, or Z_STREAM_ERROR if the source + stream state was inconsistent (such as zalloc or state being NULL). + */ + + /* + ZEXTERN int ZEXPORT inflateBackInit OF((z_stream FAR *strm, int windowBits, + unsigned char FAR *window)); + + Initialize the internal stream state for decompression using inflateBack() + calls. The fields zalloc, zfree and opaque in strm must be initialized + before the call. If zalloc and zfree are Z_NULL, then the default library- + derived memory allocation routines are used. windowBits is the base two + logarithm of the window size, in the range 8..15. window is a caller + supplied buffer of that size. Except for special applications where it is + assured that deflate was used with small window sizes, windowBits must be 15 + and a 32K byte window must be supplied to be able to decompress general + deflate streams. + + See inflateBack() for the usage of these routines. + + inflateBackInit will return Z_OK on success, Z_STREAM_ERROR if any of + the paramaters are invalid, Z_MEM_ERROR if the internal state could not + be allocated, or Z_VERSION_ERROR if the version of the library does not + match the version of the header file. + */ + + typedef unsigned (*in_func) OF((void FAR *, unsigned char FAR * FAR *)); + typedef int (*out_func) OF((void FAR *, unsigned char FAR *, unsigned)); + + ZEXTERN int ZEXPORT inflateBack OF((z_stream FAR *strm, + in_func in, void FAR *in_desc, + out_func out, void FAR *out_desc)); + /* + inflateBack() does a raw inflate with a single call using a call-back + interface for input and output. This is more efficient than inflate() for + file i/o applications in that it avoids copying between the output and the + sliding window by simply making the window itself the output buffer. This + function trusts the application to not change the output buffer passed by + the output function, at least until inflateBack() returns. + + inflateBackInit() must be called first to allocate the internal state + and to initialize the state with the user-provided window buffer. + inflateBack() may then be used multiple times to inflate a complete, raw + deflate stream with each call. inflateBackEnd() is then called to free + the allocated state. + + A raw deflate stream is one with no zlib or gzip header or trailer. + This routine would normally be used in a utility that reads zip or gzip + files and writes out uncompressed files. The utility would decode the + header and process the trailer on its own, hence this routine expects + only the raw deflate stream to decompress. This is different from the + normal behavior of inflate(), which expects either a zlib or gzip header and + trailer around the deflate stream. + + inflateBack() uses two subroutines supplied by the caller that are then + called by inflateBack() for input and output. inflateBack() calls those + routines until it reads a complete deflate stream and writes out all of the + uncompressed data, or until it encounters an error. The function's + parameters and return types are defined above in the in_func and out_func + typedefs. inflateBack() will call in(in_desc, &buf) which should return the + number of bytes of provided input, and a pointer to that input in buf. If + there is no input available, in() must return zero--buf is ignored in that + case--and inflateBack() will return a buffer error. inflateBack() will call + out(out_desc, buf, len) to write the uncompressed data buf[0..len-1]. out() + should return zero on success, or non-zero on failure. If out() returns + non-zero, inflateBack() will return with an error. Neither in() nor out() + are permitted to change the contents of the window provided to + inflateBackInit(), which is also the buffer that out() uses to write from. + The length written by out() will be at most the window size. Any non-zero + amount of input may be provided by in(). + + For convenience, inflateBack() can be provided input on the first call by + setting strm->next_in and strm->avail_in. If that input is exhausted, then + in() will be called. Therefore strm->next_in must be initialized before + calling inflateBack(). If strm->next_in is Z_NULL, then in() will be called + immediately for input. If strm->next_in is not Z_NULL, then strm->avail_in + must also be initialized, and then if strm->avail_in is not zero, input will + initially be taken from strm->next_in[0 .. strm->avail_in - 1]. + + The in_desc and out_desc parameters of inflateBack() is passed as the + first parameter of in() and out() respectively when they are called. These + descriptors can be optionally used to pass any information that the caller- + supplied in() and out() functions need to do their job. + + On return, inflateBack() will set strm->next_in and strm->avail_in to + pass back any unused input that was provided by the last in() call. The + return values of inflateBack() can be Z_STREAM_END on success, Z_BUF_ERROR + if in() or out() returned an error, Z_DATA_ERROR if there was a format + error in the deflate stream (in which case strm->msg is set to indicate the + nature of the error), or Z_STREAM_ERROR if the stream was not properly + initialized. In the case of Z_BUF_ERROR, an input or output error can be + distinguished using strm->next_in which will be Z_NULL only if in() returned + an error. If strm->next is not Z_NULL, then the Z_BUF_ERROR was due to + out() returning non-zero. (in() will always be called before out(), so + strm->next_in is assured to be defined if out() returns non-zero.) Note + that inflateBack() cannot return Z_OK. + */ + + ZEXTERN int ZEXPORT inflateBackEnd OF((z_stream FAR *strm)); + /* + All memory allocated by inflateBackInit() is freed. + + inflateBackEnd() returns Z_OK on success, or Z_STREAM_ERROR if the stream + state was inconsistent. + */ + + ZEXTERN uLong ZEXPORT zlibCompileFlags OF((void)); + /* Return flags indicating compile-time options. + + Type sizes, two bits each, 00 = 16 bits, 01 = 32, 10 = 64, 11 = other: + 1.0: size of uInt + 3.2: size of uLong + 5.4: size of voidpf (pointer) + 7.6: size of z_off_t + + Compiler, assembler, and debug options: + 8: DEBUG + 9: ASMV or ASMINF -- use ASM code + 10: ZLIB_WINAPI -- exported functions use the WINAPI calling convention + 11: 0 (reserved) + + One-time table building (smaller code, but not thread-safe if true): + 12: BUILDFIXED -- build static block decoding tables when needed + 13: DYNAMIC_CRC_TABLE -- build CRC calculation tables when needed + 14,15: 0 (reserved) + + Library content (indicates missing functionality): + 16: NO_GZCOMPRESS -- gz* functions cannot compress (to avoid linking + deflate code when not needed) + 17: NO_GZIP -- deflate can't write gzip streams, and inflate can't detect + and decode gzip streams (to avoid linking crc code) + 18-19: 0 (reserved) + + Operation variations (changes in library functionality): + 20: PKZIP_BUG_WORKAROUND -- slightly more permissive inflate + 21: FASTEST -- deflate algorithm with only one, lowest compression level + 22,23: 0 (reserved) + + The sprintf variant used by gzprintf (zero is best): + 24: 0 = vs*, 1 = s* -- 1 means limited to 20 arguments after the format + 25: 0 = *nprintf, 1 = *printf -- 1 means gzprintf() not secure! + 26: 0 = returns value, 1 = void -- 1 means inferred string length returned + + Remainder: + 27-31: 0 (reserved) + */ + + + /* utility functions */ + + /* + The following utility functions are implemented on top of the + basic stream-oriented functions. To simplify the interface, some + default options are assumed (compression level and memory usage, + standard memory allocation functions). The source code of these + utility functions can easily be modified if you need special options. + */ + + ZEXTERN int ZEXPORT compress OF((Bytef *dest, uLongf *destLen, + const Bytef *source, uLong sourceLen)); + /* + Compresses the source buffer into the destination buffer. sourceLen is + the byte length of the source buffer. Upon entry, destLen is the total + size of the destination buffer, which must be at least the value returned + by compressBound(sourceLen). Upon exit, destLen is the actual size of the + compressed buffer. + This function can be used to compress a whole file at once if the + input file is mmap'ed. + compress returns Z_OK if success, Z_MEM_ERROR if there was not + enough memory, Z_BUF_ERROR if there was not enough room in the output + buffer. + */ + + ZEXTERN int ZEXPORT compress2 OF((Bytef *dest, uLongf *destLen, + const Bytef *source, uLong sourceLen, + int level)); + /* + Compresses the source buffer into the destination buffer. The level + parameter has the same meaning as in deflateInit. sourceLen is the byte + length of the source buffer. Upon entry, destLen is the total size of the + destination buffer, which must be at least the value returned by + compressBound(sourceLen). Upon exit, destLen is the actual size of the + compressed buffer. + + compress2 returns Z_OK if success, Z_MEM_ERROR if there was not enough + memory, Z_BUF_ERROR if there was not enough room in the output buffer, + Z_STREAM_ERROR if the level parameter is invalid. + */ + + ZEXTERN uLong ZEXPORT compressBound OF((uLong sourceLen)); + /* + compressBound() returns an upper bound on the compressed size after + compress() or compress2() on sourceLen bytes. It would be used before + a compress() or compress2() call to allocate the destination buffer. + */ + + ZEXTERN int ZEXPORT uncompress OF((Bytef *dest, uLongf *destLen, + const Bytef *source, uLong sourceLen)); + /* + Decompresses the source buffer into the destination buffer. sourceLen is + the byte length of the source buffer. Upon entry, destLen is the total + size of the destination buffer, which must be large enough to hold the + entire uncompressed data. (The size of the uncompressed data must have + been saved previously by the compressor and transmitted to the decompressor + by some mechanism outside the scope of this compression library.) + Upon exit, destLen is the actual size of the compressed buffer. + This function can be used to decompress a whole file at once if the + input file is mmap'ed. + + uncompress returns Z_OK if success, Z_MEM_ERROR if there was not + enough memory, Z_BUF_ERROR if there was not enough room in the output + buffer, or Z_DATA_ERROR if the input data was corrupted or incomplete. + */ + + + typedef voidp gzFile; + + ZEXTERN gzFile ZEXPORT gzopen OF((const char *path, const char *mode)); + /* + Opens a gzip (.gz) file for reading or writing. The mode parameter + is as in fopen ("rb" or "wb") but can also include a compression level + ("wb9") or a strategy: 'f' for filtered data as in "wb6f", 'h' for + Huffman only compression as in "wb1h", or 'R' for run-length encoding + as in "wb1R". (See the description of deflateInit2 for more information + about the strategy parameter.) + + gzopen can be used to read a file which is not in gzip format; in this + case gzread will directly read from the file without decompression. + + gzopen returns NULL if the file could not be opened or if there was + insufficient memory to allocate the (de)compression state; errno + can be checked to distinguish the two cases (if errno is zero, the + zlib error is Z_MEM_ERROR). */ + + ZEXTERN gzFile ZEXPORT gzdopen OF((int fd, const char *mode)); + /* + gzdopen() associates a gzFile with the file descriptor fd. File + descriptors are obtained from calls like open, dup, creat, pipe or + fileno (in the file has been previously opened with fopen). + The mode parameter is as in gzopen. + The next call of gzclose on the returned gzFile will also close the + file descriptor fd, just like fclose(fdopen(fd), mode) closes the file + descriptor fd. If you want to keep fd open, use gzdopen(dup(fd), mode). + gzdopen returns NULL if there was insufficient memory to allocate + the (de)compression state. + */ + + ZEXTERN int ZEXPORT gzsetparams OF((gzFile file, int level, int strategy)); + /* + Dynamically update the compression level or strategy. See the description + of deflateInit2 for the meaning of these parameters. + gzsetparams returns Z_OK if success, or Z_STREAM_ERROR if the file was not + opened for writing. + */ + + ZEXTERN int ZEXPORT gzread OF((gzFile file, voidp buf, unsigned len)); + /* + Reads the given number of uncompressed bytes from the compressed file. + If the input file was not in gzip format, gzread copies the given number + of bytes into the buffer. + gzread returns the number of uncompressed bytes actually read (0 for + end of file, -1 for error). */ + + ZEXTERN int ZEXPORT gzwrite OF((gzFile file, + voidpc buf, unsigned len)); + /* + Writes the given number of uncompressed bytes into the compressed file. + gzwrite returns the number of uncompressed bytes actually written + (0 in case of error). + */ + + ZEXTERN int ZEXPORTVA gzprintf OF((gzFile file, const char *format, ...)); + /* + Converts, formats, and writes the args to the compressed file under + control of the format string, as in fprintf. gzprintf returns the number of + uncompressed bytes actually written (0 in case of error). The number of + uncompressed bytes written is limited to 4095. The caller should assure that + this limit is not exceeded. If it is exceeded, then gzprintf() will return + return an error (0) with nothing written. In this case, there may also be a + buffer overflow with unpredictable consequences, which is possible only if + zlib was compiled with the insecure functions sprintf() or vsprintf() + because the secure snprintf() or vsnprintf() functions were not available. + */ + + ZEXTERN int ZEXPORT gzputs OF((gzFile file, const char *s)); + /* + Writes the given null-terminated string to the compressed file, excluding + the terminating null character. + gzputs returns the number of characters written, or -1 in case of error. + */ + + ZEXTERN char * ZEXPORT gzgets OF((gzFile file, char *buf, int len)); + /* + Reads bytes from the compressed file until len-1 characters are read, or + a newline character is read and transferred to buf, or an end-of-file + condition is encountered. The string is then terminated with a null + character. + gzgets returns buf, or Z_NULL in case of error. + */ + + ZEXTERN int ZEXPORT gzputc OF((gzFile file, int c)); + /* + Writes c, converted to an unsigned char, into the compressed file. + gzputc returns the value that was written, or -1 in case of error. + */ + + ZEXTERN int ZEXPORT gzgetc OF((gzFile file)); + /* + Reads one byte from the compressed file. gzgetc returns this byte + or -1 in case of end of file or error. + */ + + ZEXTERN int ZEXPORT gzungetc OF((int c, gzFile file)); + /* + Push one character back onto the stream to be read again later. + Only one character of push-back is allowed. gzungetc() returns the + character pushed, or -1 on failure. gzungetc() will fail if a + character has been pushed but not read yet, or if c is -1. The pushed + character will be discarded if the stream is repositioned with gzseek() + or gzrewind(). + */ + + ZEXTERN int ZEXPORT gzflush OF((gzFile file, int flush)); + /* + Flushes all pending output into the compressed file. The parameter + flush is as in the deflate() function. The return value is the zlib + error number (see function gzerror below). gzflush returns Z_OK if + the flush parameter is Z_FINISH and all output could be flushed. + gzflush should be called only when strictly necessary because it can + degrade compression. + */ + + ZEXTERN z_off_t ZEXPORT gzseek OF((gzFile file, + z_off_t offset, int whence)); + /* + Sets the starting position for the next gzread or gzwrite on the + given compressed file. The offset represents a number of bytes in the + uncompressed data stream. The whence parameter is defined as in lseek(2); + the value SEEK_END is not supported. + If the file is opened for reading, this function is emulated but can be + extremely slow. If the file is opened for writing, only forward seeks are + supported; gzseek then compresses a sequence of zeroes up to the new + starting position. + + gzseek returns the resulting offset location as measured in bytes from + the beginning of the uncompressed stream, or -1 in case of error, in + particular if the file is opened for writing and the new starting position + would be before the current position. + */ + + ZEXTERN int ZEXPORT gzrewind OF((gzFile file)); + /* + Rewinds the given file. This function is supported only for reading. + + gzrewind(file) is equivalent to (int)gzseek(file, 0L, SEEK_SET) + */ + + ZEXTERN z_off_t ZEXPORT gztell OF((gzFile file)); + /* + Returns the starting position for the next gzread or gzwrite on the + given compressed file. This position represents a number of bytes in the + uncompressed data stream. + + gztell(file) is equivalent to gzseek(file, 0L, SEEK_CUR) + */ + + ZEXTERN int ZEXPORT gzeof OF((gzFile file)); + /* + Returns 1 when EOF has previously been detected reading the given + input stream, otherwise zero. + */ + + ZEXTERN int ZEXPORT gzclose OF((gzFile file)); + /* + Flushes all pending output if necessary, closes the compressed file + and deallocates all the (de)compression state. The return value is the zlib + error number (see function gzerror below). + */ + + ZEXTERN const char * ZEXPORT gzerror OF((gzFile file, int *errnum)); + /* + Returns the error message for the last error which occurred on the + given compressed file. errnum is set to zlib error number. If an + error occurred in the file system and not in the compression library, + errnum is set to Z_ERRNO and the application may consult errno + to get the exact error code. + */ + + ZEXTERN void ZEXPORT gzclearerr OF((gzFile file)); + /* + Clears the error and end-of-file flags for file. This is analogous to the + clearerr() function in stdio. This is useful for continuing to read a gzip + file that is being written concurrently. + */ + + /* checksum functions */ + + /* + These functions are not related to compression but are exported + anyway because they might be useful in applications using the + compression library. + */ + + ZEXTERN uLong ZEXPORT adler32 OF((uLong adler, const Bytef *buf, uInt len)); + + /* + Update a running Adler-32 checksum with the bytes buf[0..len-1] and + return the updated checksum. If buf is NULL, this function returns + the required initial value for the checksum. + An Adler-32 checksum is almost as reliable as a CRC32 but can be computed + much faster. Usage example: + + uLong adler = adler32(0L, Z_NULL, 0); + + while (read_buffer(buffer, length) != EOF) { + adler = adler32(adler, buffer, length); + } + if (adler != original_adler) error(); + */ + + ZEXTERN uLong ZEXPORT crc32 OF((uLong crc, const Bytef *buf, uInt len)); + /* + Update a running crc with the bytes buf[0..len-1] and return the updated + crc. If buf is NULL, this function returns the required initial value + for the crc. Pre- and post-conditioning (one's complement) is performed + within this function so it shouldn't be done by the application. + Usage example: + + uLong crc = crc32(0L, Z_NULL, 0); + + while (read_buffer(buffer, length) != EOF) { + crc = crc32(crc, buffer, length); + } + if (crc != original_crc) error(); + */ + + + /* various hacks, don't look :) */ + + /* deflateInit and inflateInit are macros to allow checking the zlib version + * and the compiler's view of z_stream: + */ + ZEXTERN int ZEXPORT deflateInit_ OF((z_streamp strm, int level, + const char *version, int stream_size)); + ZEXTERN int ZEXPORT inflateInit_ OF((z_streamp strm, + const char *version, int stream_size)); + ZEXTERN int ZEXPORT deflateInit2_ OF((z_streamp strm, int level, int method, + int windowBits, int memLevel, + int strategy, const char *version, + int stream_size)); + ZEXTERN int ZEXPORT inflateInit2_ OF((z_streamp strm, int windowBits, + const char *version, int stream_size)); + ZEXTERN int ZEXPORT inflateBackInit_ OF((z_stream FAR *strm, int windowBits, + unsigned char FAR *window, + const char *version, + int stream_size)); + #define deflateInit(strm, level) \ + deflateInit_((strm), (level), ZLIB_VERSION, sizeof(z_stream)) + #define inflateInit(strm) \ + inflateInit_((strm), ZLIB_VERSION, sizeof(z_stream)) + #define deflateInit2(strm, level, method, windowBits, memLevel, strategy) \ + deflateInit2_((strm),(level),(method),(windowBits),(memLevel),\ + (strategy), ZLIB_VERSION, sizeof(z_stream)) + #define inflateInit2(strm, windowBits) \ + inflateInit2_((strm), (windowBits), ZLIB_VERSION, sizeof(z_stream)) + #define inflateBackInit(strm, windowBits, window) \ + inflateBackInit_((strm), (windowBits), (window), \ + ZLIB_VERSION, sizeof(z_stream)) + + + #if !defined(ZUTIL_H) && !defined(NO_DUMMY_DECL) + struct internal_state {int dummy;}; /* hack for buggy compilers */ + #endif + + ZEXTERN const char * ZEXPORT zError OF((int err)); + ZEXTERN int ZEXPORT inflateSyncPoint OF((z_streamp z)); + ZEXTERN const uLongf * ZEXPORT get_crc_table OF((void)); + + #ifdef __cplusplus + } + #endif + + #endif /* ZLIB_H */ Index: llvm-test/Runtime/zlib/zutil.c diff -c /dev/null llvm-test/Runtime/zlib/zutil.c:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/zutil.c Mon Dec 6 15:19:40 2004 *************** *** 0 **** --- 1,319 ---- + /* zutil.c -- target dependent utility functions for the compression library + * Copyright (C) 1995-2003 Jean-loup Gailly. + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* @(#) $Id: zutil.c,v 1.1 2004/12/06 21:19:40 criswell Exp $ */ + + #include "zutil.h" + + #ifndef NO_DUMMY_DECL + struct internal_state {int dummy;}; /* for buggy compilers */ + #endif + + #ifndef STDC + extern void exit OF((int)); + #endif + + const char * const z_errmsg[10] = { + "need dictionary", /* Z_NEED_DICT 2 */ + "stream end", /* Z_STREAM_END 1 */ + "", /* Z_OK 0 */ + "file error", /* Z_ERRNO (-1) */ + "stream error", /* Z_STREAM_ERROR (-2) */ + "data error", /* Z_DATA_ERROR (-3) */ + "insufficient memory", /* Z_MEM_ERROR (-4) */ + "buffer error", /* Z_BUF_ERROR (-5) */ + "incompatible version",/* Z_VERSION_ERROR (-6) */ + ""}; + + + const char * ZEXPORT zlibVersion() + { + return ZLIB_VERSION; + } + + uLong ZEXPORT zlibCompileFlags() + { + uLong flags; + + flags = 0; + switch (sizeof(uInt)) { + case 2: break; + case 4: flags += 1; break; + case 8: flags += 2; break; + default: flags += 3; + } + switch (sizeof(uLong)) { + case 2: break; + case 4: flags += 1 << 2; break; + case 8: flags += 2 << 2; break; + default: flags += 3 << 2; + } + switch (sizeof(voidpf)) { + case 2: break; + case 4: flags += 1 << 4; break; + case 8: flags += 2 << 4; break; + default: flags += 3 << 4; + } + switch (sizeof(z_off_t)) { + case 2: break; + case 4: flags += 1 << 6; break; + case 8: flags += 2 << 6; break; + default: flags += 3 << 6; + } + #ifdef DEBUG + flags += 1 << 8; + #endif + #if defined(ASMV) || defined(ASMINF) + flags += 1 << 9; + #endif + #ifdef ZLIB_WINAPI + flags += 1 << 10; + #endif + #ifdef BUILDFIXED + flags += 1 << 12; + #endif + #ifdef DYNAMIC_CRC_TABLE + flags += 1 << 13; + #endif + #ifdef NO_GZCOMPRESS + flags += 1 << 16; + #endif + #ifdef NO_GZIP + flags += 1 << 17; + #endif + #ifdef PKZIP_BUG_WORKAROUND + flags += 1 << 20; + #endif + #ifdef FASTEST + flags += 1 << 21; + #endif + #ifdef STDC + # ifdef NO_vsnprintf + flags += 1 << 25; + # ifdef HAS_vsprintf_void + flags += 1 << 26; + # endif + # else + # ifdef HAS_vsnprintf_void + flags += 1 << 26; + # endif + # endif + #else + flags += 1 << 24; + # ifdef NO_snprintf + flags += 1 << 25; + # ifdef HAS_sprintf_void + flags += 1 << 26; + # endif + # else + # ifdef HAS_snprintf_void + flags += 1 << 26; + # endif + # endif + #endif + return flags; + } + + #ifdef DEBUG + + # ifndef verbose + # define verbose 0 + # endif + int z_verbose = verbose; + + void z_error (m) + char *m; + { + fprintf(stderr, "%s\n", m); + exit(1); + } + #endif + + /* exported to allow conversion of error code to string for compress() and + * uncompress() + */ + const char * ZEXPORT zError(err) + int err; + { + return ERR_MSG(err); + } + + #if defined(_WIN32_WCE) + /* does not exist on WCE */ + int errno = 0; + #endif + + #ifndef HAVE_MEMCPY + + void zmemcpy(dest, source, len) + Bytef* dest; + const Bytef* source; + uInt len; + { + if (len == 0) return; + do { + *dest++ = *source++; /* ??? to be unrolled */ + } while (--len != 0); + } + + int zmemcmp(s1, s2, len) + const Bytef* s1; + const Bytef* s2; + uInt len; + { + uInt j; + + for (j = 0; j < len; j++) { + if (s1[j] != s2[j]) return 2*(s1[j] > s2[j])-1; + } + return 0; + } + + void zmemzero(dest, len) + Bytef* dest; + uInt len; + { + if (len == 0) return; + do { + *dest++ = 0; /* ??? to be unrolled */ + } while (--len != 0); + } + #endif + + + #ifdef SYS16BIT + + #ifdef __TURBOC__ + /* Turbo C in 16-bit mode */ + + # define MY_ZCALLOC + + /* Turbo C malloc() does not allow dynamic allocation of 64K bytes + * and farmalloc(64K) returns a pointer with an offset of 8, so we + * must fix the pointer. Warning: the pointer must be put back to its + * original form in order to free it, use zcfree(). + */ + + #define MAX_PTR 10 + /* 10*64K = 640K */ + + local int next_ptr = 0; + + typedef struct ptr_table_s { + voidpf org_ptr; + voidpf new_ptr; + } ptr_table; + + local ptr_table table[MAX_PTR]; + /* This table is used to remember the original form of pointers + * to large buffers (64K). Such pointers are normalized with a zero offset. + * Since MSDOS is not a preemptive multitasking OS, this table is not + * protected from concurrent access. This hack doesn't work anyway on + * a protected system like OS/2. Use Microsoft C instead. + */ + + voidpf zcalloc (voidpf opaque, unsigned items, unsigned size) + { + voidpf buf = opaque; /* just to make some compilers happy */ + ulg bsize = (ulg)items*size; + + /* If we allocate less than 65520 bytes, we assume that farmalloc + * will return a usable pointer which doesn't have to be normalized. + */ + if (bsize < 65520L) { + buf = farmalloc(bsize); + if (*(ush*)&buf != 0) return buf; + } else { + buf = farmalloc(bsize + 16L); + } + if (buf == NULL || next_ptr >= MAX_PTR) return NULL; + table[next_ptr].org_ptr = buf; + + /* Normalize the pointer to seg:0 */ + *((ush*)&buf+1) += ((ush)((uch*)buf-0) + 15) >> 4; + *(ush*)&buf = 0; + table[next_ptr++].new_ptr = buf; + return buf; + } + + void zcfree (voidpf opaque, voidpf ptr) + { + int n; + if (*(ush*)&ptr != 0) { /* object < 64K */ + farfree(ptr); + return; + } + /* Find the original pointer */ + for (n = 0; n < next_ptr; n++) { + if (ptr != table[n].new_ptr) continue; + + farfree(table[n].org_ptr); + while (++n < next_ptr) { + table[n-1] = table[n]; + } + next_ptr--; + return; + } + ptr = opaque; /* just to make some compilers happy */ + Assert(0, "zcfree: ptr not found"); + } + + #endif /* __TURBOC__ */ + + + #ifdef M_I86 + /* Microsoft C in 16-bit mode */ + + # define MY_ZCALLOC + + #if (!defined(_MSC_VER) || (_MSC_VER <= 600)) + # define _halloc halloc + # define _hfree hfree + #endif + + voidpf zcalloc (voidpf opaque, unsigned items, unsigned size) + { + if (opaque) opaque = 0; /* to make compiler happy */ + return _halloc((long)items, size); + } + + void zcfree (voidpf opaque, voidpf ptr) + { + if (opaque) opaque = 0; /* to make compiler happy */ + _hfree(ptr); + } + + #endif /* M_I86 */ + + #endif /* SYS16BIT */ + + + #ifndef MY_ZCALLOC /* Any system without a special alloc function */ + + #ifndef STDC + extern voidp malloc OF((uInt size)); + extern voidp calloc OF((uInt items, uInt size)); + extern void free OF((voidpf ptr)); + #endif + + voidpf zcalloc (opaque, items, size) + voidpf opaque; + unsigned items; + unsigned size; + { + if (opaque) items += size - size; /* make compiler happy */ + return sizeof(uInt) > 2 ? (voidpf)malloc(items * size) : + (voidpf)calloc(items, size); + } + + void zcfree (opaque, ptr) + voidpf opaque; + voidpf ptr; + { + free(ptr); + if (opaque) return; /* make compiler happy */ + } + + #endif /* MY_ZCALLOC */ Index: llvm-test/Runtime/zlib/zutil.h diff -c /dev/null llvm-test/Runtime/zlib/zutil.h:1.1 *** /dev/null Mon Dec 6 15:19:56 2004 --- llvm-test/Runtime/zlib/zutil.h Mon Dec 6 15:19:40 2004 *************** *** 0 **** --- 1,258 ---- + /* zutil.h -- internal interface and configuration of the compression library + * Copyright (C) 1995-2003 Jean-loup Gailly. + * For conditions of distribution and use, see copyright notice in zlib.h + */ + + /* WARNING: this file should *not* be used by applications. It is + part of the implementation of the compression library and is + subject to change. Applications should only use zlib.h. + */ + + /* @(#) $Id: zutil.h,v 1.1 2004/12/06 21:19:40 criswell Exp $ */ + + #ifndef ZUTIL_H + #define ZUTIL_H + + #define ZLIB_INTERNAL + #include "zlib.h" + + #ifdef STDC + # include + # include + # include + #endif + #ifdef NO_ERRNO_H + extern int errno; + #else + # include + #endif + + #ifndef local + # define local static + #endif + /* compile with -Dlocal if your debugger can't find static symbols */ + + typedef unsigned char uch; + typedef uch FAR uchf; + typedef unsigned short ush; + typedef ush FAR ushf; + typedef unsigned long ulg; + + extern const char * const z_errmsg[10]; /* indexed by 2-zlib_error */ + /* (size given to avoid silly warnings with Visual C++) */ + + #define ERR_MSG(err) z_errmsg[Z_NEED_DICT-(err)] + + #define ERR_RETURN(strm,err) \ + return (strm->msg = (char*)ERR_MSG(err), (err)) + /* To be used only when the state is known to be valid */ + + /* common constants */ + + #ifndef DEF_WBITS + # define DEF_WBITS MAX_WBITS + #endif + /* default windowBits for decompression. MAX_WBITS is for compression only */ + + #if MAX_MEM_LEVEL >= 8 + # define DEF_MEM_LEVEL 8 + #else + # define DEF_MEM_LEVEL MAX_MEM_LEVEL + #endif + /* default memLevel */ + + #define STORED_BLOCK 0 + #define STATIC_TREES 1 + #define DYN_TREES 2 + /* The three kinds of block type */ + + #define MIN_MATCH 3 + #define MAX_MATCH 258 + /* The minimum and maximum match lengths */ + + #define PRESET_DICT 0x20 /* preset dictionary flag in zlib header */ + + /* target dependencies */ + + #if defined(MSDOS) || (defined(WINDOWS) && !defined(WIN32)) + # define OS_CODE 0x00 + # if defined(__TURBOC__) || defined(__BORLANDC__) + # if(__STDC__ == 1) && (defined(__LARGE__) || defined(__COMPACT__)) + /* Allow compilation with ANSI keywords only enabled */ + void _Cdecl farfree( void *block ); + void *_Cdecl farmalloc( unsigned long nbytes ); + # else + # include + # endif + # else /* MSC or DJGPP */ + # include + # endif + #endif + + #ifdef AMIGA + # define OS_CODE 0x01 + #endif + + #if defined(VAXC) || defined(VMS) + # define OS_CODE 0x02 + # define F_OPEN(name, mode) \ + fopen((name), (mode), "mbc=60", "ctx=stm", "rfm=fix", "mrs=512") + #endif + + #if defined(ATARI) || defined(atarist) + # define OS_CODE 0x05 + #endif + + #ifdef OS2 + # define OS_CODE 0x06 + #endif + + #if defined(MACOS) || defined(TARGET_OS_MAC) + # define OS_CODE 0x07 + # if defined(__MWERKS__) && __dest_os != __be_os && __dest_os != __win32_os + # include /* for fdopen */ + # else + # ifndef fdopen + # define fdopen(fd,mode) NULL /* No fdopen() */ + # endif + # endif + #endif + + #ifdef TOPS20 + # define OS_CODE 0x0a + #endif + + #ifdef WIN32 + # ifndef __CYGWIN__ /* Cygwin is Unix, not Win32 */ + # define OS_CODE 0x0b + # endif + #endif + + #ifdef __50SERIES /* Prime/PRIMOS */ + # define OS_CODE 0x0f + #endif + + #if defined(_BEOS_) || defined(RISCOS) + # define fdopen(fd,mode) NULL /* No fdopen() */ + #endif + + #if (defined(_MSC_VER) && (_MSC_VER > 600)) + # if defined(_WIN32_WCE) + # define fdopen(fd,mode) NULL /* No fdopen() */ + # ifndef _PTRDIFF_T_DEFINED + typedef int ptrdiff_t; + # define _PTRDIFF_T_DEFINED + # endif + # else + # define fdopen(fd,type) _fdopen(fd,type) + # endif + #endif + + /* common defaults */ + + #ifndef OS_CODE + # define OS_CODE 0x03 /* assume Unix */ + #endif + + #ifndef F_OPEN + # define F_OPEN(name, mode) fopen((name), (mode)) + #endif + + /* functions */ + + #if defined(STDC99) || (defined(__TURBOC__) && __TURBOC__ >= 0x550) + # ifndef HAVE_VSNPRINTF + # define HAVE_VSNPRINTF + # endif + #endif + #if defined(__CYGWIN__) + # ifndef HAVE_VSNPRINTF + # define HAVE_VSNPRINTF + # endif + #endif + #ifndef HAVE_VSNPRINTF + # ifdef MSDOS + /* vsnprintf may exist on some MS-DOS compilers (DJGPP?), + but for now we just assume it doesn't. */ + # define NO_vsnprintf + # endif + # ifdef __TURBOC__ + # define NO_vsnprintf + # endif + # ifdef WIN32 + /* In Win32, vsnprintf is available as the "non-ANSI" _vsnprintf. */ + # if !defined(vsnprintf) && !defined(NO_vsnprintf) + # define vsnprintf _vsnprintf + # endif + # endif + # ifdef __SASC + # define NO_vsnprintf + # endif + #endif + + #ifdef HAVE_STRERROR + extern char *strerror OF((int)); + # define zstrerror(errnum) strerror(errnum) + #else + # define zstrerror(errnum) "" + #endif + + #if defined(pyr) + # define NO_MEMCPY + #endif + #if defined(SMALL_MEDIUM) && !defined(_MSC_VER) && !defined(__SC__) + /* Use our own functions for small and medium model with MSC <= 5.0. + * You may have to use the same strategy for Borland C (untested). + * The __SC__ check is for Symantec. + */ + # define NO_MEMCPY + #endif + #if defined(STDC) && !defined(HAVE_MEMCPY) && !defined(NO_MEMCPY) + # define HAVE_MEMCPY + #endif + #ifdef HAVE_MEMCPY + # ifdef SMALL_MEDIUM /* MSDOS small or medium model */ + # define zmemcpy _fmemcpy + # define zmemcmp _fmemcmp + # define zmemzero(dest, len) _fmemset(dest, 0, len) + # else + # define zmemcpy memcpy + # define zmemcmp memcmp + # define zmemzero(dest, len) memset(dest, 0, len) + # endif + #else + extern void zmemcpy OF((Bytef* dest, const Bytef* source, uInt len)); + extern int zmemcmp OF((const Bytef* s1, const Bytef* s2, uInt len)); + extern void zmemzero OF((Bytef* dest, uInt len)); + #endif + + /* Diagnostic functions */ + #ifdef DEBUG + # include + extern int z_verbose; + extern void z_error OF((char *m)); + # define Assert(cond,msg) {if(!(cond)) z_error(msg);} + # define Trace(x) {if (z_verbose>=0) fprintf x ;} + # define Tracev(x) {if (z_verbose>0) fprintf x ;} + # define Tracevv(x) {if (z_verbose>1) fprintf x ;} + # define Tracec(c,x) {if (z_verbose>0 && (c)) fprintf x ;} + # define Tracecv(c,x) {if (z_verbose>1 && (c)) fprintf x ;} + #else + # define Assert(cond,msg) + # define Trace(x) + # define Tracev(x) + # define Tracevv(x) + # define Tracec(c,x) + # define Tracecv(c,x) + #endif + + + voidpf zcalloc OF((voidpf opaque, unsigned items, unsigned size)); + void zcfree OF((voidpf opaque, voidpf ptr)); + + #define ZALLOC(strm, items, size) \ + (*((strm)->zalloc))((strm)->opaque, (items), (size)) + #define ZFREE(strm, addr) (*((strm)->zfree))((strm)->opaque, (voidpf)(addr)) + #define TRY_FREE(s, p) {if (p) ZFREE(s, p);} + + #endif /* ZUTIL_H */ From criswell at cs.uiuc.edu Mon Dec 6 15:21:42 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:21:42 -0600 Subject: [llvm-commits] CVS: llvm-test/Makefile Message-ID: <200412062121.PAA21776@choi.cs.uiuc.edu> Changes in directory llvm-test: Makefile updated: 1.25 -> 1.26 --- Log message: Build any needed libraries before running any tests. --- Diffs of the changes: (+1 -0) Index: llvm-test/Makefile diff -u llvm-test/Makefile:1.25 llvm-test/Makefile:1.26 --- llvm-test/Makefile:1.25 Mon Sep 6 22:25:02 2004 +++ llvm-test/Makefile Mon Dec 6 15:21:30 2004 @@ -13,6 +13,7 @@ ##===----------------------------------------------------------------------===## LEVEL = . +DIRS = Runtime PARALLEL_DIRS = SingleSource MultiSource External include $(LEVEL)/Makefile.programs From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/untgz/ Message-ID: <200412062118.PAA21593@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/untgz: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/untgz added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:18:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:18:26 -0600 Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/iostream/ Message-ID: <200412062118.PAA21566@choi.cs.uiuc.edu> Changes in directory llvm-test/Runtime/zlib/contrib/iostream: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-test/Runtime/zlib/contrib/iostream added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Mon Dec 6 15:35:47 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:35:47 -0600 Subject: [llvm-commits] CVS: llvm/test/Makefile Message-ID: <200412062135.PAA21947@choi.cs.uiuc.edu> Changes in directory llvm/test: Makefile updated: 1.75 -> 1.76 --- Log message: Remove the last pieces of QMTest. --- Diffs of the changes: (+0 -94) Index: llvm/test/Makefile diff -u llvm/test/Makefile:1.75 llvm/test/Makefile:1.76 --- llvm/test/Makefile:1.75 Sun Dec 5 23:35:38 2004 +++ llvm/test/Makefile Mon Dec 6 15:35:32 2004 @@ -18,100 +18,6 @@ # Include other test rules include Makefile.tests -# New QMTest functionality: -# The test suite is being transitioned over to QMTest. Eventually, it -# will use QMTest by default. - -# QMTest option specifying the location of the QMTest database. -QMDB= -D $(LLVM_SRC_ROOT)/test -QMCLASSES=$(LLVM_OBJ_ROOT)/test/QMTest - -# -# Determine which expectations file we will use -# -QMEXPECT:=$(LLVM_SRC_ROOT)/test/QMTest/expectations.unknown.qmr -ifeq ($(OS),Linux) -QMEXPECT:=$(LLVM_SRC_ROOT)/test/QMTest/expectations.linux.qmr -endif - -ifeq ($(OS),SunOS) -QMEXPECT:=$(LLVM_SRC_ROOT)/test/QMTest/expectations.sunos.qmr -endif - -ifeq ($(OS),Darwin) -QMEXPECT:=$(LLVM_SRC_ROOT)/test/QMTest/expectations.darwin.qmr -endif - -# -# This is configuration information used by the test suite. In QM Test, it's -# called a 'context.' -# -CONTEXT= -c "srcroot=$(LLVM_SRC_ROOT)" \ - -c "buildroot=$(LLVM_OBJ_ROOT)" \ - -c "buildtype=$(BuildMode)" \ - -c "tmpdir=$(LLVM_OBJ_ROOT)/test/tmp" \ - -c "coresize=0" \ - -c "cc=$(CC)" \ - -c "cxx=$(CXX)" \ - -c "llvmgcc=$(LLVMGCC)" \ - -c "llvmgxx=$(LLVMGXX)" \ - -c "make=$(MAKE)" \ - -c "python=$(PYTHON)" - -# -# Location of the QMTest program. -# -QMTEST= QMTEST_CLASS_PATH=$(QMCLASSES) qmtest $(QMDB) - - -# -# Execute the tests -# -qmtest:: $(LLVM_OBJ_ROOT)/test/tmp register - -$(QMTEST) run -O $(QMEXPECT) $(CONTEXT) - -%.t:: $(LLVM_OBJ_ROOT)/test/tmp register - -$(QMTEST) run -O $(QMEXPECT) $(CONTEXT) $* - -# -# Create the temporary directory used by the test suite. -# -$(LLVM_OBJ_ROOT)/test/tmp:: - ${MKDIR} $(LLVM_OBJ_ROOT)/test/tmp - -# -# Right now, QMTest compiles the python test classes and put them into the -# source tree. Since Python bytecode is *not* cross-platform compatible (I -# think), we'll regenerate every time. -# -# Simultaneous builds won't work, but shared source trees will. -# -register: - $(QMTEST) register test llvm.TestAsmDisasm - $(QMTEST) register test llvm.AssembleTest - $(QMTEST) register test llvm.ConvertToCTest - $(QMTEST) register test llvm.LLToCTest - $(QMTEST) register test llvm.MachineCodeTest - $(QMTEST) register test llvm.TestOptimizer - $(QMTEST) register test llvm.LLITest - $(QMTEST) register test llvm.TestRunner - $(QMTEST) register test llvm.VerifierTest - $(QMTEST) register test llvm.CTest - $(QMTEST) register test llvm.CXXTest - $(QMTEST) register database llvmdb.llvmdb - -# Start up the QMTest GUI -gui:: - $(QMTEST) gui --no-browser --daemon - -# Also get rid of qmtest garbage when we 'make clean' in this directory. -qmtest-clean: - $(RM) -rf $(LLVM_OBJ_ROOT)/test/tmp - $(RM) -f $(LLVM_SRC_ROOT)/test/QMTest/*.pyo \ - $(LLVM_OBJ_ROOT)/test/QMTest/*.pyo - $(RM) -f $(LLVM_SRC_ROOT)/test/results.qmr \ - $(LLVM_OBJ_ROOT)/test/results.qmr - #===------------------------------------------------------------------------===# # DejaGNU testing support #===------------------------------------------------------------------------===# From criswell at cs.uiuc.edu Mon Dec 6 15:36:47 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 15:36:47 -0600 Subject: [llvm-commits] [ROOT_RELEASE_14] CVS: llvm/test/QMTest/configuration expectations.darwin.qmr expectations.linux.qmr expectations.sunos.qmr expectations.unknown.qmr llvm.py llvmdb.py Message-ID: <200412062136.PAA21976@choi.cs.uiuc.edu> Changes in directory llvm/test/QMTest: configuration (r1.1) removed expectations.darwin.qmr (r1.6) removed expectations.linux.qmr (r1.12) removed expectations.sunos.qmr (r1.13) removed expectations.unknown.qmr (r1.7) removed llvm.py (r1.32) removed llvmdb.py (r1.15) removed --- Log message: Remove QMTest items. --- Diffs of the changes: (+0 -0) From reid at x10sys.com Mon Dec 6 15:58:10 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 15:58:10 -0600 Subject: [llvm-commits] CVS: llvm/test/Regression/Assembler/2004-12-06-ConstantFloatRange.ll Message-ID: <200412062158.PAA03613@zion.cs.uiuc.edu> Changes in directory llvm/test/Regression/Assembler: 2004-12-06-ConstantFloatRange.ll added (r1.1) --- Log message: Test case for PR409: http://llvm.cs.uiuc.edu/PR409 : Make sure that floating point constant values outside the range of a float cannot be assigned to a constant. --- Diffs of the changes: (+10 -0) Index: llvm/test/Regression/Assembler/2004-12-06-ConstantFloatRange.ll diff -c /dev/null llvm/test/Regression/Assembler/2004-12-06-ConstantFloatRange.ll:1.1 *** /dev/null Mon Dec 6 15:58:09 2004 --- llvm/test/Regression/Assembler/2004-12-06-ConstantFloatRange.ll Mon Dec 6 15:57:59 2004 *************** *** 0 **** --- 1,10 ---- + ; RUN: llvm-as %s -o /dev/null 2>&1 | grep "constant invalid for type" + + ; make sure that 'float' values are in range + + %D1 = constant double 3.40282347e+39 + %D2 = constant double -3.40282347e+39 + %F1 = constant float 3.40282346e+38 + %F2 = constant float -3.40282346e+38 + %D1 = constant float 3.40282347e+39 + %D2 = constant float -3.40282347e+39 From criswell at cs.uiuc.edu Mon Dec 6 16:05:16 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 6 Dec 2004 16:05:16 -0600 Subject: [llvm-commits] CVS: llvm/test/Regression/Debugger/funccall.ll Message-ID: <200412062205.QAA22133@choi.cs.uiuc.edu> Changes in directory llvm/test/Regression/Debugger: funccall.ll updated: 1.7 -> 1.8 --- Log message: This test still fails on Darwin and Sparc/Solaris. --- Diffs of the changes: (+1 -0) Index: llvm/test/Regression/Debugger/funccall.ll diff -u llvm/test/Regression/Debugger/funccall.ll:1.7 llvm/test/Regression/Debugger/funccall.ll:1.8 --- llvm/test/Regression/Debugger/funccall.ll:1.7 Sat Dec 4 17:44:42 2004 +++ llvm/test/Regression/Debugger/funccall.ll Mon Dec 6 16:05:02 2004 @@ -1,3 +1,4 @@ +;; XFAIL: darwin,sun ;; RUN: echo create > %t.commands ;; RUN: echo s >> %t.commands ;; RUN: echo s >> %t.commands From reid at x10sys.com Mon Dec 6 16:18:36 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 16:18:36 -0600 Subject: [llvm-commits] CVS: llvm/lib/AsmParser/llvmAsmParser.y Message-ID: <200412062218.QAA03883@zion.cs.uiuc.edu> Changes in directory llvm/lib/AsmParser: llvmAsmParser.y updated: 1.207 -> 1.208 --- Log message: For PR409: http://llvm.cs.uiuc.edu/PR409 : \ Make sure to check isValueValidForType on floating point constants and give \ an error if the value is not valid, otherwise it would assert in the VMCore --- Diffs of the changes: (+2 -0) Index: llvm/lib/AsmParser/llvmAsmParser.y diff -u llvm/lib/AsmParser/llvmAsmParser.y:1.207 llvm/lib/AsmParser/llvmAsmParser.y:1.208 --- llvm/lib/AsmParser/llvmAsmParser.y:1.207 Sun Nov 28 10:45:45 2004 +++ llvm/lib/AsmParser/llvmAsmParser.y Mon Dec 6 16:18:25 2004 @@ -1318,6 +1318,8 @@ $$ = ConstantBool::False; } | FPType FPVAL { // Float & Double constants + if (!ConstantFP::isValueValidForType($1, $2)) + ThrowException("Floating point constant invalid for type!!"); $$ = ConstantFP::get($1, $2); }; From reid at x10sys.com Mon Dec 6 16:18:48 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 16:18:48 -0600 Subject: [llvm-commits] CVS: llvm/lib/VMCore/Constants.cpp Message-ID: <200412062218.QAA03894@zion.cs.uiuc.edu> Changes in directory llvm/lib/VMCore: Constants.cpp updated: 1.112 -> 1.113 --- Log message: For PR409: http://llvm.cs.uiuc.edu/PR409 : \ Test the range of float constants to ensure we are not attempting to create a \ float constant using a double value that is out of range for a float --- Diffs of the changes: (+11 -0) Index: llvm/lib/VMCore/Constants.cpp diff -u llvm/lib/VMCore/Constants.cpp:1.112 llvm/lib/VMCore/Constants.cpp:1.113 --- llvm/lib/VMCore/Constants.cpp:1.112 Fri Nov 19 10:39:44 2004 +++ llvm/lib/VMCore/Constants.cpp Mon Dec 6 16:18:37 2004 @@ -21,6 +21,7 @@ #include "llvm/ADT/StringExtras.h" #include #include +#include using namespace llvm; ConstantBool *ConstantBool::True = new ConstantBool(true); @@ -442,6 +443,16 @@ // TODO: Figure out how to test if a double can be cast to a float! case Type::FloatTyID: + return + (std::numeric_limits::has_infinity && + std::numeric_limits::has_infinity && + Val == std::numeric_limits::infinity()) || + (std::numeric_limits::has_quiet_NaN && + std::numeric_limits::has_quiet_NaN && + Val == std::numeric_limits::quiet_NaN()) || + (Val >= -std::numeric_limits::max() && + Val <= std::numeric_limits::max()); + case Type::DoubleTyID: return true; // This is the largest type... } From reid at x10sys.com Mon Dec 6 16:32:44 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 16:32:44 -0600 Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200412062232.QAA04073@zion.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.274 -> 1.275 --- Log message: PR409: http://llvm.cs.uiuc.edu/PR409 fixed. --- Diffs of the changes: (+4 -1) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.274 llvm/docs/ReleaseNotes.html:1.275 --- llvm/docs/ReleaseNotes.html:1.274 Sun Dec 5 14:19:45 2004 +++ llvm/docs/ReleaseNotes.html Mon Dec 6 16:32:33 2004 @@ -187,6 +187,9 @@

      +
    1. + [core/asmparser] ConstantFP::isValueValidForType Broken +
    2. [llvmg++] Tons of warnings are spewed when linking to libstdc++
      3. @@ -736,7 +739,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/12/05 20:19:45 $ + Last modified: $Date: 2004/12/06 22:32:33 $ From alkis at cs.uiuc.edu Mon Dec 6 17:40:08 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Mon, 6 Dec 2004 17:40:08 -0600 Subject: [llvm-commits] CVS: llvm-java/test/Programs/SingleSource/UnitTests/InstanceOf.java Message-ID: <200412062340.RAA04922@zion.cs.uiuc.edu> Changes in directory llvm-java/test/Programs/SingleSource/UnitTests: InstanceOf.java updated: 1.3 -> 1.4 --- Log message: Clean up test a bit. --- Diffs of the changes: (+12 -7) Index: llvm-java/test/Programs/SingleSource/UnitTests/InstanceOf.java diff -u llvm-java/test/Programs/SingleSource/UnitTests/InstanceOf.java:1.3 llvm-java/test/Programs/SingleSource/UnitTests/InstanceOf.java:1.4 --- llvm-java/test/Programs/SingleSource/UnitTests/InstanceOf.java:1.3 Sun Dec 5 17:31:23 2004 +++ llvm-java/test/Programs/SingleSource/UnitTests/InstanceOf.java Mon Dec 6 17:39:58 2004 @@ -4,30 +4,35 @@ int bar() { return 0; } } -interface InstanceOfInterface { +interface InstanceOfInterface +{ public int baz(); } -public class InstanceOf extends InstanceOfBase implements InstanceOfInterface +class InstanceOfDerived extends InstanceOfBase implements InstanceOfInterface { int foo() { return 1; } public int baz() { return foo(); } +} + +public class InstanceOf +{ public static void main(String[] args) { InstanceOfBase aa = new InstanceOfBase(); - InstanceOfBase ab = new InstanceOf(); - InstanceOfInterface bb = new InstanceOf(); + InstanceOfBase ab = new InstanceOfDerived(); + InstanceOfInterface bb = new InstanceOfDerived(); Test.print_boolean_ln(aa instanceof InstanceOfBase); - Test.print_boolean_ln(aa instanceof InstanceOf); + Test.print_boolean_ln(aa instanceof InstanceOfDerived); Test.print_boolean_ln(aa instanceof InstanceOfInterface); Test.print_boolean_ln(ab instanceof InstanceOfBase); - Test.print_boolean_ln(ab instanceof InstanceOf); + Test.print_boolean_ln(ab instanceof InstanceOfDerived); Test.print_boolean_ln(ab instanceof InstanceOfInterface); Test.print_boolean_ln(bb instanceof InstanceOfBase); - Test.print_boolean_ln(bb instanceof InstanceOf); + Test.print_boolean_ln(bb instanceof InstanceOfDerived); Test.print_boolean_ln(bb instanceof InstanceOfInterface); } } From reid at x10sys.com Mon Dec 6 17:42:48 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 17:42:48 -0600 Subject: [llvm-commits] CVS: llvm/utils/TableGen/Record.h Message-ID: <200412062342.RAA04987@zion.cs.uiuc.edu> Changes in directory llvm/utils/TableGen: Record.h updated: 1.43 -> 1.44 --- Log message: For PR387: http://llvm.cs.uiuc.edu/PR387 : Make this compile without warning when -Woverloaded-virtual is used. --- Diffs of the changes: (+174 -43) Index: llvm/utils/TableGen/Record.h diff -u llvm/utils/TableGen/Record.h:1.43 llvm/utils/TableGen/Record.h:1.44 --- llvm/utils/TableGen/Record.h:1.43 Wed Oct 27 11:06:28 2004 +++ llvm/utils/TableGen/Record.h Mon Dec 6 17:42:37 2004 @@ -109,21 +109,34 @@ /// class BitRecTy : public RecTy { public: - Init *convertValue(UnsetInit *UI) { return (Init*)UI; } - Init *convertValue(BitInit *BI) { return (Init*)BI; } - Init *convertValue(BitsInit *BI); - Init *convertValue(IntInit *II); - Init *convertValue(TypedInit *VI); - Init *convertValue(VarBitInit *VB) { return (Init*)VB; } + virtual Init *convertValue( UnsetInit *UI) { return (Init*)UI; } + virtual Init *convertValue( BitInit *BI) { return (Init*)BI; } + virtual Init *convertValue( BitsInit *BI); + virtual Init *convertValue( IntInit *II); + virtual Init *convertValue(StringInit *SI) { return 0; } + virtual Init *convertValue( ListInit *LI) { return 0; } + virtual Init *convertValue( CodeInit *CI) { return 0; } + virtual Init *convertValue(VarBitInit *VB) { return (Init*)VB; } + virtual Init *convertValue( DefInit *DI) { return 0; } + virtual Init *convertValue( DagInit *DI) { return 0; } + virtual Init *convertValue( TypedInit *TI); + virtual Init *convertValue( VarInit *VI) { return RecTy::convertValue(VI);} + virtual Init *convertValue( FieldInit *FI) { return RecTy::convertValue(FI);} void print(std::ostream &OS) const { OS << "bit"; } bool typeIsConvertibleTo(const RecTy *RHS) const { return RHS->baseClassOf(this); } - virtual bool baseClassOf(const BitRecTy *RHS) const { return true; } - virtual bool baseClassOf(const BitsRecTy *RHS) const; - virtual bool baseClassOf(const IntRecTy *RHS) const { return true; } + virtual bool baseClassOf(const BitRecTy *RHS) const { return true; } + virtual bool baseClassOf(const BitsRecTy *RHS) const; + virtual bool baseClassOf(const IntRecTy *RHS) const { return true; } + virtual bool baseClassOf(const StringRecTy *RHS) const { return false; } + virtual bool baseClassOf(const ListRecTy *RHS) const { return false; } + virtual bool baseClassOf(const CodeRecTy *RHS) const { return false; } + virtual bool baseClassOf(const DagRecTy *RHS) const { return false; } + virtual bool baseClassOf(const RecordRecTy *RHS) const { return false; } + }; @@ -137,22 +150,37 @@ unsigned getNumBits() const { return Size; } - Init *convertValue(UnsetInit *UI); - Init *convertValue(BitInit *UI); - Init *convertValue(BitsInit *BI); - Init *convertValue(IntInit *II); - Init *convertValue(TypedInit *VI); + virtual Init *convertValue( UnsetInit *UI); + virtual Init *convertValue( BitInit *UI); + virtual Init *convertValue( BitsInit *BI); + virtual Init *convertValue( IntInit *II); + virtual Init *convertValue(StringInit *SI) { return 0; } + virtual Init *convertValue( ListInit *LI) { return 0; } + virtual Init *convertValue( CodeInit *CI) { return 0; } + virtual Init *convertValue(VarBitInit *VB) { return 0; } + virtual Init *convertValue( DefInit *DI) { return 0; } + virtual Init *convertValue( DagInit *DI) { return 0; } + virtual Init *convertValue( TypedInit *TI); + virtual Init *convertValue( VarInit *VI) { return RecTy::convertValue(VI);} + virtual Init *convertValue( FieldInit *FI) { return RecTy::convertValue(FI);} + void print(std::ostream &OS) const { OS << "bits<" << Size << ">"; } bool typeIsConvertibleTo(const RecTy *RHS) const { return RHS->baseClassOf(this); } - virtual bool baseClassOf(const BitRecTy *RHS) const { return Size == 1; } - virtual bool baseClassOf(const IntRecTy *RHS) const { return true; } - virtual bool baseClassOf(const BitsRecTy *RHS) const { + virtual bool baseClassOf(const BitRecTy *RHS) const { return Size == 1; } + virtual bool baseClassOf(const BitsRecTy *RHS) const { return RHS->Size == Size; } + virtual bool baseClassOf(const IntRecTy *RHS) const { return true; } + virtual bool baseClassOf(const StringRecTy *RHS) const { return false; } + virtual bool baseClassOf(const ListRecTy *RHS) const { return false; } + virtual bool baseClassOf(const CodeRecTy *RHS) const { return false; } + virtual bool baseClassOf(const DagRecTy *RHS) const { return false; } + virtual bool baseClassOf(const RecordRecTy *RHS) const { return false; } + }; @@ -160,11 +188,20 @@ /// class IntRecTy : public RecTy { public: - Init *convertValue(UnsetInit *UI) { return (Init*)UI; } - Init *convertValue(IntInit *II) { return (Init*)II; } - Init *convertValue(BitInit *BI); - Init *convertValue(BitsInit *BI); - Init *convertValue(TypedInit *TI); + virtual Init *convertValue( UnsetInit *UI) { return (Init*)UI; } + virtual Init *convertValue( BitInit *BI); + virtual Init *convertValue( BitsInit *BI); + virtual Init *convertValue( IntInit *II) { return (Init*)II; } + virtual Init *convertValue(StringInit *SI) { return 0; } + virtual Init *convertValue( ListInit *LI) { return 0; } + virtual Init *convertValue( CodeInit *CI) { return 0; } + virtual Init *convertValue(VarBitInit *VB) { return 0; } + virtual Init *convertValue( DefInit *DI) { return 0; } + virtual Init *convertValue( DagInit *DI) { return 0; } + virtual Init *convertValue( TypedInit *TI); + virtual Init *convertValue( VarInit *VI) { return RecTy::convertValue(VI);} + virtual Init *convertValue( FieldInit *FI) { return RecTy::convertValue(FI);} + void print(std::ostream &OS) const { OS << "int"; } @@ -172,25 +209,49 @@ return RHS->baseClassOf(this); } - virtual bool baseClassOf(const BitRecTy *RHS) const { return true; } - virtual bool baseClassOf(const IntRecTy *RHS) const { return true; } - virtual bool baseClassOf(const BitsRecTy *RHS) const { return true; } + virtual bool baseClassOf(const BitRecTy *RHS) const { return true; } + virtual bool baseClassOf(const BitsRecTy *RHS) const { return true; } + virtual bool baseClassOf(const IntRecTy *RHS) const { return true; } + virtual bool baseClassOf(const StringRecTy *RHS) const { return false; } + virtual bool baseClassOf(const ListRecTy *RHS) const { return false; } + virtual bool baseClassOf(const CodeRecTy *RHS) const { return false; } + virtual bool baseClassOf(const DagRecTy *RHS) const { return false; } + virtual bool baseClassOf(const RecordRecTy *RHS) const { return false; } + }; /// StringRecTy - 'string' - Represent an string value /// class StringRecTy : public RecTy { public: - Init *convertValue(UnsetInit *UI) { return (Init*)UI; } - Init *convertValue(StringInit *SI) { return (Init*)SI; } - Init *convertValue(TypedInit *TI); + virtual Init *convertValue( UnsetInit *UI) { return (Init*)UI; } + virtual Init *convertValue( BitInit *BI) { return 0; } + virtual Init *convertValue( BitsInit *BI) { return 0; } + virtual Init *convertValue( IntInit *II) { return 0; } + virtual Init *convertValue(StringInit *SI) { return (Init*)SI; } + virtual Init *convertValue( ListInit *LI) { return 0; } + virtual Init *convertValue( CodeInit *CI) { return 0; } + virtual Init *convertValue(VarBitInit *VB) { return 0; } + virtual Init *convertValue( DefInit *DI) { return 0; } + virtual Init *convertValue( DagInit *DI) { return 0; } + virtual Init *convertValue( TypedInit *TI); + virtual Init *convertValue( VarInit *VI) { return RecTy::convertValue(VI);} + virtual Init *convertValue( FieldInit *FI) { return RecTy::convertValue(FI);} + void print(std::ostream &OS) const { OS << "string"; } bool typeIsConvertibleTo(const RecTy *RHS) const { return RHS->baseClassOf(this); } + virtual bool baseClassOf(const BitRecTy *RHS) const { return false; } + virtual bool baseClassOf(const BitsRecTy *RHS) const { return false; } + virtual bool baseClassOf(const IntRecTy *RHS) const { return false; } virtual bool baseClassOf(const StringRecTy *RHS) const { return true; } + virtual bool baseClassOf(const ListRecTy *RHS) const { return false; } + virtual bool baseClassOf(const CodeRecTy *RHS) const { return false; } + virtual bool baseClassOf(const DagRecTy *RHS) const { return false; } + virtual bool baseClassOf(const RecordRecTy *RHS) const { return false; } }; // ListRecTy - 'list' - Represent a list of values, all of which must be of @@ -205,9 +266,19 @@ RecTy *getElementType() const { return Ty; } - Init *convertValue(UnsetInit *UI) { return (Init*)UI; } - Init *convertValue(ListInit *LI); - Init *convertValue(TypedInit *TI); + virtual Init *convertValue( UnsetInit *UI) { return (Init*)UI; } + virtual Init *convertValue( BitInit *BI) { return 0; } + virtual Init *convertValue( BitsInit *BI) { return 0; } + virtual Init *convertValue( IntInit *II) { return 0; } + virtual Init *convertValue(StringInit *SI) { return 0; } + virtual Init *convertValue( ListInit *LI); + virtual Init *convertValue( CodeInit *CI) { return 0; } + virtual Init *convertValue(VarBitInit *VB) { return 0; } + virtual Init *convertValue( DefInit *DI) { return 0; } + virtual Init *convertValue( DagInit *DI) { return 0; } + virtual Init *convertValue( TypedInit *TI); + virtual Init *convertValue( VarInit *VI) { return RecTy::convertValue(VI);} + virtual Init *convertValue( FieldInit *FI) { return RecTy::convertValue(FI);} void print(std::ostream &OS) const; @@ -215,41 +286,84 @@ return RHS->baseClassOf(this); } - virtual bool baseClassOf(const ListRecTy *RHS) const { + virtual bool baseClassOf(const BitRecTy *RHS) const { return false; } + virtual bool baseClassOf(const BitsRecTy *RHS) const { return false; } + virtual bool baseClassOf(const IntRecTy *RHS) const { return false; } + virtual bool baseClassOf(const StringRecTy *RHS) const { return false; } + virtual bool baseClassOf(const ListRecTy *RHS) const { return RHS->getElementType()->typeIsConvertibleTo(Ty); } + virtual bool baseClassOf(const CodeRecTy *RHS) const { return false; } + virtual bool baseClassOf(const DagRecTy *RHS) const { return false; } + virtual bool baseClassOf(const RecordRecTy *RHS) const { return false; } }; /// CodeRecTy - 'code' - Represent an code fragment, function or method. /// class CodeRecTy : public RecTy { public: - Init *convertValue(UnsetInit *UI) { return (Init*)UI; } - Init *convertValue( CodeInit *CI) { return (Init*)CI; } - Init *convertValue(TypedInit *TI); + virtual Init *convertValue( UnsetInit *UI) { return (Init*)UI; } + virtual Init *convertValue( BitInit *BI) { return 0; } + virtual Init *convertValue( BitsInit *BI) { return 0; } + virtual Init *convertValue( IntInit *II) { return 0; } + virtual Init *convertValue(StringInit *SI) { return 0; } + virtual Init *convertValue( ListInit *LI) { return 0; } + virtual Init *convertValue( CodeInit *CI) { return (Init*)CI; } + virtual Init *convertValue(VarBitInit *VB) { return 0; } + virtual Init *convertValue( DefInit *DI) { return 0; } + virtual Init *convertValue( DagInit *DI) { return 0; } + virtual Init *convertValue( TypedInit *TI); + virtual Init *convertValue( VarInit *VI) { return RecTy::convertValue(VI);} + virtual Init *convertValue( FieldInit *FI) { return RecTy::convertValue(FI);} + void print(std::ostream &OS) const { OS << "code"; } bool typeIsConvertibleTo(const RecTy *RHS) const { return RHS->baseClassOf(this); } - virtual bool baseClassOf(const CodeRecTy *RHS) const { return true; } + virtual bool baseClassOf(const BitRecTy *RHS) const { return false; } + virtual bool baseClassOf(const BitsRecTy *RHS) const { return false; } + virtual bool baseClassOf(const IntRecTy *RHS) const { return false; } + virtual bool baseClassOf(const StringRecTy *RHS) const { return false; } + virtual bool baseClassOf(const ListRecTy *RHS) const { return false; } + virtual bool baseClassOf(const CodeRecTy *RHS) const { return true; } + virtual bool baseClassOf(const DagRecTy *RHS) const { return false; } + virtual bool baseClassOf(const RecordRecTy *RHS) const { return false; } }; /// DagRecTy - 'dag' - Represent a dag fragment /// class DagRecTy : public RecTy { public: - Init *convertValue(UnsetInit *UI) { return (Init*)UI; } - Init *convertValue( DagInit *CI) { return (Init*)CI; } - Init *convertValue(TypedInit *TI); + virtual Init *convertValue( UnsetInit *UI) { return (Init*)UI; } + virtual Init *convertValue( BitInit *BI) { return 0; } + virtual Init *convertValue( BitsInit *BI) { return 0; } + virtual Init *convertValue( IntInit *II) { return 0; } + virtual Init *convertValue(StringInit *SI) { return 0; } + virtual Init *convertValue( ListInit *LI) { return 0; } + virtual Init *convertValue( CodeInit *CI) { return 0; } + virtual Init *convertValue(VarBitInit *VB) { return 0; } + virtual Init *convertValue( DefInit *DI) { return 0; } + virtual Init *convertValue( DagInit *CI) { return (Init*)CI; } + virtual Init *convertValue( TypedInit *TI); + virtual Init *convertValue( VarInit *VI) { return RecTy::convertValue(VI);} + virtual Init *convertValue( FieldInit *FI) { return RecTy::convertValue(FI);} void print(std::ostream &OS) const { OS << "dag"; } bool typeIsConvertibleTo(const RecTy *RHS) const { return RHS->baseClassOf(this); } - virtual bool baseClassOf(const DagRecTy *RHS) const { return true; } + + virtual bool baseClassOf(const BitRecTy *RHS) const { return false; } + virtual bool baseClassOf(const BitsRecTy *RHS) const { return false; } + virtual bool baseClassOf(const IntRecTy *RHS) const { return false; } + virtual bool baseClassOf(const StringRecTy *RHS) const { return false; } + virtual bool baseClassOf(const ListRecTy *RHS) const { return false; } + virtual bool baseClassOf(const CodeRecTy *RHS) const { return false; } + virtual bool baseClassOf(const DagRecTy *RHS) const { return true; } + virtual bool baseClassOf(const RecordRecTy *RHS) const { return false; } }; @@ -263,15 +377,32 @@ Record *getRecord() const { return Rec; } - Init *convertValue(UnsetInit *UI) { return (Init*)UI; } - Init *convertValue( DefInit *DI); - Init *convertValue(TypedInit *VI); + virtual Init *convertValue( UnsetInit *UI) { return (Init*)UI; } + virtual Init *convertValue( BitInit *BI) { return 0; } + virtual Init *convertValue( BitsInit *BI) { return 0; } + virtual Init *convertValue( IntInit *II) { return 0; } + virtual Init *convertValue(StringInit *SI) { return 0; } + virtual Init *convertValue( ListInit *LI) { return 0; } + virtual Init *convertValue( CodeInit *CI) { return 0; } + virtual Init *convertValue(VarBitInit *VB) { return 0; } + virtual Init *convertValue( DefInit *DI); + virtual Init *convertValue( DagInit *DI) { return 0; } + virtual Init *convertValue( TypedInit *VI); + virtual Init *convertValue( VarInit *VI) { return RecTy::convertValue(VI);} + virtual Init *convertValue( FieldInit *FI) { return RecTy::convertValue(FI);} void print(std::ostream &OS) const; bool typeIsConvertibleTo(const RecTy *RHS) const { return RHS->baseClassOf(this); } + virtual bool baseClassOf(const BitRecTy *RHS) const { return false; } + virtual bool baseClassOf(const BitsRecTy *RHS) const { return false; } + virtual bool baseClassOf(const IntRecTy *RHS) const { return false; } + virtual bool baseClassOf(const StringRecTy *RHS) const { return false; } + virtual bool baseClassOf(const ListRecTy *RHS) const { return false; } + virtual bool baseClassOf(const CodeRecTy *RHS) const { return false; } + virtual bool baseClassOf(const DagRecTy *RHS) const { return false; } virtual bool baseClassOf(const RecordRecTy *RHS) const; }; From reid at x10sys.com Mon Dec 6 22:03:57 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 22:03:57 -0600 Subject: [llvm-commits] CVS: llvm/lib/Analysis/DataStructure/DataStructureStats.cpp IPModRef.cpp IPModRef.h MemoryDepAnalysis.cpp MemoryDepAnalysis.h PgmDependenceGraph.cpp PgmDependenceGraph.h Message-ID: <200412070403.WAA07765@zion.cs.uiuc.edu> Changes in directory llvm/lib/Analysis/DataStructure: DataStructureStats.cpp updated: 1.14 -> 1.15 IPModRef.cpp updated: 1.27 -> 1.28 IPModRef.h updated: 1.3 -> 1.4 MemoryDepAnalysis.cpp updated: 1.19 -> 1.20 MemoryDepAnalysis.h updated: 1.4 -> 1.5 PgmDependenceGraph.cpp updated: 1.7 -> 1.8 PgmDependenceGraph.h updated: 1.5 -> 1.6 --- Log message: For PR387: http://llvm.cs.uiuc.edu/PR387 :\ Make only one print method to avoid overloaded virtual warnings when \ compiled with -Woverloaded-virtual --- Diffs of the changes: (+7 -7) Index: llvm/lib/Analysis/DataStructure/DataStructureStats.cpp diff -u llvm/lib/Analysis/DataStructure/DataStructureStats.cpp:1.14 llvm/lib/Analysis/DataStructure/DataStructureStats.cpp:1.15 --- llvm/lib/Analysis/DataStructure/DataStructureStats.cpp:1.14 Wed Sep 1 17:55:35 2004 +++ llvm/lib/Analysis/DataStructure/DataStructureStats.cpp Mon Dec 6 22:03:45 2004 @@ -57,7 +57,7 @@ void visitStore(StoreInst &SI); /// Debugging support methods - void print(std::ostream &O) const { } + void print(std::ostream &O, const Module* = 0) const { } }; static RegisterAnalysis Z("dsstats", "DS Graph Statistics"); Index: llvm/lib/Analysis/DataStructure/IPModRef.cpp diff -u llvm/lib/Analysis/DataStructure/IPModRef.cpp:1.27 llvm/lib/Analysis/DataStructure/IPModRef.cpp:1.28 --- llvm/lib/Analysis/DataStructure/IPModRef.cpp:1.27 Sun Sep 19 23:45:25 2004 +++ llvm/lib/Analysis/DataStructure/IPModRef.cpp Mon Dec 6 22:03:45 2004 @@ -424,7 +424,7 @@ } -void IPModRef::print(std::ostream &O) const +void IPModRef::print(std::ostream &O, const Module*) const { O << "\nRESULTS OF INTERPROCEDURAL MOD/REF ANALYSIS:\n\n"; Index: llvm/lib/Analysis/DataStructure/IPModRef.h diff -u llvm/lib/Analysis/DataStructure/IPModRef.h:1.3 llvm/lib/Analysis/DataStructure/IPModRef.h:1.4 --- llvm/lib/Analysis/DataStructure/IPModRef.h:1.3 Sun Sep 19 23:45:25 2004 +++ llvm/lib/Analysis/DataStructure/IPModRef.h Mon Dec 6 22:03:45 2004 @@ -213,7 +213,7 @@ // Debugging support methods // - void print(std::ostream &O) const; + void print(std::ostream &O, const Module* = 0) const; void dump() const; /// releaseMemory - Release memory held by this pass when the pass pipeline is Index: llvm/lib/Analysis/DataStructure/MemoryDepAnalysis.cpp diff -u llvm/lib/Analysis/DataStructure/MemoryDepAnalysis.cpp:1.19 llvm/lib/Analysis/DataStructure/MemoryDepAnalysis.cpp:1.20 --- llvm/lib/Analysis/DataStructure/MemoryDepAnalysis.cpp:1.19 Sun Sep 19 23:45:25 2004 +++ llvm/lib/Analysis/DataStructure/MemoryDepAnalysis.cpp Mon Dec 6 22:03:45 2004 @@ -405,7 +405,7 @@ /// Debugging support methods /// -void MemoryDepAnalysis::print(std::ostream &O) const +void MemoryDepAnalysis::print(std::ostream &O, const Module*) const { // TEMPORARY LOOP for (hash_map::const_iterator Index: llvm/lib/Analysis/DataStructure/MemoryDepAnalysis.h diff -u llvm/lib/Analysis/DataStructure/MemoryDepAnalysis.h:1.4 llvm/lib/Analysis/DataStructure/MemoryDepAnalysis.h:1.5 --- llvm/lib/Analysis/DataStructure/MemoryDepAnalysis.h:1.4 Sun Sep 19 23:45:25 2004 +++ llvm/lib/Analysis/DataStructure/MemoryDepAnalysis.h Mon Dec 6 22:03:45 2004 @@ -94,7 +94,7 @@ /// Debugging support methods /// - void print(std::ostream &O) const; + void print(std::ostream &O, const Module* = 0) const; void dump() const; }; Index: llvm/lib/Analysis/DataStructure/PgmDependenceGraph.cpp diff -u llvm/lib/Analysis/DataStructure/PgmDependenceGraph.cpp:1.7 llvm/lib/Analysis/DataStructure/PgmDependenceGraph.cpp:1.8 --- llvm/lib/Analysis/DataStructure/PgmDependenceGraph.cpp:1.7 Sun Jul 4 07:19:55 2004 +++ llvm/lib/Analysis/DataStructure/PgmDependenceGraph.cpp Mon Dec 6 22:03:45 2004 @@ -222,7 +222,7 @@ } -void PgmDependenceGraph::print(std::ostream &O) const +void PgmDependenceGraph::print(std::ostream &O, const Module*) const { MemoryDepAnalysis& graphSet = getAnalysis(); Index: llvm/lib/Analysis/DataStructure/PgmDependenceGraph.h diff -u llvm/lib/Analysis/DataStructure/PgmDependenceGraph.h:1.5 llvm/lib/Analysis/DataStructure/PgmDependenceGraph.h:1.6 --- llvm/lib/Analysis/DataStructure/PgmDependenceGraph.h:1.5 Sun Sep 19 23:45:25 2004 +++ llvm/lib/Analysis/DataStructure/PgmDependenceGraph.h Mon Dec 6 22:03:45 2004 @@ -292,7 +292,7 @@ /// Debugging support methods /// - void print(std::ostream &O) const; + void print(std::ostream &O, const Module* = 0) const; void dump() const; }; From reid at x10sys.com Mon Dec 6 22:03:57 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 22:03:57 -0600 Subject: [llvm-commits] CVS: llvm/include/llvm/Pass.h Message-ID: <200412070403.WAA07764@zion.cs.uiuc.edu> Changes in directory llvm/include/llvm: Pass.h updated: 1.47 -> 1.48 --- Log message: For PR387: http://llvm.cs.uiuc.edu/PR387 :\ Make only one print method to avoid overloaded virtual warnings when \ compiled with -Woverloaded-virtual --- Diffs of the changes: (+1 -2) Index: llvm/include/llvm/Pass.h diff -u llvm/include/llvm/Pass.h:1.47 llvm/include/llvm/Pass.h:1.48 --- llvm/include/llvm/Pass.h:1.47 Wed Oct 27 11:14:47 2004 +++ llvm/include/llvm/Pass.h Mon Dec 6 22:03:44 2004 @@ -96,8 +96,7 @@ /// provide the Module* in case the analysis doesn't need it it can just be /// ignored. /// - virtual void print(std::ostream &O, const Module *M) const { print(O); } - virtual void print(std::ostream &O) const; + virtual void print(std::ostream &O, const Module *M) const; void dump() const; // dump - call print(std::cerr, 0); From reid at x10sys.com Mon Dec 6 22:03:57 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 22:03:57 -0600 Subject: [llvm-commits] CVS: llvm/lib/Analysis/AliasSetTracker.cpp CFGPrinter.cpp IntervalPartition.cpp LoopInfo.cpp ScalarEvolution.cpp Message-ID: <200412070403.WAA07763@zion.cs.uiuc.edu> Changes in directory llvm/lib/Analysis: AliasSetTracker.cpp updated: 1.31 -> 1.32 CFGPrinter.cpp updated: 1.10 -> 1.11 IntervalPartition.cpp updated: 1.26 -> 1.27 LoopInfo.cpp updated: 1.60 -> 1.61 ScalarEvolution.cpp updated: 1.29 -> 1.30 --- Log message: For PR387: http://llvm.cs.uiuc.edu/PR387 :\ Make only one print method to avoid overloaded virtual warnings when \ compiled with -Woverloaded-virtual --- Diffs of the changes: (+6 -6) Index: llvm/lib/Analysis/AliasSetTracker.cpp diff -u llvm/lib/Analysis/AliasSetTracker.cpp:1.31 llvm/lib/Analysis/AliasSetTracker.cpp:1.32 --- llvm/lib/Analysis/AliasSetTracker.cpp:1.31 Sat Nov 27 12:37:42 2004 +++ llvm/lib/Analysis/AliasSetTracker.cpp Mon Dec 6 22:03:45 2004 @@ -539,7 +539,7 @@ } /// print - Convert to human readable form - virtual void print(std::ostream &OS) const { + virtual void print(std::ostream &OS, const Module* = 0) const { Tracker->print(OS); } Index: llvm/lib/Analysis/CFGPrinter.cpp diff -u llvm/lib/Analysis/CFGPrinter.cpp:1.10 llvm/lib/Analysis/CFGPrinter.cpp:1.11 --- llvm/lib/Analysis/CFGPrinter.cpp:1.10 Wed Sep 1 17:55:35 2004 +++ llvm/lib/Analysis/CFGPrinter.cpp Mon Dec 6 22:03:45 2004 @@ -101,7 +101,7 @@ return false; } - void print(std::ostream &OS) const {} + void print(std::ostream &OS, const Module* = 0) const {} virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesAll(); @@ -119,7 +119,7 @@ CFGOnly = OldCFGOnly; return false; } - void print(std::ostream &OS) const {} + void print(std::ostream &OS, const Module* = 0) const {} virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesAll(); Index: llvm/lib/Analysis/IntervalPartition.cpp diff -u llvm/lib/Analysis/IntervalPartition.cpp:1.26 llvm/lib/Analysis/IntervalPartition.cpp:1.27 --- llvm/lib/Analysis/IntervalPartition.cpp:1.26 Fri Sep 3 13:19:51 2004 +++ llvm/lib/Analysis/IntervalPartition.cpp Mon Dec 6 22:03:45 2004 @@ -32,7 +32,7 @@ RootInterval = 0; } -void IntervalPartition::print(std::ostream &O) const { +void IntervalPartition::print(std::ostream &O, const Module*) const { std::copy(Intervals.begin(), Intervals.end(), std::ostream_iterator(O, "\n")); } Index: llvm/lib/Analysis/LoopInfo.cpp diff -u llvm/lib/Analysis/LoopInfo.cpp:1.60 llvm/lib/Analysis/LoopInfo.cpp:1.61 --- llvm/lib/Analysis/LoopInfo.cpp:1.60 Wed Sep 15 12:06:41 2004 +++ llvm/lib/Analysis/LoopInfo.cpp Mon Dec 6 22:03:45 2004 @@ -119,7 +119,7 @@ AU.addRequired(); } -void LoopInfo::print(std::ostream &OS) const { +void LoopInfo::print(std::ostream &OS, const Module* ) const { for (unsigned i = 0; i < TopLevelLoops.size(); ++i) TopLevelLoops[i]->print(OS); #if 0 Index: llvm/lib/Analysis/ScalarEvolution.cpp diff -u llvm/lib/Analysis/ScalarEvolution.cpp:1.29 llvm/lib/Analysis/ScalarEvolution.cpp:1.30 --- llvm/lib/Analysis/ScalarEvolution.cpp:1.29 Sat Dec 4 14:54:32 2004 +++ llvm/lib/Analysis/ScalarEvolution.cpp Mon Dec 6 22:03:45 2004 @@ -2326,7 +2326,7 @@ std::cerr << "\n"; } -void ScalarEvolution::print(std::ostream &OS) const { +void ScalarEvolution::print(std::ostream &OS, const Module* ) const { Function &F = ((ScalarEvolutionsImpl*)Impl)->F; LoopInfo &LI = ((ScalarEvolutionsImpl*)Impl)->LI; From reid at x10sys.com Mon Dec 6 22:03:57 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 22:03:57 -0600 Subject: [llvm-commits] CVS: llvm/lib/VMCore/Dominators.cpp Pass.cpp Message-ID: <200412070403.WAA07777@zion.cs.uiuc.edu> Changes in directory llvm/lib/VMCore: Dominators.cpp updated: 1.59 -> 1.60 Pass.cpp updated: 1.63 -> 1.64 --- Log message: For PR387: http://llvm.cs.uiuc.edu/PR387 :\ Make only one print method to avoid overloaded virtual warnings when \ compiled with -Woverloaded-virtual --- Diffs of the changes: (+5 -5) Index: llvm/lib/VMCore/Dominators.cpp diff -u llvm/lib/VMCore/Dominators.cpp:1.59 llvm/lib/VMCore/Dominators.cpp:1.60 --- llvm/lib/VMCore/Dominators.cpp:1.59 Thu Oct 14 10:47:16 2004 +++ llvm/lib/VMCore/Dominators.cpp Mon Dec 6 22:03:45 2004 @@ -210,7 +210,7 @@ return false; } -void ImmediateDominatorsBase::print(std::ostream &o) const { +void ImmediateDominatorsBase::print(std::ostream &o, const Module* ) const { Function *F = getRoots()[0]->getParent(); for (Function::iterator I = F->begin(), E = F->end(); I != E; ++I) { o << " Immediate Dominator For Basic Block:"; @@ -313,7 +313,7 @@ } } -void DominatorSetBase::print(std::ostream &o) const { +void DominatorSetBase::print(std::ostream &o, const Module* ) const { for (const_iterator I = begin(), E = end(); I != E; ++I) { o << " DomSet For BB: "; if (I->first) @@ -408,7 +408,7 @@ PrintDomTree(*I, o, Lev+1); } -void DominatorTreeBase::print(std::ostream &o) const { +void DominatorTreeBase::print(std::ostream &o, const Module* ) const { o << "=============================--------------------------------\n" << "Inorder Dominator Tree:\n"; PrintDomTree(getRootNode(), o, 1); @@ -455,7 +455,7 @@ return S; } -void DominanceFrontierBase::print(std::ostream &o) const { +void DominanceFrontierBase::print(std::ostream &o, const Module* ) const { for (const_iterator I = begin(), E = end(); I != E; ++I) { o << " DomFrontier for BB"; if (I->first) Index: llvm/lib/VMCore/Pass.cpp diff -u llvm/lib/VMCore/Pass.cpp:1.63 llvm/lib/VMCore/Pass.cpp:1.64 --- llvm/lib/VMCore/Pass.cpp:1.63 Sun Sep 19 23:47:19 2004 +++ llvm/lib/VMCore/Pass.cpp Mon Dec 6 22:03:45 2004 @@ -217,7 +217,7 @@ // to print out the contents of an analysis. Otherwise it is not necessary to // implement this method. // -void Pass::print(std::ostream &O) const { +void Pass::print(std::ostream &O,const Module*) const { O << "Pass::print not implemented for pass: '" << getPassName() << "'!\n"; } From reid at x10sys.com Mon Dec 6 22:03:57 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 22:03:57 -0600 Subject: [llvm-commits] CVS: llvm/lib/CodeGen/LiveIntervalAnalysis.cpp LiveIntervalAnalysis.h Message-ID: <200412070403.WAA07775@zion.cs.uiuc.edu> Changes in directory llvm/lib/CodeGen: LiveIntervalAnalysis.cpp updated: 1.132 -> 1.133 LiveIntervalAnalysis.h updated: 1.43 -> 1.44 --- Log message: For PR387: http://llvm.cs.uiuc.edu/PR387 :\ Make only one print method to avoid overloaded virtual warnings when \ compiled with -Woverloaded-virtual --- Diffs of the changes: (+2 -2) Index: llvm/lib/CodeGen/LiveIntervalAnalysis.cpp diff -u llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1.132 llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1.133 --- llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1.132 Tue Oct 26 00:29:18 2004 +++ llvm/lib/CodeGen/LiveIntervalAnalysis.cpp Mon Dec 6 22:03:45 2004 @@ -169,7 +169,7 @@ } /// print - Implement the dump method. -void LiveIntervals::print(std::ostream &O) const { +void LiveIntervals::print(std::ostream &O, const Module* ) const { O << "********** INTERVALS **********\n"; for (const_iterator I = begin(), E = end(); I != E; ++I) O << " " << I->second << "\n"; Index: llvm/lib/CodeGen/LiveIntervalAnalysis.h diff -u llvm/lib/CodeGen/LiveIntervalAnalysis.h:1.43 llvm/lib/CodeGen/LiveIntervalAnalysis.h:1.44 --- llvm/lib/CodeGen/LiveIntervalAnalysis.h:1.43 Thu Sep 30 10:59:17 2004 +++ llvm/lib/CodeGen/LiveIntervalAnalysis.h Mon Dec 6 22:03:45 2004 @@ -128,7 +128,7 @@ virtual bool runOnMachineFunction(MachineFunction&); /// print - Implement the dump method. - virtual void print(std::ostream &O) const; + virtual void print(std::ostream &O, const Module* = 0) const; private: /// computeIntervals - compute live intervals From reid at x10sys.com Mon Dec 6 22:03:57 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 22:03:57 -0600 Subject: [llvm-commits] CVS: llvm/include/llvm/Analysis/Dominators.h IntervalPartition.h LoopInfo.h ScalarEvolution.h Message-ID: <200412070403.WAA07740@zion.cs.uiuc.edu> Changes in directory llvm/include/llvm/Analysis: Dominators.h updated: 1.47 -> 1.48 IntervalPartition.h updated: 1.20 -> 1.21 LoopInfo.h updated: 1.42 -> 1.43 ScalarEvolution.h updated: 1.6 -> 1.7 --- Log message: For PR387: http://llvm.cs.uiuc.edu/PR387 :\ Make only one print method to avoid overloaded virtual warnings when \ compiled with -Woverloaded-virtual --- Diffs of the changes: (+7 -7) Index: llvm/include/llvm/Analysis/Dominators.h diff -u llvm/include/llvm/Analysis/Dominators.h:1.47 llvm/include/llvm/Analysis/Dominators.h:1.48 --- llvm/include/llvm/Analysis/Dominators.h:1.47 Wed Oct 27 11:14:50 2004 +++ llvm/include/llvm/Analysis/Dominators.h Mon Dec 6 22:03:45 2004 @@ -114,7 +114,7 @@ /// print - Convert to human readable form /// - virtual void print(std::ostream &OS) const; + virtual void print(std::ostream &OS, const Module* = 0) const; }; //===------------------------------------- @@ -218,7 +218,7 @@ /// print - Convert to human readable form /// - virtual void print(std::ostream &OS) const; + virtual void print(std::ostream &OS, const Module* = 0) const; /// dominates - Return true if A dominates B. This performs the special /// checks necessary if A and B are in the same basic block. @@ -375,7 +375,7 @@ /// print - Convert to human readable form /// - virtual void print(std::ostream &OS) const; + virtual void print(std::ostream &OS, const Module* = 0) const; }; @@ -475,7 +475,7 @@ /// print - Convert to human readable form /// - virtual void print(std::ostream &OS) const; + virtual void print(std::ostream &OS, const Module* = 0) const; }; Index: llvm/include/llvm/Analysis/IntervalPartition.h diff -u llvm/include/llvm/Analysis/IntervalPartition.h:1.20 llvm/include/llvm/Analysis/IntervalPartition.h:1.21 --- llvm/include/llvm/Analysis/IntervalPartition.h:1.20 Tue Nov 11 16:41:31 2003 +++ llvm/include/llvm/Analysis/IntervalPartition.h Mon Dec 6 22:03:45 2004 @@ -60,7 +60,7 @@ ~IntervalPartition() { destroy(); } // print - Show contents in human readable format... - virtual void print(std::ostream &O) const; + virtual void print(std::ostream &O, const Module* = 0) const; // getRootInterval() - Return the root interval that contains the starting // block of the function. Index: llvm/include/llvm/Analysis/LoopInfo.h diff -u llvm/include/llvm/Analysis/LoopInfo.h:1.42 llvm/include/llvm/Analysis/LoopInfo.h:1.43 --- llvm/include/llvm/Analysis/LoopInfo.h:1.42 Wed Oct 27 11:14:50 2004 +++ llvm/include/llvm/Analysis/LoopInfo.h Mon Dec 6 22:03:45 2004 @@ -241,7 +241,7 @@ virtual bool runOnFunction(Function &F); virtual void releaseMemory(); - void print(std::ostream &O) const; + void print(std::ostream &O, const Module* = 0) const; /// getAnalysisUsage - Requires dominator sets /// Index: llvm/include/llvm/Analysis/ScalarEvolution.h diff -u llvm/include/llvm/Analysis/ScalarEvolution.h:1.6 llvm/include/llvm/Analysis/ScalarEvolution.h:1.7 --- llvm/include/llvm/Analysis/ScalarEvolution.h:1.6 Thu Jun 24 01:52:20 2004 +++ llvm/include/llvm/Analysis/ScalarEvolution.h Mon Dec 6 22:03:45 2004 @@ -202,7 +202,7 @@ virtual bool runOnFunction(Function &F); virtual void releaseMemory(); virtual void getAnalysisUsage(AnalysisUsage &AU) const; - virtual void print(std::ostream &OS) const; + virtual void print(std::ostream &OS, const Module* = 0) const; }; } From reid at x10sys.com Mon Dec 6 22:03:57 2004 From: reid at x10sys.com (Reid Spencer) Date: Mon, 6 Dec 2004 22:03:57 -0600 Subject: [llvm-commits] CVS: llvm/lib/Analysis/IPA/PrintSCC.cpp Message-ID: <200412070403.WAA07782@zion.cs.uiuc.edu> Changes in directory llvm/lib/Analysis/IPA: PrintSCC.cpp updated: 1.12 -> 1.13 --- Log message: For PR387: http://llvm.cs.uiuc.edu/PR387 :\ Make only one print method to avoid overloaded virtual warnings when \ compiled with -Woverloaded-virtual --- Diffs of the changes: (+2 -2) Index: llvm/lib/Analysis/IPA/PrintSCC.cpp diff -u llvm/lib/Analysis/IPA/PrintSCC.cpp:1.12 llvm/lib/Analysis/IPA/PrintSCC.cpp:1.13 --- llvm/lib/Analysis/IPA/PrintSCC.cpp:1.12 Sun Sep 19 23:44:31 2004 +++ llvm/lib/Analysis/IPA/PrintSCC.cpp Mon Dec 6 22:03:45 2004 @@ -37,7 +37,7 @@ struct CFGSCC : public FunctionPass { bool runOnFunction(Function& func); - void print(std::ostream &O) const { } + void print(std::ostream &O, const Module* = 0) const { } virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesAll(); @@ -48,7 +48,7 @@ // run - Print out SCCs in the call graph for the specified module. bool runOnModule(Module &M); - void print(std::ostream &O) const { } + void print(std::ostream &O, const Module* = 0) const { } // getAnalysisUsage - This pass requires the CallGraph. virtual void getAnalysisUsage(AnalysisUsage &AU) const { From alkis at cs.uiuc.edu Mon Dec 6 22:55:56 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Mon, 6 Dec 2004 22:55:56 -0600 Subject: [llvm-commits] CVS: llvm-java/test/Programs/SingleSource/UnitTests/test.c Message-ID: <200412070455.WAA08414@zion.cs.uiuc.edu> Changes in directory llvm-java/test/Programs/SingleSource/UnitTests: test.c added (r1.1) --- Log message: Commit sources for the test library. --- Diffs of the changes: (+31 -0) Index: llvm-java/test/Programs/SingleSource/UnitTests/test.c diff -c /dev/null llvm-java/test/Programs/SingleSource/UnitTests/test.c:1.1 *** /dev/null Mon Dec 6 22:55:55 2004 --- llvm-java/test/Programs/SingleSource/UnitTests/test.c Mon Dec 6 22:55:45 2004 *************** *** 0 **** --- 1,31 ---- + #include + + #include "Test.h" + + void Java_Test_print_1boolean_1ln(JNIEnv *env, jclass clazz, jboolean aBoolean) + { + if (aBoolean) + puts("true"); + else + puts("false"); + } + + void Java_Test_print_1int_1ln(JNIEnv *env, jclass clazz, jint aInt) + { + printf("%d\n", aInt); + } + + void Java_Test_print_1long_1ln(JNIEnv *env, jclass clazz, jlong aLong) + { + printf("%Ld\n", aLong); + } + + void Java_Test_print_1float_1ln(JNIEnv *env, jclass clazz, jfloat aFloat) + { + printf("%f\n", aFloat); + } + + void Java_Test_print_1double_1ln(JNIEnv *env, jclass clazz, jdouble aDouble) + { + printf("%lf\n", aDouble); + } From alkis at cs.uiuc.edu Mon Dec 6 23:01:05 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Mon, 6 Dec 2004 23:01:05 -0600 Subject: [llvm-commits] CVS: llvm-java/test/Programs/SingleSource/UnitTests/Makefile Message-ID: <200412070501.XAA08543@zion.cs.uiuc.edu> Changes in directory llvm-java/test/Programs/SingleSource/UnitTests: Makefile updated: 1.13 -> 1.14 --- Log message: Add rule to create Test.h. --- Diffs of the changes: (+5 -0) Index: llvm-java/test/Programs/SingleSource/UnitTests/Makefile diff -u llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.13 llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.14 --- llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.13 Sun Dec 5 19:05:23 2004 +++ llvm-java/test/Programs/SingleSource/UnitTests/Makefile Mon Dec 6 23:00:55 2004 @@ -28,6 +28,11 @@ SHARED_LIBRARY=1 LIBRARYNAME=test +all:: Test.h + +Test.h: Output/.compile-java + javah -classpath Output Test + EXTRA_OBJS = $(LibDir)/libtest.bca include ../Makefile.singlesrc From natebegeman at mac.com Mon Dec 6 23:26:04 2004 From: natebegeman at mac.com (Nate Begeman) Date: Mon, 6 Dec 2004 23:26:04 -0600 Subject: [llvm-commits] CVS: llvm/lib/CodeGen/RegAllocLinearScan.cpp Message-ID: <200412070526.XAA08821@zion.cs.uiuc.edu> Changes in directory llvm/lib/CodeGen: RegAllocLinearScan.cpp updated: 1.103 -> 1.104 --- Log message: Move virtual function call out of loop to speed up getFreePhysReg by about 20%, shaving 0.1s off hbd compile time on my g5. Yay. --- Diffs of the changes: (+2 -2) Index: llvm/lib/CodeGen/RegAllocLinearScan.cpp diff -u llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.103 llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.104 --- llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.103 Thu Nov 18 00:01:45 2004 +++ llvm/lib/CodeGen/RegAllocLinearScan.cpp Mon Dec 6 23:25:53 2004 @@ -608,8 +608,8 @@ const TargetRegisterClass* rc = mf_->getSSARegMap()->getRegClass(cur->reg); unsigned freeReg = 0; - for (TargetRegisterClass::iterator i = rc->allocation_order_begin(*mf_); - i != rc->allocation_order_end(*mf_); ++i) { + for (TargetRegisterClass::iterator i = rc->allocation_order_begin(*mf_), + e = rc->allocation_order_end(*mf_); i != e; ++i) { unsigned reg = *i; if (prt_->isRegAvail(reg) && (!freeReg || inactiveCounts[freeReg] < inactiveCounts[reg])) From alkis at cs.uiuc.edu Tue Dec 7 00:47:00 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Tue, 7 Dec 2004 00:47:00 -0600 Subject: [llvm-commits] CVS: llvm/lib/VMCore/Constants.cpp Message-ID: <200412070647.AAA09643@zion.cs.uiuc.edu> Changes in directory llvm/lib/VMCore: Constants.cpp updated: 1.113 -> 1.114 --- Log message: Fix check for valid floats. Also use and HUGE_VALF instead of std::numeric_limits, because they work in more platforms. --- Diffs of the changes: (+1 -10) Index: llvm/lib/VMCore/Constants.cpp diff -u llvm/lib/VMCore/Constants.cpp:1.113 llvm/lib/VMCore/Constants.cpp:1.114 --- llvm/lib/VMCore/Constants.cpp:1.113 Mon Dec 6 16:18:37 2004 +++ llvm/lib/VMCore/Constants.cpp Tue Dec 7 00:46:50 2004 @@ -21,7 +21,6 @@ #include "llvm/ADT/StringExtras.h" #include #include -#include using namespace llvm; ConstantBool *ConstantBool::True = new ConstantBool(true); @@ -443,15 +442,7 @@ // TODO: Figure out how to test if a double can be cast to a float! case Type::FloatTyID: - return - (std::numeric_limits::has_infinity && - std::numeric_limits::has_infinity && - Val == std::numeric_limits::infinity()) || - (std::numeric_limits::has_quiet_NaN && - std::numeric_limits::has_quiet_NaN && - Val == std::numeric_limits::quiet_NaN()) || - (Val >= -std::numeric_limits::max() && - Val <= std::numeric_limits::max()); + return isinf(Val) || isnan(Val) || (Val >= -HUGE_VALF && Val <= HUGE_VALF); case Type::DoubleTyID: return true; // This is the largest type... From reid at x10sys.com Tue Dec 7 00:48:29 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 00:48:29 -0600 Subject: [llvm-commits] CVS: llvm-java/autoconf/configure.ac Message-ID: <200412070648.AAA09671@zion.cs.uiuc.edu> Changes in directory llvm-java/autoconf: configure.ac updated: 1.7 -> 1.8 --- Log message: Configure the test directory too --- Diffs of the changes: (+1 -0) Index: llvm-java/autoconf/configure.ac diff -u llvm-java/autoconf/configure.ac:1.7 llvm-java/autoconf/configure.ac:1.8 --- llvm-java/autoconf/configure.ac:1.7 Mon Sep 20 20:00:41 2004 +++ llvm-java/autoconf/configure.ac Tue Dec 7 00:48:18 2004 @@ -14,6 +14,7 @@ AC_CONFIG_MAKEFILE(Makefile) AC_CONFIG_MAKEFILE(lib/Makefile) AC_CONFIG_MAKEFILE(lib/ClassFile/Makefile) +AC_CONFIG_MAKEFILE([test/Makefile]) AC_CONFIG_MAKEFILE(tools/Makefile) AC_CONFIG_MAKEFILE(tools/classdump/Makefile) From reid at x10sys.com Tue Dec 7 01:06:23 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 01:06:23 -0600 Subject: [llvm-commits] CVS: llvm-java/configure Message-ID: <200412070706.BAA09933@zion.cs.uiuc.edu> Changes in directory llvm-java: configure updated: 1.6 -> 1.7 --- Log message: Provide construction of the various test makefiles. --- Diffs of the changes: (+48 -0) Index: llvm-java/configure diff -u llvm-java/configure:1.6 llvm-java/configure:1.7 --- llvm-java/configure:1.6 Mon Sep 20 20:23:40 2004 +++ llvm-java/configure Tue Dec 7 01:06:12 2004 @@ -1274,6 +1274,30 @@ ac_config_commands="$ac_config_commands lib/ClassFile/Makefile" + ac_config_commands="$ac_config_commands test/Makefile" + + + ac_config_commands="$ac_config_commands test/Makefile.test" + + + ac_config_commands="$ac_config_commands test/Programs/SingleSource/UnitTests/Makefile" + + + ac_config_commands="$ac_config_commands test/Programs/SingleSource/Makefile" + + + ac_config_commands="$ac_config_commands test/Programs/SingleSource/Makefile.singlesrc" + + + ac_config_commands="$ac_config_commands test/Programs/Makefile" + + + ac_config_commands="$ac_config_commands test/Regression/ClassFile/Makefile" + + + ac_config_commands="$ac_config_commands test/Regression/Makefile" + + ac_config_commands="$ac_config_commands tools/Makefile" @@ -1973,6 +1997,14 @@ ${srcdir}/autoconf/mkinstalldirs `dirname Makefile` ${srcdir}/autoconf/mkinstalldirs `dirname lib/Makefile` ${srcdir}/autoconf/mkinstalldirs `dirname lib/ClassFile/Makefile` +${srcdir}/autoconf/mkinstalldirs `dirname test/Makefile` +${srcdir}/autoconf/mkinstalldirs `dirname test/Makefile.test` +${srcdir}/autoconf/mkinstalldirs `dirname test/Programs/SingleSource/UnitTests/Makefile` +${srcdir}/autoconf/mkinstalldirs `dirname test/Programs/SingleSource/Makefile` +${srcdir}/autoconf/mkinstalldirs `dirname test/Programs/SingleSource/Makefile.singlesrc` +${srcdir}/autoconf/mkinstalldirs `dirname test/Programs/Makefile` +${srcdir}/autoconf/mkinstalldirs `dirname test/Regression/ClassFile/Makefile` +${srcdir}/autoconf/mkinstalldirs `dirname test/Regression/Makefile` ${srcdir}/autoconf/mkinstalldirs `dirname tools/Makefile` ${srcdir}/autoconf/mkinstalldirs `dirname tools/classdump/Makefile` @@ -1989,6 +2021,14 @@ "Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS Makefile" ;; "lib/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS lib/Makefile" ;; "lib/ClassFile/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS lib/ClassFile/Makefile" ;; + "test/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/Makefile" ;; + "test/Makefile.test" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/Makefile.test" ;; + "test/Programs/SingleSource/UnitTests/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/Programs/SingleSource/UnitTests/Makefile" ;; + "test/Programs/SingleSource/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/Programs/SingleSource/Makefile" ;; + "test/Programs/SingleSource/Makefile.singlesrc" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/Programs/SingleSource/Makefile.singlesrc" ;; + "test/Programs/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/Programs/Makefile" ;; + "test/Regression/ClassFile/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/Regression/ClassFile/Makefile" ;; + "test/Regression/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/Regression/Makefile" ;; "tools/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS tools/Makefile" ;; "tools/classdump/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS tools/classdump/Makefile" ;; *) { { echo "$as_me:$LINENO: error: invalid argument: $ac_config_target" >&5 @@ -2432,6 +2472,14 @@ Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/Makefile Makefile ;; lib/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/lib/Makefile lib/Makefile ;; lib/ClassFile/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/lib/ClassFile/Makefile lib/ClassFile/Makefile ;; + test/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/Makefile test/Makefile ;; + test/Makefile.test ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/Makefile.test test/Makefile.test ;; + test/Programs/SingleSource/UnitTests/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/Programs/SingleSource/UnitTests/Makefile test/Programs/SingleSource/UnitTests/Makefile ;; + test/Programs/SingleSource/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/Programs/SingleSource/Makefile test/Programs/SingleSource/Makefile ;; + test/Programs/SingleSource/Makefile.singlesrc ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/Programs/SingleSource/Makefile.singlesrc test/Programs/SingleSource/Makefile.singlesrc ;; + test/Programs/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/Programs/Makefile test/Programs/Makefile ;; + test/Regression/ClassFile/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/Regression/ClassFile/Makefile test/Regression/ClassFile/Makefile ;; + test/Regression/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/Regression/Makefile test/Regression/Makefile ;; tools/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/tools/Makefile tools/Makefile ;; tools/classdump/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/tools/classdump/Makefile tools/classdump/Makefile ;; esac From reid at x10sys.com Tue Dec 7 01:06:23 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 01:06:23 -0600 Subject: [llvm-commits] CVS: llvm-java/autoconf/AutoRegen.sh configure.ac Message-ID: <200412070706.BAA09930@zion.cs.uiuc.edu> Changes in directory llvm-java/autoconf: AutoRegen.sh updated: 1.1 -> 1.2 configure.ac updated: 1.8 -> 1.9 --- Log message: Provide construction of the various test makefiles. --- Diffs of the changes: (+13 -6) Index: llvm-java/autoconf/AutoRegen.sh diff -u llvm-java/autoconf/AutoRegen.sh:1.1 llvm-java/autoconf/AutoRegen.sh:1.2 --- llvm-java/autoconf/AutoRegen.sh:1.1 Mon Sep 20 19:58:00 2004 +++ llvm-java/autoconf/AutoRegen.sh Tue Dec 7 01:06:12 2004 @@ -9,7 +9,7 @@ if test $? -ne 0 ; then die "Your autoconf was not detected as being 2.59" fi -aclocal --version | egrep '1\.9\.1' > /dev/null +aclocal --version | egrep '1\.9\.2' > /dev/null if test $? -ne 0 ; then die "Your aclocal was not detected as being 1.9.1" fi Index: llvm-java/autoconf/configure.ac diff -u llvm-java/autoconf/configure.ac:1.8 llvm-java/autoconf/configure.ac:1.9 --- llvm-java/autoconf/configure.ac:1.8 Tue Dec 7 00:48:18 2004 +++ llvm-java/autoconf/configure.ac Tue Dec 7 01:06:12 2004 @@ -11,12 +11,19 @@ dnl Configure Makefiles dnl List every Makefile that exists within your source tree -AC_CONFIG_MAKEFILE(Makefile) -AC_CONFIG_MAKEFILE(lib/Makefile) -AC_CONFIG_MAKEFILE(lib/ClassFile/Makefile) +AC_CONFIG_MAKEFILE([Makefile]) +AC_CONFIG_MAKEFILE([lib/Makefile]) +AC_CONFIG_MAKEFILE([lib/ClassFile/Makefile]) AC_CONFIG_MAKEFILE([test/Makefile]) -AC_CONFIG_MAKEFILE(tools/Makefile) -AC_CONFIG_MAKEFILE(tools/classdump/Makefile) +AC_CONFIG_MAKEFILE([test/Makefile.test]) +AC_CONFIG_MAKEFILE([test/Programs/SingleSource/UnitTests/Makefile]) +AC_CONFIG_MAKEFILE([test/Programs/SingleSource/Makefile]) +AC_CONFIG_MAKEFILE([test/Programs/SingleSource/Makefile.singlesrc]) +AC_CONFIG_MAKEFILE([test/Programs/Makefile]) +AC_CONFIG_MAKEFILE([test/Regression/ClassFile/Makefile]) +AC_CONFIG_MAKEFILE([test/Regression/Makefile]) +AC_CONFIG_MAKEFILE([tools/Makefile]) +AC_CONFIG_MAKEFILE([tools/classdump/Makefile]) AC_CONFIG_FILES(Makefile.common) From reid at x10sys.com Tue Dec 7 01:06:57 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 01:06:57 -0600 Subject: [llvm-commits] CVS: llvm/lib/VMCore/Constants.cpp Message-ID: <200412070706.BAA09954@zion.cs.uiuc.edu> Changes in directory llvm/lib/VMCore: Constants.cpp updated: 1.114 -> 1.115 --- Log message: Fix some comments. --- Diffs of the changes: (+2 -1) Index: llvm/lib/VMCore/Constants.cpp diff -u llvm/lib/VMCore/Constants.cpp:1.114 llvm/lib/VMCore/Constants.cpp:1.115 --- llvm/lib/VMCore/Constants.cpp:1.114 Tue Dec 7 00:46:50 2004 +++ llvm/lib/VMCore/Constants.cpp Tue Dec 7 01:06:47 2004 @@ -440,8 +440,9 @@ default: return false; // These can't be represented as floating point! - // TODO: Figure out how to test if a double can be cast to a float! case Type::FloatTyID: + // Since we're passed a double but the ConstantFP is of type float, make + // sure that the double value is in the range of a float return isinf(Val) || isnan(Val) || (Val >= -HUGE_VALF && Val <= HUGE_VALF); case Type::DoubleTyID: From reid at x10sys.com Tue Dec 7 01:08:19 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 01:08:19 -0600 Subject: [llvm-commits] CVS: llvm/lib/VMCore/Constants.cpp Message-ID: <200412070708.BAA09972@zion.cs.uiuc.edu> Changes in directory llvm/lib/VMCore: Constants.cpp updated: 1.115 -> 1.116 --- Log message: Provide a missing header file. --- Diffs of the changes: (+1 -0) Index: llvm/lib/VMCore/Constants.cpp diff -u llvm/lib/VMCore/Constants.cpp:1.115 llvm/lib/VMCore/Constants.cpp:1.116 --- llvm/lib/VMCore/Constants.cpp:1.115 Tue Dec 7 01:06:47 2004 +++ llvm/lib/VMCore/Constants.cpp Tue Dec 7 01:08:08 2004 @@ -21,6 +21,7 @@ #include "llvm/ADT/StringExtras.h" #include #include +#include "math.h" using namespace llvm; ConstantBool *ConstantBool::True = new ConstantBool(true); From reid at x10sys.com Tue Dec 7 01:38:18 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 01:38:18 -0600 Subject: [llvm-commits] CVS: llvm/lib/VMCore/Constants.cpp Message-ID: <200412070738.BAA10291@zion.cs.uiuc.edu> Changes in directory llvm/lib/VMCore: Constants.cpp updated: 1.116 -> 1.117 --- Log message: Revert the recent patches to "fix" ConstantFP::isValueValidForType. None of them seem to work everywhere. --- Diffs of the changes: (+1 -5) Index: llvm/lib/VMCore/Constants.cpp diff -u llvm/lib/VMCore/Constants.cpp:1.116 llvm/lib/VMCore/Constants.cpp:1.117 --- llvm/lib/VMCore/Constants.cpp:1.116 Tue Dec 7 01:08:08 2004 +++ llvm/lib/VMCore/Constants.cpp Tue Dec 7 01:38:08 2004 @@ -21,7 +21,6 @@ #include "llvm/ADT/StringExtras.h" #include #include -#include "math.h" using namespace llvm; ConstantBool *ConstantBool::True = new ConstantBool(true); @@ -441,11 +440,8 @@ default: return false; // These can't be represented as floating point! + // TODO: Figure out how to test if a double can be cast to a float! case Type::FloatTyID: - // Since we're passed a double but the ConstantFP is of type float, make - // sure that the double value is in the range of a float - return isinf(Val) || isnan(Val) || (Val >= -HUGE_VALF && Val <= HUGE_VALF); - case Type::DoubleTyID: return true; // This is the largest type... } From lattner at cs.uiuc.edu Tue Dec 7 02:04:28 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 7 Dec 2004 02:04:28 -0600 Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200412070804.iB784SKl024261@apoc.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.275 -> 1.276 --- Log message: Commit the cleanup of the LLVM 1.4 release notes. This should clearly go into the release :) --- Diffs of the changes: (+79 -100) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.275 llvm/docs/ReleaseNotes.html:1.276 --- llvm/docs/ReleaseNotes.html:1.275 Mon Dec 6 16:32:33 2004 +++ llvm/docs/ReleaseNotes.html Tue Dec 7 02:04:13 2004 @@ -44,14 +44,14 @@

      This document contains the release notes for the LLVM compiler infrastructure, release 1.4. Here we describe the status of LLVM, including any -known problems and bug fixes from the previous release. The most up-to-date +known problems and improvements from the previous release. The most up-to-date version of this document can be found on the LLVM 1.4 web site. If you are not reading this on the LLVM web pages, you should probably go there because this document may be updated after the release.

      -

      For more information about LLVM, including information about potentially more -current releases, please check out the main +

      For more information about LLVM, including information about the latest +release, please check out the main LLVM web site. If you have questions or comments, the LLVM developer's mailing list is a good place to send them.

      @@ -73,9 +73,18 @@

      This is the fifth public release of the LLVM compiler infrastructure.

      -

      At this time, LLVM is known to correctly compile and run all C & C++ -SPEC CPU95 & 2000 benchmarks, the Olden benchmarks, and the Ptrdist -benchmarks, and many other C and C++ programs.

      +

      At this time, LLVM is known to correctly compile and a broad range of +C and C++ programs, including the SPEC CPU95 & 2000 suite. This release +includes several major enhancements to the LLVM system, including a new +PowerPC JIT, enhancements to the C/C++ front-end to provide source line number +information in LLVM, a new compiler +driver, and several other enhancements listed below. It also includes +bug fixes for those problems found since the 1.3 release.

      + +

      Note that this release seperates the LLVM Program Testsuite out of the +main LLVM distribution into a seperate CVS repository and tarball. This +reduces the size of the main LLVM distribution. Also note that LLVM now +builds tools into llvm/Debug/bin by default instead of llvm/tools/Debug.

    @@ -86,71 +95,69 @@
      -
    1. LLVM now includes a JIT for the PowerPC target.
      2. -
    2. LLVM now optimizes global variables significantly more than it did - before. -
      3. -
    3. LLVM now includes the new 'undef' value and - unreachable instruction, - which give the optimizer more information about the behavior of the - program. -
      4. +
    4. LLVM now includes a Just-In-Time compiler for the PowerPC target.
    5. llvmgcc and llvmg++ now emit source line number information when '-g' is passed in. This information can be used with llvm-db or other tools and - passes. -
      6. + passes.
    6. The test/Programs hierarchy has been moved out of the main LLVM tree into a separate CVS repository and tarball. This shrinks the distribution size of LLVM itself significantly.
      7. +
    7. LLVM now optimizes global variables more aggressively than it did + before.
      8. +
    8. LLVM now includes the new 'undef' value and + unreachable instruction, + which give the optimizer more information about the behavior of the + program. +
    9. Bytecode compression with bzip2 has been implemented. All bytecode files generated by LLVM will now be compressed by default. Compression can be disabled with the -disable-compression option to the tools that can generate bytecode files.
      10. -
    10. A generic compiler driver and - an associated generic linker have - been implemented. The compiler driver is generic because it can be configured +
    11. A generic compiler driver + (llvmc) and + an associated generic linker + (llvm-ld) have been added. The compiler driver is generic because it can be + configured to pre-process, translate, optimize, assemble, and link code from any source - language. This aids compiler writers because all that is needed is a - source-to-bytecode or source-to-assembly translator and a configuration file. - The linker is generic because it allows dynamically loadable optimization - modules to be executed for link-time optimization. Language specific - link-time optimization modules can be created and executed automatically. + language with an LLVM front-end. This makes it easier for compiler writers + to hide the multiple steps required to compile a program (compiling, + optimizing, linking runtime libraries, etc) in one simple command.
    12. The dependent libraries feature has been implemented. This allows front end compilers to indicate in the bytecode which libraries the bytecode needs to be linked with. Both the C/C++ front end and Stacker support generating the required libraries. The - Linker now supports using this information to ensure required libaries are + linker now supports using this information to ensure required libaries are linked into the module. This minimizes the need to use the -l option when using llvmc
      13. -
    13. The LLVM makefiles have been improved to build LLVM faster (2x) and - includes new targets (like dist-check, uninstall). One important change is - associated with PR456. The - libraries and tools will now be built into $builddir/Debug/{bin,lib} - instead of $builddir/tools/Debug and $builddir/lib/Debug. - Similarly for Release and Profile builds. +
    14. The LLVM makefiles have been improved to build LLVM much faster and + includes new targets (like dist-check, uninstall). One important user-visible + change is that libraries and tools will now be built into + $builddir/Debug/{bin,lib} + instead of $builddir/tools/Debug and $builddir/lib/Debug + (Similarly for Release and Profile builds).
    15. The LLVM source code is much more compatible with Microsoft Visual C++, including the JIT and runtime-code generation, though the entire system may not work with it.
      16. -
    16. The target-to-JIT interfaces are +
    17. The JIT-Target interfaces are now much simpler and more powerful.
      18. +
    18. LLVM now provides llvm-ar and llvm-ranlib tools for working with archives + of LLVM bytecode files.
    19. zlib and libpng are no longer included in the main LLVM tarball.
      20. -
    20. The LLVM code generator now generates asm writers for the target from - an abstract target description, instead of requiring them to be hand - written.
      21. +
    21. The LLVM code generator now automatically generates assembly code writers + from an abstract target descriptions, eliminating the need to write + assembly printers manually.
    22. LLVM regression and feature tests can now be run with DejaGNU.
    23. llvmgcc and llvmg++ now emit source-level line number information, making it possible to map from LLVM code back to source. This is currently used by llvm-db.
      24. -
    24. Floating point intensive programs on X86 systems run much faster - with the LLC code generator and JIT than in 1.3.
    @@ -187,14 +194,12 @@
      -
    1. - [core/asmparser] ConstantFP::isValueValidForType Broken -
      2. -
    2. [llvmg++] Tons of warnings - are spewed when linking to libstdc++ +
    3. The linker no longer emits many + useless warnings when linking C++ programs.
      4. -
    4. include/{Support,Config} -> - include/llvm/{Support,Config} +
    5. The LLVM #include namespace + has been made consistent. Files in llvm/include/{Support,Config} + are now located in llvm/include/llvm/{Support,Config}.
    6. The names of the libraries generated by compiling LLVM source have been changed to ensure they do not conflict with other packages upon installation. @@ -202,23 +207,13 @@ the library libasmparser.a in 1.3 has become libLLVMAsmParser.a in release 1.4.
      7. -
    7. [llvmg++] C++ frontend is expanding - lots of unused inline functions
      8. -
    - -
    +
  • The C++ frontend no longer expands and emits all inline functions, even if they + are unused. It now properly tracks which functions are needed and + only compiles those.
    • - -
    -In this release, the following build problems were fixed: -
    - -
    -
      -
    1. [autoconf] further standardizing - autoconf usage. Various improvements in the configure.ac script were - made as well as the makefile system. -
      2. +
    2. Many improvements in the autoconf + and makefile systems have been implemented.
    @@ -230,9 +225,12 @@
      -
    1. Ugly code generated for - std::min/std::max -
      2. +
    2. The optimizer produces more + efficient code for std::min/std::max and other similar functions.
      3. +
    3. The X86 backend generates substantially faster code for floating point + intensive programs.
      4. +
    4. The PowerPC backend generates more efficient code in many common + scenarios.
    @@ -247,10 +245,6 @@

    Bugs fixed in the LLVM Core:

      -
    1. [Linker] gccld does not link - objects/archives in order specified on the command line
      2. -
    2. [X86] llc output for functions - w/certain names tickles GNU 'as' bugs
    3. [licm] LICM invalidates alias analysis info and uses broken information (optimizer crash)
    4. [asmwriter] Asmwriter is really @@ -259,6 +253,8 @@ completely broken in LLVM 1.3
    5. [bcwriter] Empty compaction tables defined
      6. +
    6. [X86] llc output for functions + w/certain names tickles GNU 'as' bugs
    7. [cbackend] Static globals are prototyped as 'extern'
    @@ -274,7 +270,7 @@ bitfield which does not increase struct size
  • [llvmgcc] llvmgcc emits invalid constant exprs
    • -
  • [llvmg++] Crash in initializing +
  • [llvmg++] Crash initializing array with constructors in hard EH situations
  • [llvm-gcc] Inline function redefinitions error due to 'asm' function rename
    • @@ -309,8 +305,9 @@
  • Intel and AMD machines running Red Hat Linux and FreeBSD (and probably other unix-like systems).
  • Sun UltraSPARC workstations running Solaris 8.
    • -
  • Intel and AMD machines running on Win32 with the Cygwin libraries.
    • -
  • PowerPC-based Mac OS X boxes, running 10.2 and above.
    • +
  • Intel and AMD machines running on Win32 with the Cygwin libraries (limited + support is available for native builds with Visual C++).
    • +
  • PowerPC-based Mac OS X systems, running 10.2 and above.

    • The core LLVM infrastructure uses @@ -319,6 +316,7 @@ porting may be required to get LLVM to work on new platforms. We welcome your portability patches and reports of successful builds or error messages.

    + @@ -360,11 +359,11 @@ components, please contact us on the llvmdev list.

      -
    • The following passes are incomplete or buggy: -pgmdep, -memdep, - -ipmodref, -cee, -branch-combine, -instloops, -paths
      • -
    • The -pre pass is incomplete (there are cases it doesn't handle that - it should) and not thoroughly tested.
      • -
    • The llvm-db tool is in a very early stage of development.
      • +
    • The following passes are incomplete or buggy, and may be removed in future + releases: -pgmdep, -memdep, -ipmodref, -cee, -branch-combine, + -instloops, -paths, -pre
      • +
    • The llvm-db tool is in a very early stage of development, but can + be used to step through programs and inspect the stack.
    • The "iterative scan" register allocator (enabled with -regalloc=iterativescan) is not stable.
    @@ -385,22 +384,10 @@ such, execution of a threaded program could cause these data structures to be corrupted. -
  • Linking in static archive files (.a files) is slow by default because - there is no symbol table in the archive. To remedy this, run - llvm-ranlib on the - archive to add an LLVM symbol table. -
    • -
  • The gccld program does not link - objects/archives in the order specified on the command line. -
  • The lower-invoke pass does not mark values live across a setjmp as volatile. This missing feature only affects targets whose setjmp/longjmp libraries do not save and restore the entire register file.
    • -
  • [bytecode] Assertion on V1 - Bytecode Files. This bug won't be fixed because V1 bytecode had its own - problems, no one is using V1 bytecode any more, and the fix is non-trivial. -
    • @@ -426,9 +413,6 @@
  • Initialization of global union variables can only be done with the largest union member.
    • -
  • [llvm-gcc] Error when an implicitly -external function is re-declared as static
    • - @@ -581,10 +565,9 @@
    -

    For this release, the C++ front-end is considered to be fully functional but -has not been tested as thoroughly as the C front-end. It has been tested and -works for a number of non-trivial programs, but there may be lurking bugs. -Please report any bugs or problems.

    +

    For this release, the C++ front-end is considered to be fully. It has been +tested and works for a number of non-trivial programs, including LLVM +itself.

    @@ -696,10 +679,6 @@ (for example, GCC requires the -fno-strict-aliasing option). This problem probably cannot be fixed. -
  • Initializers for global variables -cannot include special floating point numbers like Not-A-Number or -Infinity.
    • -
  • Zero arg vararg functions are not supported. This should not affect LLVM produced by the C or C++ frontends.
    • @@ -739,7 +718,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/12/06 22:32:33 $ + Last modified: $Date: 2004/12/07 08:04:13 $ From reid at x10sys.com Tue Dec 7 02:11:22 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 02:11:22 -0600 Subject: [llvm-commits] CVS: llvm/include/llvm/Pass.h Message-ID: <200412070811.CAA10614@zion.cs.uiuc.edu> Changes in directory llvm/include/llvm: Pass.h updated: 1.48 -> 1.49 --- Log message: For PR387: http://llvm.cs.uiuc.edu/PR387 :\ Add runPass methods to remove -Woverloaded-virtual warnings are not \ present and circumvent possible inheritance bugs. --- Diffs of the changes: (+6 -3) Index: llvm/include/llvm/Pass.h diff -u llvm/include/llvm/Pass.h:1.48 llvm/include/llvm/Pass.h:1.49 --- llvm/include/llvm/Pass.h:1.48 Mon Dec 6 22:03:44 2004 +++ llvm/include/llvm/Pass.h Tue Dec 7 02:11:11 2004 @@ -87,7 +87,8 @@ /// runPass - Run this pass, returning true if a modification was made to the /// module argument. This should be implemented by all concrete subclasses. /// - virtual bool runPass(Module &M) = 0; + virtual bool runPass(Module &M) { return false; } + virtual bool runPass(BasicBlock&) { return false; } /// print - Print out the internal state of the pass. This is called by /// Analyze to print out the contents of an analysis. Otherwise it is not @@ -216,7 +217,8 @@ /// being operated on. virtual bool runOnModule(Module &M) = 0; - bool runPass(Module &M) { return runOnModule(M); } + virtual bool runPass(Module &M) { return runOnModule(M); } + virtual bool runPass(BasicBlock&) { return false; } virtual void addToPassManager(PassManagerT *PM, AnalysisUsage &AU); }; @@ -338,7 +340,8 @@ /// To run directly on the basic block, we initialize, runOnBasicBlock, then /// finalize. /// - bool runPass(BasicBlock &BB); + virtual bool runPass(Module &M) { return false; } + virtual bool runPass(BasicBlock &BB); private: friend class PassManagerT; From reid at x10sys.com Tue Dec 7 02:11:35 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 02:11:35 -0600 Subject: [llvm-commits] CVS: llvm/lib/Analysis/IPA/GlobalsModRef.cpp Message-ID: <200412070811.CAA10636@zion.cs.uiuc.edu> Changes in directory llvm/lib/Analysis/IPA: GlobalsModRef.cpp updated: 1.7 -> 1.8 --- Log message: For PR387: http://llvm.cs.uiuc.edu/PR387 :\ Add getModRefInfo method to avoid overloaded virtuals --- Diffs of the changes: (+3 -0) Index: llvm/lib/Analysis/IPA/GlobalsModRef.cpp diff -u llvm/lib/Analysis/IPA/GlobalsModRef.cpp:1.7 llvm/lib/Analysis/IPA/GlobalsModRef.cpp:1.8 --- llvm/lib/Analysis/IPA/GlobalsModRef.cpp:1.7 Sun Sep 19 23:45:09 2004 +++ llvm/lib/Analysis/IPA/GlobalsModRef.cpp Tue Dec 7 02:11:24 2004 @@ -96,6 +96,9 @@ AliasResult alias(const Value *V1, unsigned V1Size, const Value *V2, unsigned V2Size); ModRefResult getModRefInfo(CallSite CS, Value *P, unsigned Size); + ModRefResult getModRefInfo(CallSite CS1, CallSite CS2) { + return AliasAnalysis::getModRefInfo(CS1,CS2); + } bool hasNoModRefInfoForCalls() const { return false; } bool doesNotAccessMemory(Function *F) { From reid at x10sys.com Tue Dec 7 02:11:46 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 02:11:46 -0600 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Scalar/LowerAllocations.cpp Message-ID: <200412070811.CAA10655@zion.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Scalar: LowerAllocations.cpp updated: 1.49 -> 1.50 --- Log message: For PR387: http://llvm.cs.uiuc.edu/PR387 :\ Add doInitialization method to avoid overloaded virtuals --- Diffs of the changes: (+3 -0) Index: llvm/lib/Transforms/Scalar/LowerAllocations.cpp diff -u llvm/lib/Transforms/Scalar/LowerAllocations.cpp:1.49 llvm/lib/Transforms/Scalar/LowerAllocations.cpp:1.50 --- llvm/lib/Transforms/Scalar/LowerAllocations.cpp:1.49 Wed Sep 1 17:55:36 2004 +++ llvm/lib/Transforms/Scalar/LowerAllocations.cpp Tue Dec 7 02:11:36 2004 @@ -37,6 +37,9 @@ /// a module contains a declaration for a malloc and a free function. /// bool doInitialization(Module &M); + + virtual bool doInitialization(Function&f) + { return BasicBlockPass::doInitialization(f); } /// runOnBasicBlock - This method does the actual work of converting /// instructions over, assuming that the pass has already been initialized. From reid at x10sys.com Tue Dec 7 02:11:35 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 02:11:35 -0600 Subject: [llvm-commits] CVS: llvm/lib/Analysis/AliasAnalysisCounter.cpp BasicAliasAnalysis.cpp Message-ID: <200412070811.CAA10641@zion.cs.uiuc.edu> Changes in directory llvm/lib/Analysis: AliasAnalysisCounter.cpp updated: 1.9 -> 1.10 BasicAliasAnalysis.cpp updated: 1.58 -> 1.59 --- Log message: For PR387: http://llvm.cs.uiuc.edu/PR387 :\ Add getModRefInfo method to avoid overloaded virtuals --- Diffs of the changes: (+6 -0) Index: llvm/lib/Analysis/AliasAnalysisCounter.cpp diff -u llvm/lib/Analysis/AliasAnalysisCounter.cpp:1.9 llvm/lib/Analysis/AliasAnalysisCounter.cpp:1.10 --- llvm/lib/Analysis/AliasAnalysisCounter.cpp:1.9 Sun Sep 19 23:45:57 2004 +++ llvm/lib/Analysis/AliasAnalysisCounter.cpp Tue Dec 7 02:11:24 2004 @@ -115,6 +115,9 @@ ModRefResult getModRefInfo(CallSite CS, Value *P, unsigned Size) { return count(getAnalysis().getModRefInfo(CS, P, Size)); } + ModRefResult getModRefInfo(CallSite CS1, CallSite CS2) { + return AliasAnalysis::getModRefInfo(CS1,CS2); + } }; RegisterOpt Index: llvm/lib/Analysis/BasicAliasAnalysis.cpp diff -u llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.58 llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.59 --- llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.58 Sun Nov 28 14:30:15 2004 +++ llvm/lib/Analysis/BasicAliasAnalysis.cpp Tue Dec 7 02:11:24 2004 @@ -82,6 +82,9 @@ const Value *V2, unsigned V2Size); ModRefResult getModRefInfo(CallSite CS, Value *P, unsigned Size); + ModRefResult getModRefInfo(CallSite CS1, CallSite CS2) { + return NoAA::getModRefInfo(CS1,CS2); + } /// hasNoModRefInfoForCalls - We can provide mod/ref information against /// non-escaping allocations. From reid at x10sys.com Tue Dec 7 02:11:35 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 02:11:35 -0600 Subject: [llvm-commits] CVS: llvm/lib/Analysis/DataStructure/DataStructureAA.cpp Message-ID: <200412070811.CAA10644@zion.cs.uiuc.edu> Changes in directory llvm/lib/Analysis/DataStructure: DataStructureAA.cpp updated: 1.20 -> 1.21 --- Log message: For PR387: http://llvm.cs.uiuc.edu/PR387 :\ Add getModRefInfo method to avoid overloaded virtuals --- Diffs of the changes: (+3 -0) Index: llvm/lib/Analysis/DataStructure/DataStructureAA.cpp diff -u llvm/lib/Analysis/DataStructure/DataStructureAA.cpp:1.20 llvm/lib/Analysis/DataStructure/DataStructureAA.cpp:1.21 --- llvm/lib/Analysis/DataStructure/DataStructureAA.cpp:1.20 Sun Sep 19 23:45:25 2004 +++ llvm/lib/Analysis/DataStructure/DataStructureAA.cpp Tue Dec 7 02:11:24 2004 @@ -56,6 +56,9 @@ void getMustAliases(Value *P, std::vector &RetVals); ModRefResult getModRefInfo(CallSite CS, Value *P, unsigned Size); + ModRefResult getModRefInfo(CallSite CS1, CallSite CS2) { + return AliasAnalysis::getModRefInfo(CS1,CS2); + } private: DSGraph *getGraphForValue(const Value *V); From alkis at cs.uiuc.edu Tue Dec 7 02:33:23 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Tue, 7 Dec 2004 02:33:23 -0600 Subject: [llvm-commits] CVS: llvm-java/test/Programs/SingleSource/UnitTests/Makefile Message-ID: <200412070833.CAA10909@zion.cs.uiuc.edu> Changes in directory llvm-java/test/Programs/SingleSource/UnitTests: Makefile updated: 1.14 -> 1.15 --- Log message: Don't print out command if not in VERBOSE mode. --- Diffs of the changes: (+1 -1) Index: llvm-java/test/Programs/SingleSource/UnitTests/Makefile diff -u llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.14 llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.15 --- llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.14 Mon Dec 6 23:00:55 2004 +++ llvm-java/test/Programs/SingleSource/UnitTests/Makefile Tue Dec 7 02:33:12 2004 @@ -31,7 +31,7 @@ all:: Test.h Test.h: Output/.compile-java - javah -classpath Output Test + $(Verb)javah -classpath Output Test EXTRA_OBJS = $(LibDir)/libtest.bca From reid at x10sys.com Tue Dec 7 02:39:19 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 02:39:19 -0600 Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200412070839.CAA10993@zion.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.276 -> 1.277 --- Log message: * Eliminate redundancies * Fix grammaro's * HTML 4.01 Strict compliance --- Diffs of the changes: (+11 -13) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.276 llvm/docs/ReleaseNotes.html:1.277 --- llvm/docs/ReleaseNotes.html:1.276 Tue Dec 7 02:04:13 2004 +++ llvm/docs/ReleaseNotes.html Tue Dec 7 02:39:08 2004 @@ -73,7 +73,7 @@

    This is the fifth public release of the LLVM compiler infrastructure.

    -

    At this time, LLVM is known to correctly compile and a broad range of +

    At this time, LLVM is known to correctly compile on a broad range of C and C++ programs, including the SPEC CPU95 & 2000 suite. This release includes several major enhancements to the LLVM system, including a new PowerPC JIT, enhancements to the C/C++ front-end to provide source line number @@ -97,8 +97,9 @@

    1. LLVM now includes a Just-In-Time compiler for the PowerPC target.
    2. llvmgcc and llvmg++ now emit source line number information when '-g' is - passed in. This information can be used with llvm-db or other tools and - passes.
      3. + passed in, making it possible to map from LLVM code back to source. + This information is currently used by llvm-db and can be used with other + tools and passes.
    3. The test/Programs hierarchy has been moved out of the main LLVM tree into a separate CVS repository and tarball. This shrinks the distribution size of LLVM itself significantly. @@ -128,8 +129,8 @@
    4. The dependent libraries feature has been implemented. This allows front end compilers to indicate in the bytecode which libraries the bytecode needs to be linked with. Both the - C/C++ front end and Stacker support generating the required libraries. The - linker now supports using this information to ensure required libaries are + C/C++ and Stacker front ends support generating the required dependencies. + The linker now supports using this information to ensure required libaries are linked into the module. This minimizes the need to use the -l option when using llvmc
      5. @@ -154,10 +155,7 @@
    5. The LLVM code generator now automatically generates assembly code writers from an abstract target descriptions, eliminating the need to write assembly printers manually.
      6. -
    6. LLVM regression and feature tests can now be run with DejaGNU.
      7. -
    7. llvmgcc and llvmg++ now emit source-level line number information, making - it possible to map from LLVM code back to source. This is currently used - by llvm-db.
      8. +
    8. LLVM regression and feature tests now use DejaGNU instead of QMTest.
    @@ -195,11 +193,11 @@
    1. The linker no longer emits many - useless warnings when linking C++ programs. + useless warnings when linking C++ programs.
    2. The LLVM #include namespace has been made consistent. Files in llvm/include/{Support,Config} - are now located in llvm/include/llvm/{Support,Config}. + are now located in llvm/include/llvm/{Support,Config}.
    3. The names of the libraries generated by compiling LLVM source have been changed to ensure they do not conflict with other packages upon installation. @@ -565,7 +563,7 @@
      -

      For this release, the C++ front-end is considered to be fully. It has been +

      For this release, the C++ front-end is considered to be fully tested and works for a number of non-trivial programs, including LLVM itself.

      @@ -718,7 +716,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/12/07 08:04:13 $ + Last modified: $Date: 2004/12/07 08:39:08 $ From alkis at cs.uiuc.edu Tue Dec 7 03:04:27 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Tue, 7 Dec 2004 03:04:27 -0600 Subject: [llvm-commits] CVS: llvm-java/lib/Compiler/Compiler.cpp Message-ID: <200412070904.DAA11347@zion.cs.uiuc.edu> Changes in directory llvm-java/lib/Compiler: Compiler.cpp updated: 1.170 -> 1.171 --- Log message: Be a bit more careful about the vtable types so that we don't cast function pointers around. --- Diffs of the changes: (+26 -13) Index: llvm-java/lib/Compiler/Compiler.cpp diff -u llvm-java/lib/Compiler/Compiler.cpp:1.170 llvm-java/lib/Compiler/Compiler.cpp:1.171 --- llvm-java/lib/Compiler/Compiler.cpp:1.170 Mon Dec 6 02:10:29 2004 +++ llvm-java/lib/Compiler/Compiler.cpp Tue Dec 7 03:04:16 2004 @@ -114,6 +114,7 @@ typedef std::map Method2IndexMap; Method2IndexMap m2iMap; + static Type* VTableBaseTy; static StructType* VTableTy; static StructType* TypeInfoTy; }; @@ -419,6 +420,8 @@ PATypeHolder holder = VTtype; cast(VTtype)->refineAbstractTypeTo(StructType::get(elements)); + VTableInfo::VTableBaseTy = OpaqueType::get(); + module_.addTypeName(LLVM_JAVA_OBJECT_VTABLE, VTableInfo::VTableBaseTy); VTableInfo::VTableTy = cast(holder.get()); module_.addTypeName("java/lang/Object", VTableInfo::VTableTy); @@ -2104,7 +2107,7 @@ new CastInst(objRef, PointerType::get(ClassInfo::ObjectBaseTy), TMP, currentBB_); Function* f = module_.getOrInsertFunction( - LLVM_JAVA_GETOBJECTCLASS, PointerType::get(VTableInfo::VTableTy), + LLVM_JAVA_GETOBJECTCLASS, PointerType::get(VTableInfo::VTableBaseTy), objBase->getType(), NULL); Value* vtable = new CallInst(f, objBase, TMP, currentBB_); vtable = new CastInst(vtable, vi->vtable->getType(), @@ -2188,9 +2191,11 @@ new CastInst(objRef, PointerType::get(ClassInfo::ObjectBaseTy), TMP, currentBB_); Function* f = module_.getOrInsertFunction( - LLVM_JAVA_GETOBJECTCLASS, PointerType::get(VTableInfo::VTableTy), + LLVM_JAVA_GETOBJECTCLASS, PointerType::get(VTableInfo::VTableBaseTy), objBase->getType(), NULL); Value* vtable = new CallInst(f, objBase, TMP, currentBB_); + vtable = new CastInst(vtable, PointerType::get(VTableInfo::VTableTy), + TMP, currentBB_); // get the interfaces array of vtables std::vector indices(2, ConstantUInt::get(Type::UIntTy, 0)); indices.push_back(ConstantUInt::get(Type::UIntTy, 3)); @@ -2230,13 +2235,16 @@ Value* objRef = new MallocInst(ci.type, ConstantUInt::get(Type::UIntTy, 0), TMP, currentBB_); - Value* objBase = getField(cf, LLVM_JAVA_OBJECT_BASE, objRef); + Value* objBase = new CastInst(objRef, + PointerType::get(ClassInfo::ObjectBaseTy), + TMP, currentBB_); Value* vtable = new CastInst(vi.vtable, - PointerType::get(VTableInfo::VTableTy), + PointerType::get(VTableInfo::VTableBaseTy), TMP, currentBB_); Function* f = module_.getOrInsertFunction( LLVM_JAVA_SETOBJECTCLASS, Type::VoidTy, - objBase->getType(), PointerType::get(VTableInfo::VTableTy), NULL); + PointerType::get(ClassInfo::ObjectBaseTy), + PointerType::get(VTableInfo::VTableBaseTy), NULL); new CallInst(f, objBase, vtable, "", currentBB_); currentOpStack_->push(objRef, currentBB_); } @@ -2302,13 +2310,16 @@ Value* lengthPtr = getArrayLengthPtr(objRef); new StoreInst(count, lengthPtr, currentBB_); // Install the vtable pointer. - Value* objBase = getArrayObjectBasePtr(objRef); + Value* objBase = new CastInst(objRef, + PointerType::get(ClassInfo::ObjectBaseTy), + TMP, currentBB_); Value* vtable = new CastInst(vi.vtable, - PointerType::get(VTableInfo::VTableTy), + PointerType::get(VTableInfo::VTableBaseTy), TMP, currentBB_); Function* f = module_.getOrInsertFunction( LLVM_JAVA_SETOBJECTCLASS, Type::VoidTy, - objBase->getType(), PointerType::get(VTableInfo::VTableTy), NULL); + PointerType::get(ClassInfo::ObjectBaseTy), + PointerType::get(VTableInfo::VTableBaseTy), NULL); new CallInst(f, objBase, vtable, "", currentBB_); currentOpStack_->push(objRef, currentBB_); } @@ -2329,7 +2340,8 @@ objRef = new CastInst(objRef, PointerType::get(ClassInfo::ObjectBaseTy), TMP, currentBB_); Function* f = module_.getOrInsertFunction( - LLVM_JAVA_THROW, Type::IntTy, objRef->getType(), NULL); + LLVM_JAVA_THROW, Type::IntTy, + PointerType::get(ClassInfo::ObjectBaseTy), NULL); new CallInst(f, objRef, TMP, currentBB_); new UnreachableInst(currentBB_); } @@ -2347,9 +2359,9 @@ TMP, currentBB_); Function* f = module_.getOrInsertFunction( LLVM_JAVA_ISINSTANCEOF, Type::IntTy, - objBase->getType(), PointerType::get(VTableInfo::VTableTy), NULL); + objBase->getType(), PointerType::get(VTableInfo::VTableBaseTy), NULL); Value* vtable = new CastInst(vi->vtable, - PointerType::get(VTableInfo::VTableTy), + PointerType::get(VTableInfo::VTableBaseTy), TMP, currentBB_); Value* r = new CallInst(f, objBase, vtable, TMP, currentBB_); @@ -2375,9 +2387,9 @@ TMP, currentBB_); Function* f = module_.getOrInsertFunction( LLVM_JAVA_ISINSTANCEOF, Type::IntTy, - objBase->getType(), PointerType::get(VTableInfo::VTableTy), NULL); + objBase->getType(), PointerType::get(VTableInfo::VTableBaseTy), NULL); Value* vtable = new CastInst(vi->vtable, - PointerType::get(VTableInfo::VTableTy), + PointerType::get(VTableInfo::VTableBaseTy), TMP, currentBB_); Value* r = new CallInst(f, objBase, vtable, TMP, currentBB_); currentOpStack_->push(r, currentBB_); @@ -2398,6 +2410,7 @@ unsigned Compiler::ClassInfo::InterfaceCount = 0; Type* Compiler::ClassInfo::ObjectBaseTy; + Type* Compiler::VTableInfo::VTableBaseTy; StructType* Compiler::VTableInfo::VTableTy; StructType* Compiler::VTableInfo::TypeInfoTy; From criswell at cs.uiuc.edu Tue Dec 7 10:39:13 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 7 Dec 2004 10:39:13 -0600 Subject: [llvm-commits] CVS: llvm-test/LICENSE.TXT Message-ID: <200412071639.KAA28662@choi.cs.uiuc.edu> Changes in directory llvm-test: LICENSE.TXT updated: 1.3 -> 1.4 --- Log message: Added libpng and zlib license information entries. --- Diffs of the changes: (+2 -0) Index: llvm-test/LICENSE.TXT diff -u llvm-test/LICENSE.TXT:1.3 llvm-test/LICENSE.TXT:1.4 --- llvm-test/LICENSE.TXT:1.3 Thu Sep 16 11:41:31 2004 +++ llvm-test/LICENSE.TXT Tue Dec 7 10:38:58 2004 @@ -92,3 +92,5 @@ SingleSource Tests: llvm-test/SingleSource/Benchmarks/Misc llvm-test/SingleSource/CustomChecked llvm-test/SingleSource/Gizmos +zlib: llvm-test/Runtime/zlib +libpng: llvm-test/Runtime/libpng From alkis at cs.uiuc.edu Tue Dec 7 12:38:14 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Tue, 7 Dec 2004 12:38:14 -0600 Subject: [llvm-commits] CVS: llvm-java/test/Programs/SingleSource/UnitTests/Array.java Makefile Message-ID: <200412071838.MAA11876@zion.cs.uiuc.edu> Changes in directory llvm-java/test/Programs/SingleSource/UnitTests: Array.java added (r1.1) Makefile updated: 1.15 -> 1.16 --- Log message: Add array test. --- Diffs of the changes: (+23 -0) Index: llvm-java/test/Programs/SingleSource/UnitTests/Array.java diff -c /dev/null llvm-java/test/Programs/SingleSource/UnitTests/Array.java:1.1 *** /dev/null Tue Dec 7 12:38:12 2004 --- llvm-java/test/Programs/SingleSource/UnitTests/Array.java Tue Dec 7 12:38:02 2004 *************** *** 0 **** --- 1,22 ---- + public class Array + { + public static void main(String[] args) { + int[] intArray = new int[10]; + + for (int i = 0, e = intArray.length; i != e; ++i) + intArray[i] = intArray.length - i; + + for (int i = 0, e = intArray.length; i != e; ++i) + Test.print_int_ln(intArray[i]); + + + Object[] objectArray = new Object[10]; + + for (int i = 0, e = objectArray.length; i != e; ++i) + objectArray[i] = intArray; + + intArray = (int[]) objectArray[4]; + for (int i = 0, e = intArray.length; i != e; ++i) + Test.print_int_ln(intArray[i]); + } + } Index: llvm-java/test/Programs/SingleSource/UnitTests/Makefile diff -u llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.15 llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.16 --- llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.15 Tue Dec 7 02:33:12 2004 +++ llvm-java/test/Programs/SingleSource/UnitTests/Makefile Tue Dec 7 12:38:02 2004 @@ -9,6 +9,7 @@ LEVEL := ../../../.. JAVA_TESTS := Arithm \ + Array \ BigConstants \ FieldAccess \ FloatCompare \ From alkis at cs.uiuc.edu Tue Dec 7 12:43:08 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Tue, 7 Dec 2004 12:43:08 -0600 Subject: [llvm-commits] CVS: llvm-java/test/Programs/SingleSource/UnitTests/MultiArray.java Makefile Message-ID: <200412071843.MAA11989@zion.cs.uiuc.edu> Changes in directory llvm-java/test/Programs/SingleSource/UnitTests: MultiArray.java added (r1.1) Makefile updated: 1.16 -> 1.17 --- Log message: Add multi array test. --- Diffs of the changes: (+15 -0) Index: llvm-java/test/Programs/SingleSource/UnitTests/MultiArray.java diff -c /dev/null llvm-java/test/Programs/SingleSource/UnitTests/MultiArray.java:1.1 *** /dev/null Tue Dec 7 12:43:07 2004 --- llvm-java/test/Programs/SingleSource/UnitTests/MultiArray.java Tue Dec 7 12:42:57 2004 *************** *** 0 **** --- 1,14 ---- + public class MultiArray + { + public static void main(String[] args) { + int[][] intArray = new int[10][10]; + + for (int i = 0; i != intArray.length; ++i) + for (int j = 0; j != intArray[i].length; ++j) + intArray[i][j] = (j+1) * (i+1); + + for (int i = 0; i != intArray.length; ++i) + for (int j = 0; j != intArray[i].length; ++j) + Test.print_int_ln(intArray[i][j]); + } + } Index: llvm-java/test/Programs/SingleSource/UnitTests/Makefile diff -u llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.16 llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.17 --- llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.16 Tue Dec 7 12:38:02 2004 +++ llvm-java/test/Programs/SingleSource/UnitTests/Makefile Tue Dec 7 12:42:57 2004 @@ -19,6 +19,7 @@ InterfaceCall \ LongCompare \ LookupSwitch \ + MultiArray \ StaticInitializers \ TableSwitch \ VirtualCall \ From lattner at cs.uiuc.edu Tue Dec 7 20:25:47 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 7 Dec 2004 20:25:47 -0600 Subject: [llvm-commits] CVS: llvm/test/Regression/Assembler/2004-12-06-ConstantFloatRange.ll Message-ID: <200412080225.iB82Pl2i005088@apoc.cs.uiuc.edu> Changes in directory llvm/test/Regression/Assembler: 2004-12-06-ConstantFloatRange.ll updated: 1.1 -> 1.2 --- Log message: This test is xfail right now, to keep DJ clean, also mention the PR# in testcases. --- Diffs of the changes: (+3 -0) Index: llvm/test/Regression/Assembler/2004-12-06-ConstantFloatRange.ll diff -u llvm/test/Regression/Assembler/2004-12-06-ConstantFloatRange.ll:1.1 llvm/test/Regression/Assembler/2004-12-06-ConstantFloatRange.ll:1.2 --- llvm/test/Regression/Assembler/2004-12-06-ConstantFloatRange.ll:1.1 Mon Dec 6 15:57:59 2004 +++ llvm/test/Regression/Assembler/2004-12-06-ConstantFloatRange.ll Tue Dec 7 20:25:32 2004 @@ -1,4 +1,7 @@ ; RUN: llvm-as %s -o /dev/null 2>&1 | grep "constant invalid for type" +; XFAIL: * + +;; This is a testcase for PR409 ; make sure that 'float' values are in range From lattner at cs.uiuc.edu Tue Dec 7 21:29:05 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 7 Dec 2004 21:29:05 -0600 Subject: [llvm-commits] CVS: llvm/lib/Linker/LinkModules.cpp Message-ID: <200412080329.iB83T59F013314@apoc.cs.uiuc.edu> Changes in directory llvm/lib/Linker: LinkModules.cpp updated: 1.97 -> 1.98 --- Log message: Add a disgusting hack to work around a libstdc++ issue. This code should be removed when PR400: http://llvm.cs.uiuc.edu/PR400 is resolved. --- Diffs of the changes: (+23 -0) Index: llvm/lib/Linker/LinkModules.cpp diff -u llvm/lib/Linker/LinkModules.cpp:1.97 llvm/lib/Linker/LinkModules.cpp:1.98 --- llvm/lib/Linker/LinkModules.cpp:1.97 Sat Dec 4 12:54:48 2004 +++ llvm/lib/Linker/LinkModules.cpp Tue Dec 7 21:28:51 2004 @@ -425,6 +425,20 @@ return false; } +// Gross hack, see call sites. +static void CoutHack(GlobalVariable *GV1, GlobalVariable *GV2) { + const Type *GV1Ty = GV1->getType()->getElementType(); + const Type *GV2Ty = GV2->getType()->getElementType(); + + if (GV1->isExternal() && isa(GV1Ty) && + GV2->hasInitializer() && GV2->hasExternalLinkage() && + GV2->getInitializer()->isNullValue() && isa(GV2Ty) && + cast(GV2Ty)->getElementType() == Type::SByteTy) { + GV1->setInitializer(Constant::getNullValue(GV1Ty)); + GV2->setInitializer(0); + } +} + // LinkGlobals - Loop through the global variables in the src module and merge // them into the dest module. static bool LinkGlobals(Module *Dest, Module *Src, @@ -459,6 +473,15 @@ assert(SGV->hasInitializer() || SGV->hasExternalLinkage() && "Global must either be external or have an initializer!"); + // This is a gross hack to handle cin/cout until PR400 is implemented. If + // we are linking an external struct against a zero-initialized array of + // sbytes, move the initializer from the array to the struct so we keep the + // struct type. + if (DGV) { + CoutHack(DGV, SGV); + CoutHack(SGV, DGV); + } + GlobalValue::LinkageTypes NewLinkage; bool LinkFromSrc; if (GetLinkageResult(DGV, SGV, NewLinkage, LinkFromSrc, Err)) From lattner at cs.uiuc.edu Tue Dec 7 21:31:27 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 7 Dec 2004 21:31:27 -0600 Subject: [llvm-commits] CVS: llvm/lib/Linker/LinkModules.cpp Message-ID: <200412080331.iB83VRGC013502@apoc.cs.uiuc.edu> Changes in directory llvm/lib/Linker: LinkModules.cpp updated: 1.98 -> 1.99 --- Log message: Revert this disgusting hack, John has a much nicer solution --- Diffs of the changes: (+0 -23) Index: llvm/lib/Linker/LinkModules.cpp diff -u llvm/lib/Linker/LinkModules.cpp:1.98 llvm/lib/Linker/LinkModules.cpp:1.99 --- llvm/lib/Linker/LinkModules.cpp:1.98 Tue Dec 7 21:28:51 2004 +++ llvm/lib/Linker/LinkModules.cpp Tue Dec 7 21:31:14 2004 @@ -425,20 +425,6 @@ return false; } -// Gross hack, see call sites. -static void CoutHack(GlobalVariable *GV1, GlobalVariable *GV2) { - const Type *GV1Ty = GV1->getType()->getElementType(); - const Type *GV2Ty = GV2->getType()->getElementType(); - - if (GV1->isExternal() && isa(GV1Ty) && - GV2->hasInitializer() && GV2->hasExternalLinkage() && - GV2->getInitializer()->isNullValue() && isa(GV2Ty) && - cast(GV2Ty)->getElementType() == Type::SByteTy) { - GV1->setInitializer(Constant::getNullValue(GV1Ty)); - GV2->setInitializer(0); - } -} - // LinkGlobals - Loop through the global variables in the src module and merge // them into the dest module. static bool LinkGlobals(Module *Dest, Module *Src, @@ -473,15 +459,6 @@ assert(SGV->hasInitializer() || SGV->hasExternalLinkage() && "Global must either be external or have an initializer!"); - // This is a gross hack to handle cin/cout until PR400 is implemented. If - // we are linking an external struct against a zero-initialized array of - // sbytes, move the initializer from the array to the struct so we keep the - // struct type. - if (DGV) { - CoutHack(DGV, SGV); - CoutHack(SGV, DGV); - } - GlobalValue::LinkageTypes NewLinkage; bool LinkFromSrc; if (GetLinkageResult(DGV, SGV, NewLinkage, LinkFromSrc, Err)) From alkis at cs.uiuc.edu Tue Dec 7 21:45:30 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Tue, 7 Dec 2004 21:45:30 -0600 Subject: [llvm-commits] CVS: llvm/include/llvm/Constants.h Message-ID: <200412080345.VAA20876@zion.cs.uiuc.edu> Changes in directory llvm/include/llvm: Constants.h updated: 1.64 -> 1.65 --- Log message: Use getOperand() and remove getElementAt() function. --- Diffs of the changes: (+0 -8) Index: llvm/include/llvm/Constants.h diff -u llvm/include/llvm/Constants.h:1.64 llvm/include/llvm/Constants.h:1.65 --- llvm/include/llvm/Constants.h:1.64 Sun Dec 5 14:09:18 2004 +++ llvm/include/llvm/Constants.h Tue Dec 7 21:45:20 2004 @@ -418,14 +418,6 @@ return false; } - Constant* getElementAt(unsigned i) const { - return cast(Operands[i]); - } - - unsigned getNumElements() const { - return Operands.size(); - } - virtual void destroyConstant(); virtual void replaceUsesOfWithOnConstant(Value *From, Value *To, bool DisableChecking = false); From alkis at cs.uiuc.edu Tue Dec 7 21:45:31 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Tue, 7 Dec 2004 21:45:31 -0600 Subject: [llvm-commits] CVS: llvm-java/lib/Compiler/Compiler.cpp Message-ID: <200412080345.VAA20879@zion.cs.uiuc.edu> Changes in directory llvm-java/lib/Compiler: Compiler.cpp updated: 1.171 -> 1.172 --- Log message: Use getOperand() and remove getElementAt() function. --- Diffs of the changes: (+1 -1) Index: llvm-java/lib/Compiler/Compiler.cpp diff -u llvm-java/lib/Compiler/Compiler.cpp:1.171 llvm-java/lib/Compiler/Compiler.cpp:1.172 --- llvm-java/lib/Compiler/Compiler.cpp:1.171 Tue Dec 7 03:04:16 2004 +++ llvm-java/lib/Compiler/Compiler.cpp Tue Dec 7 21:45:19 2004 @@ -621,7 +621,7 @@ "Interface method not found in class definition!"); unsigned classMethodIdx = classVI.m2iMap.find(i->first)->second; init[i->second] = cast( - classVI.vtable->getInitializer())->getElementAt(classMethodIdx); + classVI.vtable->getInitializer())->getOperand(classMethodIdx); } llvm::Constant* vtable = ConstantStruct::get(init); From criswell at cs.uiuc.edu Tue Dec 7 22:08:34 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 7 Dec 2004 22:08:34 -0600 Subject: [llvm-commits] CVS: llvm-gcc/libstdc++-v3/src/globals.cc Message-ID: <200412080408.WAA31201@choi.cs.uiuc.edu> Changes in directory llvm-gcc/libstdc++-v3/src: globals.cc updated: 1.2 -> 1.3 --- Log message: Modify the global variables so that they are arrays of longs and not arrays of chars. This tricks LLVM into assigning alignment to the largest integer on the system (32 bits on i386, 64 bits on Sparc), which prevents Sparc from segfaulting and should help improve i386 performance. Kudos to everyone (Tanya, Brian, Reid, and Chris) who helped bring this bug to a close. --- Diffs of the changes: (+48 -46) Index: llvm-gcc/libstdc++-v3/src/globals.cc diff -u llvm-gcc/libstdc++-v3/src/globals.cc:1.2 llvm-gcc/libstdc++-v3/src/globals.cc:1.3 --- llvm-gcc/libstdc++-v3/src/globals.cc:1.2 Fri Jan 9 10:54:35 2004 +++ llvm-gcc/libstdc++-v3/src/globals.cc Tue Dec 7 22:08:19 2004 @@ -53,11 +53,13 @@ namespace std { +#define lsizeof(a) (((a)+sizeof(long)-1)/sizeof(long)) + // Standard stream objects. // NB: Iff is included, these definitions become wonky. - typedef char fake_istream[sizeof(istream)] + typedef long fake_istream[lsizeof(sizeof(istream)) ] __attribute__ ((aligned(__alignof__(istream)))); - typedef char fake_ostream[sizeof(ostream)] + typedef long fake_ostream[lsizeof(sizeof(ostream)) ] __attribute__ ((aligned(__alignof__(ostream)))); fake_istream cin; fake_ostream cout; @@ -65,9 +67,9 @@ fake_ostream clog; #ifdef _GLIBCXX_USE_WCHAR_T - typedef char fake_wistream[sizeof(wistream)] + typedef long fake_wistream[lsizeof(sizeof(wistream)) ] __attribute__ ((aligned(__alignof__(wistream)))); - typedef char fake_wostream[sizeof(wostream)] + typedef long fake_wostream[lsizeof(sizeof(wostream)) ] __attribute__ ((aligned(__alignof__(wostream)))); fake_wistream wcin; fake_wostream wcout; @@ -82,189 +84,189 @@ // We use different stream buffer types depending on whether // ios_base::sync_with_stdio(false) has been called. - typedef char fake_stdiobuf[sizeof(stdio_sync_filebuf)] + typedef long fake_stdiobuf[lsizeof(sizeof(stdio_sync_filebuf)) ] __attribute__ ((aligned(__alignof__(stdio_sync_filebuf)))); fake_stdiobuf buf_cout_sync; fake_stdiobuf buf_cin_sync; fake_stdiobuf buf_cerr_sync; - typedef char fake_filebuf[sizeof(stdio_filebuf)] + typedef long fake_filebuf[lsizeof(sizeof(stdio_filebuf)) ] __attribute__ ((aligned(__alignof__(stdio_filebuf)))); fake_filebuf buf_cout; fake_filebuf buf_cin; fake_filebuf buf_cerr; #ifdef _GLIBCXX_USE_WCHAR_T - typedef char fake_wstdiobuf[sizeof(stdio_sync_filebuf)] + typedef long fake_wstdiobuf[lsizeof(sizeof(stdio_sync_filebuf)) ] __attribute__ ((aligned(__alignof__(stdio_sync_filebuf)))); fake_wstdiobuf buf_wcout_sync; fake_wstdiobuf buf_wcin_sync; fake_wstdiobuf buf_wcerr_sync; - typedef char fake_wfilebuf[sizeof(stdio_filebuf)] + typedef long fake_wfilebuf[lsizeof(sizeof(stdio_filebuf)) ] __attribute__ ((aligned(__alignof__(stdio_filebuf)))); fake_wfilebuf buf_wcout; fake_wfilebuf buf_wcin; fake_wfilebuf buf_wcerr; #endif - typedef char fake_locale_Impl[sizeof(locale::_Impl)] + typedef long fake_locale_Impl[lsizeof(sizeof(locale::_Impl)) ] __attribute__ ((aligned(__alignof__(locale::_Impl)))); fake_locale_Impl c_locale_impl; - typedef char fake_locale[sizeof(locale)] + typedef long fake_locale[lsizeof(sizeof(locale)) ] __attribute__ ((aligned(__alignof__(locale)))); fake_locale c_locale; - typedef char fake_name_vec[sizeof(char*)] + typedef long fake_name_vec[lsizeof(sizeof(char*)) ] __attribute__ ((aligned(__alignof__(char*)))); fake_name_vec name_vec[6 + _GLIBCXX_NUM_CATEGORIES]; - typedef char fake_names[sizeof(char[2])] + typedef long fake_names[lsizeof(sizeof(char[2])) ] __attribute__ ((aligned(__alignof__(char[2])))); fake_names name_c[6 + _GLIBCXX_NUM_CATEGORIES]; - typedef char fake_facet_vec[sizeof(locale::facet*)] + typedef long fake_facet_vec[lsizeof(sizeof(locale::facet*)) ] __attribute__ ((aligned(__alignof__(locale::facet*)))); fake_facet_vec facet_vec[_GLIBCXX_NUM_FACETS]; - typedef char fake_cache_vec[sizeof(locale::facet*)] + typedef long fake_cache_vec[lsizeof(sizeof(locale::facet*)) ] __attribute__ ((aligned(__alignof__(locale::facet*)))); fake_cache_vec cache_vec[_GLIBCXX_NUM_FACETS]; - typedef char fake_ctype_c[sizeof(std::ctype)] + typedef long fake_ctype_c[lsizeof(sizeof(std::ctype)) ] __attribute__ ((aligned(__alignof__(std::ctype)))); fake_ctype_c ctype_c; - typedef char fake_collate_c[sizeof(std::collate)] + typedef long fake_collate_c[lsizeof(sizeof(std::collate)) ] __attribute__ ((aligned(__alignof__(std::collate)))); fake_collate_c collate_c; - typedef char fake_numpunct_c[sizeof(numpunct)] + typedef long fake_numpunct_c[lsizeof(sizeof (numpunct)) ] __attribute__ ((aligned(__alignof__(numpunct)))); fake_numpunct_c numpunct_c; - typedef char fake_num_get_c[sizeof(num_get)] + typedef long fake_num_get_c[lsizeof(sizeof (num_get)) ] __attribute__ ((aligned(__alignof__(num_get)))); fake_num_get_c num_get_c; - typedef char fake_num_put_c[sizeof(num_put)] + typedef long fake_num_put_c[lsizeof(sizeof(num_put)) ] __attribute__ ((aligned(__alignof__(num_put)))); fake_num_put_c num_put_c; - typedef char fake_codecvt_c[sizeof(codecvt)] + typedef long fake_codecvt_c[lsizeof(sizeof(codecvt)) ] __attribute__ ((aligned(__alignof__(codecvt)))); fake_codecvt_c codecvt_c; - typedef char fake_moneypunct_c[sizeof(moneypunct)] + typedef long fake_moneypunct_c[lsizeof(sizeof(moneypunct)) ] __attribute__ ((aligned(__alignof__(moneypunct)))); fake_moneypunct_c moneypunct_ct; fake_moneypunct_c moneypunct_cf; - typedef char fake_money_get_c[sizeof(money_get)] + typedef long fake_money_get_c[lsizeof(sizeof(money_get)) ] __attribute__ ((aligned(__alignof__(money_get)))); fake_money_get_c money_get_c; - typedef char fake_money_put_c[sizeof(money_put)] + typedef long fake_money_put_c[lsizeof(sizeof(money_put)) ] __attribute__ ((aligned(__alignof__(money_put)))); fake_money_put_c money_put_c; - typedef char fake_timepunct_c[sizeof(__timepunct)] + typedef long fake_timepunct_c[lsizeof(sizeof(__timepunct)) ] __attribute__ ((aligned(__alignof__(__timepunct)))); fake_timepunct_c timepunct_c; - typedef char fake_time_get_c[sizeof(time_get)] + typedef long fake_time_get_c[lsizeof(sizeof(time_get)) ] __attribute__ ((aligned(__alignof__(time_get)))); fake_time_get_c time_get_c; - typedef char fake_time_put_c[sizeof(time_put)] + typedef long fake_time_put_c[lsizeof(sizeof (time_put)) ] __attribute__ ((aligned(__alignof__(time_put)))); fake_time_put_c time_put_c; - typedef char fake_messages_c[sizeof(messages)] + typedef long fake_messages_c[lsizeof(sizeof (messages)) ] __attribute__ ((aligned(__alignof__(messages)))); fake_messages_c messages_c; #ifdef _GLIBCXX_USE_WCHAR_T - typedef char fake_wtype_w[sizeof(std::ctype)] + typedef long fake_wtype_w[lsizeof(sizeof (std::ctype)) ] __attribute__ ((aligned(__alignof__(std::ctype)))); fake_wtype_w ctype_w; - typedef char fake_wollate_w[sizeof(std::collate)] + typedef long fake_wollate_w[lsizeof(sizeof (std::collate)) ] __attribute__ ((aligned(__alignof__(std::collate)))); fake_wollate_w collate_w; - typedef char fake_numpunct_w[sizeof(numpunct)] + typedef long fake_numpunct_w[lsizeof(sizeof (numpunct)) ] __attribute__ ((aligned(__alignof__(numpunct)))); fake_numpunct_w numpunct_w; - typedef char fake_num_get_w[sizeof(num_get)] + typedef long fake_num_get_w[lsizeof(sizeof (num_get)) ] __attribute__ ((aligned(__alignof__(num_get)))); fake_num_get_w num_get_w; - typedef char fake_num_put_w[sizeof(num_put)] + typedef long fake_num_put_w[lsizeof(sizeof (num_put)) ] __attribute__ ((aligned(__alignof__(num_put)))); fake_num_put_w num_put_w; - typedef char fake_wodecvt_w[sizeof(codecvt)] + typedef long fake_wodecvt_w[lsizeof(sizeof (codecvt)) ] __attribute__ ((aligned(__alignof__(codecvt)))); fake_wodecvt_w codecvt_w; - typedef char fake_moneypunct_w[sizeof(moneypunct)] + typedef long fake_moneypunct_w[lsizeof(sizeof (moneypunct)) ] __attribute__ ((aligned(__alignof__(moneypunct)))); fake_moneypunct_w moneypunct_wt; fake_moneypunct_w moneypunct_wf; - typedef char fake_money_get_w[sizeof(money_get)] + typedef long fake_money_get_w[lsizeof(sizeof (money_get)) ] __attribute__ ((aligned(__alignof__(money_get)))); fake_money_get_w money_get_w; - typedef char fake_money_put_w[sizeof(money_put)] + typedef long fake_money_put_w[lsizeof(sizeof (money_put)) ] __attribute__ ((aligned(__alignof__(money_put)))); fake_money_put_w money_put_w; - typedef char fake_timepunct_w[sizeof(__timepunct)] + typedef long fake_timepunct_w[lsizeof(sizeof (__timepunct)) ] __attribute__ ((aligned(__alignof__(__timepunct)))); fake_timepunct_w timepunct_w; - typedef char fake_time_get_w[sizeof(time_get)] + typedef long fake_time_get_w[lsizeof(sizeof (time_get)) ] __attribute__ ((aligned(__alignof__(time_get)))); fake_time_get_w time_get_w; - typedef char fake_time_put_w[sizeof(time_put)] + typedef long fake_time_put_w[lsizeof(sizeof (time_put)) ] __attribute__ ((aligned(__alignof__(time_put)))); fake_time_put_w time_put_w; - typedef char fake_messages_w[sizeof(messages)] + typedef long fake_messages_w[lsizeof(sizeof (messages)) ] __attribute__ ((aligned(__alignof__(messages)))); fake_messages_w messages_w; #endif // Storage for "C" locale caches. - typedef char fake_num_cache_c[sizeof(std::__numpunct_cache)] + typedef long fake_num_cache_c[lsizeof(sizeof (std::__numpunct_cache)) ] __attribute__ ((aligned(__alignof__(std::__numpunct_cache)))); fake_num_cache_c numpunct_cache_c; - typedef char fake_money_cache_c[sizeof(std::__moneypunct_cache)] + typedef long fake_money_cache_c[lsizeof(sizeof (std::__moneypunct_cache)) ] __attribute__ ((aligned(__alignof__(std::__moneypunct_cache)))); fake_money_cache_c moneypunct_cache_ct; fake_money_cache_c moneypunct_cache_cf; - typedef char fake_time_cache_c[sizeof(std::__timepunct_cache)] + typedef long fake_time_cache_c[lsizeof(sizeof (std::__timepunct_cache)) ] __attribute__ ((aligned(__alignof__(std::__timepunct_cache)))); fake_time_cache_c timepunct_cache_c; #ifdef _GLIBCXX_USE_WCHAR_T - typedef char fake_num_cache_w[sizeof(std::__numpunct_cache)] + typedef long fake_num_cache_w[lsizeof(sizeof (std::__numpunct_cache)) ] __attribute__ ((aligned(__alignof__(std::__numpunct_cache)))); fake_num_cache_w numpunct_cache_w; - typedef char fake_money_cache_w[sizeof(std::__moneypunct_cache)] + typedef long fake_money_cache_w[lsizeof(sizeof (std::__moneypunct_cache)) ] __attribute__ ((aligned(__alignof__(std::__moneypunct_cache)))); fake_money_cache_w moneypunct_cache_wt; fake_money_cache_w moneypunct_cache_wf; - typedef char fake_time_cache_w[sizeof(std::__timepunct_cache)] + typedef long fake_time_cache_w[lsizeof(sizeof (std::__timepunct_cache)) ] __attribute__ ((aligned(__alignof__(std::__timepunct_cache)))); fake_time_cache_w timepunct_cache_w; #endif From reid at x10sys.com Tue Dec 7 22:22:58 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 22:22:58 -0600 Subject: [llvm-commits] CVS: llvm/runtime/GCCLibraries/crtend/Makefile Message-ID: <200412080422.WAA21552@zion.cs.uiuc.edu> Changes in directory llvm/runtime/GCCLibraries/crtend: Makefile updated: 1.24 -> 1.25 --- Log message: Remove useless -L switch now that gccld -link-as-library bug is fixed. --- Diffs of the changes: (+3 -3) Index: llvm/runtime/GCCLibraries/crtend/Makefile diff -u llvm/runtime/GCCLibraries/crtend/Makefile:1.24 llvm/runtime/GCCLibraries/crtend/Makefile:1.25 --- llvm/runtime/GCCLibraries/crtend/Makefile:1.24 Sun Dec 5 13:15:06 2004 +++ llvm/runtime/GCCLibraries/crtend/Makefile Tue Dec 7 22:22:47 2004 @@ -47,18 +47,18 @@ $(Echo) Linking $(notdir $@) component... $(Verb) $(GCCLD) -link-as-library \ -internalize-public-api-file=$(BUILD_SRC_DIR)/comp_main.lst \ - $(MainObj) -o $@ -L$(LLVMGCCStdCXXLibDir) + $(MainObj) -o $@ # Generic exception handling support runtime. $(ObjDir)/comp_genericeh.bc: $(GenericEHObj) $(Echo) Linking $(notdir $@) component... $(Verb) $(GCCLD) -link-as-library \ -internalize-public-api-file=$(BUILD_SRC_DIR)/comp_genericeh.lst \ - $(GenericEHObj) -o $@ -L$(LLVMGCCStdCXXLibDir) + $(GenericEHObj) -o $@ # setjmp/longjmp exception handling support runtime. $(ObjDir)/comp_sjljeh.bc: $(SJLJEHObj) $(Echo) Linking $(notdir $@) component... $(Verb) $(GCCLD) -link-as-library \ -internalize-public-api-file=$(BUILD_SRC_DIR)/comp_sjljeh.lst \ - $(SJLJEHObj) -o $@ -L$(LLVMGCCStdCXXLibDir) + $(SJLJEHObj) -o $@ From reid at x10sys.com Tue Dec 7 22:26:35 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 22:26:35 -0600 Subject: [llvm-commits] CVS: llvm/Makefile.rules Message-ID: <200412080426.WAA21670@zion.cs.uiuc.edu> Changes in directory llvm: Makefile.rules updated: 1.253 -> 1.254 --- Log message: Remove variables that are not used by any of the LLVM makefiles --- Diffs of the changes: (+7 -7) Index: llvm/Makefile.rules diff -u llvm/Makefile.rules:1.253 llvm/Makefile.rules:1.254 --- llvm/Makefile.rules:1.253 Sun Dec 5 23:35:13 2004 +++ llvm/Makefile.rules Tue Dec 7 22:26:23 2004 @@ -146,20 +146,24 @@ # Variables derived from configuration we are building #-------------------------------------------------------------------- +CommonCXXOpts := -Woverloaded-virtual + ifdef ENABLE_PROFILING BuildMode := Profile - CXX.Flags := -O3 -DNDEBUG -felide-constructors -finline-functions -pg + CXX.Flags := -O3 -DNDEBUG $(CommonCXXOpts) -felide-constructors \ + -finline-functions -pg C.Flags := -O3 -DNDEBUG -pg LD.Flags := -O3 -DNDEBUG -pg else ifdef ENABLE_OPTIMIZED BuildMode := Release - CXX.Flags := -O3 -DNDEBUG -finline-functions -felide-constructors -fomit-frame-pointer + CXX.Flags := -O3 -DNDEBUG $(CommonCXXOpts) -finline-functions \ + -felide-constructors -fomit-frame-pointer C.Flags := -O3 -DNDEBUG -fomit-frame-pointer LD.Flags := -O3 -DNDEBUG else BuildMode := Debug - CXX.Flags := -g -D_DEBUG + CXX.Flags := -g -D_DEBUG $(CommonCXXOpts) C.Flags := -g -D_DEBUG LD.Flags := -g -D_DEBUG KEEP_SYMBOLS := 1 @@ -214,10 +218,6 @@ LLVMGXX := PATH=$(LLVMToolDir):$(PATH) $(LLVMGCCDIR)/bin/g++ endif -# Need a better way to compute this. -LLVMGCCLibDir := $(dir $(shell $(LLVMGCC) -print-file-name=libgcc.a))/ -LLVMGCCStdCXXLibDir := $(dir $(shell $(LLVMGCC) -print-file-name=libstdc++.a))/ - #-------------------------------------------------------------------- # Adjust to user's request #-------------------------------------------------------------------- From reid at x10sys.com Tue Dec 7 22:26:35 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 22:26:35 -0600 Subject: [llvm-commits] CVS: llvm/docs/MakefileGuide.html Message-ID: <200412080426.WAA21671@zion.cs.uiuc.edu> Changes in directory llvm/docs: MakefileGuide.html updated: 1.19 -> 1.20 --- Log message: Remove variables that are not used by any of the LLVM makefiles --- Diffs of the changes: (+1 -3) Index: llvm/docs/MakefileGuide.html diff -u llvm/docs/MakefileGuide.html:1.19 llvm/docs/MakefileGuide.html:1.20 --- llvm/docs/MakefileGuide.html:1.19 Sun Dec 5 23:35:25 2004 +++ llvm/docs/MakefileGuide.html Tue Dec 7 22:26:23 2004 @@ -906,8 +906,6 @@ LibTool.Flags Link LinkModule - LLVMGCCLibDir - LLVMGCCStdCXXLibDir LLVMLibDir LLVMLibsOptions LLVMLibsPaths @@ -953,7 +951,7 @@ Reid Spencer
      The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/12/06 05:35:25 $ + Last modified: $Date: 2004/12/08 04:26:23 $ From reid at x10sys.com Tue Dec 7 22:35:01 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 22:35:01 -0600 Subject: [llvm-commits] CVS: llvm/Makefile.rules Message-ID: <200412080435.WAA21813@zion.cs.uiuc.edu> Changes in directory llvm: Makefile.rules updated: 1.254 -> 1.255 --- Log message: Remove -Woverloaded-virtual usage that was committed by accident. --- Diffs of the changes: (+3 -6) Index: llvm/Makefile.rules diff -u llvm/Makefile.rules:1.254 llvm/Makefile.rules:1.255 --- llvm/Makefile.rules:1.254 Tue Dec 7 22:26:23 2004 +++ llvm/Makefile.rules Tue Dec 7 22:34:51 2004 @@ -146,24 +146,21 @@ # Variables derived from configuration we are building #-------------------------------------------------------------------- -CommonCXXOpts := -Woverloaded-virtual - ifdef ENABLE_PROFILING BuildMode := Profile - CXX.Flags := -O3 -DNDEBUG $(CommonCXXOpts) -felide-constructors \ - -finline-functions -pg + CXX.Flags := -O3 -DNDEBUG -felide-constructors -finline-functions -pg C.Flags := -O3 -DNDEBUG -pg LD.Flags := -O3 -DNDEBUG -pg else ifdef ENABLE_OPTIMIZED BuildMode := Release - CXX.Flags := -O3 -DNDEBUG $(CommonCXXOpts) -finline-functions \ + CXX.Flags := -O3 -DNDEBUG -finline-functions \ -felide-constructors -fomit-frame-pointer C.Flags := -O3 -DNDEBUG -fomit-frame-pointer LD.Flags := -O3 -DNDEBUG else BuildMode := Debug - CXX.Flags := -g -D_DEBUG $(CommonCXXOpts) + CXX.Flags := -g -D_DEBUG C.Flags := -g -D_DEBUG LD.Flags := -g -D_DEBUG KEEP_SYMBOLS := 1 From reid at x10sys.com Tue Dec 7 22:43:50 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 22:43:50 -0600 Subject: [llvm-commits] CVS: llvm/docs/CommandGuide/Makefile Message-ID: <200412080443.WAA22021@zion.cs.uiuc.edu> Changes in directory llvm/docs/CommandGuide: Makefile updated: 1.7 -> 1.8 --- Log message: Make an alternate version of this Makefile that can be used in an unconfigured tree for rebuilding the html files from POD sources for the website update on cvs commit. --- Diffs of the changes: (+20 -0) Index: llvm/docs/CommandGuide/Makefile diff -u llvm/docs/CommandGuide/Makefile:1.7 llvm/docs/CommandGuide/Makefile:1.8 --- llvm/docs/CommandGuide/Makefile:1.7 Mon Nov 29 08:46:29 2004 +++ llvm/docs/CommandGuide/Makefile Tue Dec 7 22:43:40 2004 @@ -7,6 +7,24 @@ # ##===----------------------------------------------------------------------===## +ifdef BUILD_FOR_WEBSITE +# This special case is for keeping the CommandGuide on the LLVM web site +# up to date automatically as the documents are checked in. It must build +# the POD files to HTML only and keep them in the src directories. It must also +# build in an unconfigured tree, hence the ifdef. To use this, run +# make -s BUILD_FOR_WEBSITE=1 inside the cvs commit script. + +POD := $(wildcard *.pod) +HTML := $(patsubst %.pod,html/%.html, $(POD)) + +all: $(HTML) + +html/%.html : %.pod + pod2html --css=manpage.css --htmlroot=. --podpath=. \ + --noindex --infile=$< --outfile=$@ --title=$* + +else + LEVEL := ../.. include $(LEVEL)/Makefile.common @@ -62,3 +80,5 @@ printvars:: $(Echo) "POD : " '$(POD)' $(Echo) "HTML : " '$(HTML)' + +endif From reid at x10sys.com Tue Dec 7 23:17:51 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 23:17:51 -0600 Subject: [llvm-commits] CVS: llvm/tools/gccld/gccld.cpp Message-ID: <200412080517.XAA22264@zion.cs.uiuc.edu> Changes in directory llvm/tools/gccld: gccld.cpp updated: 1.83 -> 1.84 --- Log message: When -link-as-library, add -l options to Module's deplibs --- Diffs of the changes: (+8 -1) Index: llvm/tools/gccld/gccld.cpp diff -u llvm/tools/gccld/gccld.cpp:1.83 llvm/tools/gccld/gccld.cpp:1.84 --- llvm/tools/gccld/gccld.cpp:1.83 Sun Dec 5 13:15:17 2004 +++ llvm/tools/gccld/gccld.cpp Tue Dec 7 23:17:40 2004 @@ -176,10 +176,17 @@ std::auto_ptr Composite(0); if (LinkAsLibrary) { - // Link in only the files, we ignore libraries in this case. + // Link in only the files. Composite.reset( new Module(argv[0]) ); if (LinkFiles(argv[0], Composite.get(), InputFilenames, Verbose)) return 1; // Error already printed + // The libraries aren't linked in but are noted as "dependent" in the + // module. + for (cl::list::const_iterator I = Libraries.begin(), + E = Libraries.end(); I != E ; ++I) { + Composite.get()->addLibrary(*I); + } + } else { // Build a list of the items from our command line LinkItemList Items; From reid at x10sys.com Tue Dec 7 23:17:51 2004 From: reid at x10sys.com (Reid Spencer) Date: Tue, 7 Dec 2004 23:17:51 -0600 Subject: [llvm-commits] CVS: llvm/tools/llvm-ld/llvm-ld.cpp Message-ID: <200412080517.XAA22267@zion.cs.uiuc.edu> Changes in directory llvm/tools/llvm-ld: llvm-ld.cpp updated: 1.6 -> 1.7 --- Log message: When -link-as-library, add -l options to Module's deplibs --- Diffs of the changes: (+8 -1) Index: llvm/tools/llvm-ld/llvm-ld.cpp diff -u llvm/tools/llvm-ld/llvm-ld.cpp:1.6 llvm/tools/llvm-ld/llvm-ld.cpp:1.7 --- llvm/tools/llvm-ld/llvm-ld.cpp:1.6 Sun Dec 5 13:15:29 2004 +++ llvm/tools/llvm-ld/llvm-ld.cpp Tue Dec 7 23:17:40 2004 @@ -397,10 +397,17 @@ std::auto_ptr Composite(0); if (LinkAsLibrary) { - // Link in only the files, we ignore libraries in this case. + // Link in only the files. Composite.reset( new Module(argv[0]) ); if (LinkFiles(argv[0], Composite.get(), InputFilenames, Verbose)) return 1; // Error already printed + + // The libraries aren't linked in but are noted as "dependent" in the + // module. + for (cl::list::const_iterator I = Libraries.begin(), + E = Libraries.end(); I != E ; ++I) { + Composite.get()->addLibrary(*I); + } } else { // Build a list of the items from our command line LinkItemList Items; From brukman at cs.uiuc.edu Tue Dec 7 23:44:12 2004 From: brukman at cs.uiuc.edu (Misha Brukman) Date: Tue, 7 Dec 2004 23:44:12 -0600 Subject: [llvm-commits] CVS: CVSROOT/update-www.sh Message-ID: <200412080544.XAA22767@zion.cs.uiuc.edu> Changes in directory CVSROOT: update-www.sh updated: 1.5 -> 1.6 --- Log message: Use the variable Reid added to build website docs without having a configured LLVM tree to make HTML version of the tools documentation --- Diffs of the changes: (+1 -1) Index: CVSROOT/update-www.sh diff -u CVSROOT/update-www.sh:1.5 CVSROOT/update-www.sh:1.6 --- CVSROOT/update-www.sh:1.5 Fri Jul 2 10:43:24 2004 +++ CVSROOT/update-www.sh Tue Dec 7 23:44:01 2004 @@ -11,7 +11,7 @@ # Make the HTML docs from POD source cd /home/vadve/shared/llvm-wwwroot/docs/CommandGuide -make -s +make -s BUILD_FOR_WEBSITE=1 # Give access to any of the files we just checked in to the group find . -user $USER -exec chmod g+w {} \; From alkis at cs.uiuc.edu Wed Dec 8 00:32:25 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Wed, 8 Dec 2004 00:32:25 -0600 Subject: [llvm-commits] CVS: llvm-java/Makefile.common.in Message-ID: <200412080632.AAA23746@zion.cs.uiuc.edu> Changes in directory llvm-java: Makefile.common.in updated: 1.4 -> 1.5 --- Log message: Build system cleanups. --- Diffs of the changes: (+0 -2) Index: llvm-java/Makefile.common.in diff -u llvm-java/Makefile.common.in:1.4 llvm-java/Makefile.common.in:1.5 --- llvm-java/Makefile.common.in:1.4 Thu Sep 16 09:13:18 2004 +++ llvm-java/Makefile.common.in Wed Dec 8 00:32:14 2004 @@ -38,7 +38,6 @@ # # Additional utilities # -JIKES=@JIKES@ JAVAC=@JAVAC@ JAVA=@JAVA@ @@ -46,4 +45,3 @@ # Include local build rules. # include $(BUILD_SRC_ROOT)/Makefile.rules - From alkis at cs.uiuc.edu Wed Dec 8 00:32:25 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Wed, 8 Dec 2004 00:32:25 -0600 Subject: [llvm-commits] CVS: llvm-java/autoconf/configure.ac Message-ID: <200412080632.AAA23743@zion.cs.uiuc.edu> Changes in directory llvm-java/autoconf: configure.ac updated: 1.9 -> 1.10 --- Log message: Build system cleanups. --- Diffs of the changes: (+12 -1) Index: llvm-java/autoconf/configure.ac diff -u llvm-java/autoconf/configure.ac:1.9 llvm-java/autoconf/configure.ac:1.10 --- llvm-java/autoconf/configure.ac:1.9 Tue Dec 7 01:06:12 2004 +++ llvm-java/autoconf/configure.ac Wed Dec 8 00:32:14 2004 @@ -34,10 +34,21 @@ dnl ************************************************************************** dnl * Check for programs. dnl ************************************************************************** -AC_CHECK_PROG(JIKES, jikes, jikes) +AC_ARG_VAR(JAVAC, [The java compiler (used for testing)]) AC_CHECK_PROG(JAVAC, javac, javac) +AC_ARG_VAR(JAVA, [The Java Virtual Machine (used for testing)]) AC_CHECK_PROG(JAVA, java, java) +if test -z "$JAVA" +then + AC_MSG_WARN([A Java Virtual Machine is required for the test suite, but it was not found]) +fi + +if test -z "$JAVAC" +then + AC_MSG_WARN([A Java compiler is required for the test suite, but it was not found]) +fi + dnl Verify that the source directory is valid AC_CONFIG_SRCDIR(Makefile.common.in) From alkis at cs.uiuc.edu Wed Dec 8 00:34:01 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Wed, 8 Dec 2004 00:34:01 -0600 Subject: [llvm-commits] CVS: llvm-java/configure Message-ID: <200412080634.AAA07078@niobe.cs.uiuc.edu> Changes in directory llvm-java: configure updated: 1.7 -> 1.8 --- Log message: Regenate configure --- Diffs of the changes: (+29 -36) Index: llvm-java/configure diff -u llvm-java/configure:1.7 llvm-java/configure:1.8 --- llvm-java/configure:1.7 Tue Dec 7 01:06:12 2004 +++ llvm-java/configure Wed Dec 8 00:33:46 2004 @@ -274,7 +274,7 @@ PACKAGE_BUGREPORT='llvmbugs at cs.uiuc.edu' ac_unique_file="Makefile.common.in" -ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS JIKES JAVAC JAVA LLVM_SRC LLVM_OBJ LIBOBJS LTLIBOBJS' +ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS JAVAC JAVA LLVM_SRC LLVM_OBJ LIBOBJS LTLIBOBJS' ac_subst_files='' # Initialize some variables set by options. @@ -715,6 +715,14 @@ ac_env_target_alias_value=$target_alias ac_cv_env_target_alias_set=${target_alias+set} ac_cv_env_target_alias_value=$target_alias +ac_env_JAVAC_set=${JAVAC+set} +ac_env_JAVAC_value=$JAVAC +ac_cv_env_JAVAC_set=${JAVAC+set} +ac_cv_env_JAVAC_value=$JAVAC +ac_env_JAVA_set=${JAVA+set} +ac_env_JAVA_value=$JAVA +ac_cv_env_JAVA_set=${JAVA+set} +ac_cv_env_JAVA_value=$JAVA # # Report the --help message. @@ -790,6 +798,13 @@ --with-llvmsrc Location of LLVM Source Code --with-llvmobj Location of LLVM Object Code +Some influential environment variables: + JAVAC The java compiler (used for testing) + JAVA The Java Virtual Machine (used for testing) + +Use these variables to override the choices made by `configure' or to help +it to find libraries and programs with nonstandard names/locations. + Report bugs to . _ACEOF fi @@ -1309,40 +1324,6 @@ -# Extract the first word of "jikes", so it can be a program name with args. -set dummy jikes; ac_word=$2 -echo "$as_me:$LINENO: checking for $ac_word" >&5 -echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 -if test "${ac_cv_prog_JIKES+set}" = set; then - echo $ECHO_N "(cached) $ECHO_C" >&6 -else - if test -n "$JIKES"; then - ac_cv_prog_JIKES="$JIKES" # Let the user override the test. -else -as_save_IFS=$IFS; IFS=$PATH_SEPARATOR -for as_dir in $PATH -do - IFS=$as_save_IFS - test -z "$as_dir" && as_dir=. - for ac_exec_ext in '' $ac_executable_extensions; do - if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then - ac_cv_prog_JIKES="jikes" - echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 - break 2 - fi -done -done - -fi -fi -JIKES=$ac_cv_prog_JIKES -if test -n "$JIKES"; then - echo "$as_me:$LINENO: result: $JIKES" >&5 -echo "${ECHO_T}$JIKES" >&6 -else - echo "$as_me:$LINENO: result: no" >&5 -echo "${ECHO_T}no" >&6 -fi # Extract the first word of "javac", so it can be a program name with args. set dummy javac; ac_word=$2 @@ -1379,6 +1360,7 @@ echo "${ECHO_T}no" >&6 fi + # Extract the first word of "java", so it can be a program name with args. set dummy java; ac_word=$2 echo "$as_me:$LINENO: checking for $ac_word" >&5 @@ -1415,6 +1397,18 @@ fi +if test -z "$JAVA" +then + { echo "$as_me:$LINENO: WARNING: A Java Virtual Machine is required for the test suite, but it was not found" >&5 +echo "$as_me: WARNING: A Java Virtual Machine is required for the test suite, but it was not found" >&2;} +fi + +if test -z "$JAVAC" +then + { echo "$as_me:$LINENO: WARNING: A Java compiler is required for the test suite, but it was not found" >&5 +echo "$as_me: WARNING: A Java compiler is required for the test suite, but it was not found" >&2;} +fi + @@ -2115,7 +2109,6 @@ s, at ECHO_N@,$ECHO_N,;t t s, at ECHO_T@,$ECHO_T,;t t s, at LIBS@,$LIBS,;t t -s, at JIKES@,$JIKES,;t t s, at JAVAC@,$JAVAC,;t t s, at JAVA@,$JAVA,;t t s, at LLVM_SRC@,$LLVM_SRC,;t t From alkis at cs.uiuc.edu Wed Dec 8 00:37:48 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Wed, 8 Dec 2004 00:37:48 -0600 Subject: [llvm-commits] CVS: llvm-java/test/Programs/SingleSource/UnitTests/Makefile Message-ID: <200412080637.AAA23910@zion.cs.uiuc.edu> Changes in directory llvm-java/test/Programs/SingleSource/UnitTests: Makefile updated: 1.17 -> 1.18 --- Log message: Find javah executable at configuration time. --- Diffs of the changes: (+1 -1) Index: llvm-java/test/Programs/SingleSource/UnitTests/Makefile diff -u llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.17 llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.18 --- llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.17 Tue Dec 7 12:42:57 2004 +++ llvm-java/test/Programs/SingleSource/UnitTests/Makefile Wed Dec 8 00:37:37 2004 @@ -33,7 +33,7 @@ all:: Test.h Test.h: Output/.compile-java - $(Verb)javah -classpath Output Test + $(Verb)$(JAVAH) -classpath Output Test EXTRA_OBJS = $(LibDir)/libtest.bca From alkis at cs.uiuc.edu Wed Dec 8 00:37:48 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Wed, 8 Dec 2004 00:37:48 -0600 Subject: [llvm-commits] CVS: llvm-java/autoconf/configure.ac Message-ID: <200412080637.AAA23907@zion.cs.uiuc.edu> Changes in directory llvm-java/autoconf: configure.ac updated: 1.10 -> 1.11 --- Log message: Find javah executable at configuration time. --- Diffs of the changes: (+9 -2) Index: llvm-java/autoconf/configure.ac diff -u llvm-java/autoconf/configure.ac:1.10 llvm-java/autoconf/configure.ac:1.11 --- llvm-java/autoconf/configure.ac:1.10 Wed Dec 8 00:32:14 2004 +++ llvm-java/autoconf/configure.ac Wed Dec 8 00:37:37 2004 @@ -34,10 +34,12 @@ dnl ************************************************************************** dnl * Check for programs. dnl ************************************************************************** -AC_ARG_VAR(JAVAC, [The java compiler (used for testing)]) -AC_CHECK_PROG(JAVAC, javac, javac) AC_ARG_VAR(JAVA, [The Java Virtual Machine (used for testing)]) AC_CHECK_PROG(JAVA, java, java) +AC_ARG_VAR(JAVAC, [The java compiler (used for testing)]) +AC_CHECK_PROG(JAVAC, javac, javac) +AC_ARG_VAR(JAVAH, [The java JNI header generator (used for testing)]) +AC_CHECK_PROG(JAVAH, javah, javah) if test -z "$JAVA" then @@ -49,6 +51,11 @@ AC_MSG_WARN([A Java compiler is required for the test suite, but it was not found]) fi +if test -z "$JAVAC" +then + AC_MSG_WARN([A Java JNI header generator is required for the test suite, but it was not found]) +fi + dnl Verify that the source directory is valid AC_CONFIG_SRCDIR(Makefile.common.in) From alkis at cs.uiuc.edu Wed Dec 8 00:37:48 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Wed, 8 Dec 2004 00:37:48 -0600 Subject: [llvm-commits] CVS: llvm-java/Makefile.common.in Message-ID: <200412080637.AAA23913@zion.cs.uiuc.edu> Changes in directory llvm-java: Makefile.common.in updated: 1.5 -> 1.6 --- Log message: Find javah executable at configuration time. --- Diffs of the changes: (+2 -1) Index: llvm-java/Makefile.common.in diff -u llvm-java/Makefile.common.in:1.5 llvm-java/Makefile.common.in:1.6 --- llvm-java/Makefile.common.in:1.5 Wed Dec 8 00:32:14 2004 +++ llvm-java/Makefile.common.in Wed Dec 8 00:37:37 2004 @@ -38,8 +38,9 @@ # # Additional utilities # -JAVAC=@JAVAC@ JAVA=@JAVA@ +JAVAC=@JAVAC@ +JAVAH=@JAVAH@ # # Include local build rules. From alkis at cs.uiuc.edu Wed Dec 8 00:38:38 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Wed, 8 Dec 2004 00:38:38 -0600 Subject: [llvm-commits] CVS: llvm-java/configure Message-ID: <200412080638.AAA07998@niobe.cs.uiuc.edu> Changes in directory llvm-java: configure updated: 1.8 -> 1.9 --- Log message: Regenate configure --- Diffs of the changes: (+65 -17) Index: llvm-java/configure diff -u llvm-java/configure:1.8 llvm-java/configure:1.9 --- llvm-java/configure:1.8 Wed Dec 8 00:33:46 2004 +++ llvm-java/configure Wed Dec 8 00:38:19 2004 @@ -274,7 +274,7 @@ PACKAGE_BUGREPORT='llvmbugs at cs.uiuc.edu' ac_unique_file="Makefile.common.in" -ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS JAVAC JAVA LLVM_SRC LLVM_OBJ LIBOBJS LTLIBOBJS' +ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS JAVA JAVAC JAVAH LLVM_SRC LLVM_OBJ LIBOBJS LTLIBOBJS' ac_subst_files='' # Initialize some variables set by options. @@ -715,14 +715,18 @@ ac_env_target_alias_value=$target_alias ac_cv_env_target_alias_set=${target_alias+set} ac_cv_env_target_alias_value=$target_alias -ac_env_JAVAC_set=${JAVAC+set} -ac_env_JAVAC_value=$JAVAC -ac_cv_env_JAVAC_set=${JAVAC+set} -ac_cv_env_JAVAC_value=$JAVAC ac_env_JAVA_set=${JAVA+set} ac_env_JAVA_value=$JAVA ac_cv_env_JAVA_set=${JAVA+set} ac_cv_env_JAVA_value=$JAVA +ac_env_JAVAC_set=${JAVAC+set} +ac_env_JAVAC_value=$JAVAC +ac_cv_env_JAVAC_set=${JAVAC+set} +ac_cv_env_JAVAC_value=$JAVAC +ac_env_JAVAH_set=${JAVAH+set} +ac_env_JAVAH_value=$JAVAH +ac_cv_env_JAVAH_set=${JAVAH+set} +ac_cv_env_JAVAH_value=$JAVAH # # Report the --help message. @@ -799,8 +803,9 @@ --with-llvmobj Location of LLVM Object Code Some influential environment variables: - JAVAC The java compiler (used for testing) JAVA The Java Virtual Machine (used for testing) + JAVAC The java compiler (used for testing) + JAVAH The java JNI header generator (used for testing) Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. @@ -1325,6 +1330,42 @@ +# Extract the first word of "java", so it can be a program name with args. +set dummy java; ac_word=$2 +echo "$as_me:$LINENO: checking for $ac_word" >&5 +echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 +if test "${ac_cv_prog_JAVA+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + if test -n "$JAVA"; then + ac_cv_prog_JAVA="$JAVA" # Let the user override the test. +else +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR +for as_dir in $PATH +do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for ac_exec_ext in '' $ac_executable_extensions; do + if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then + ac_cv_prog_JAVA="java" + echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 + break 2 + fi +done +done + +fi +fi +JAVA=$ac_cv_prog_JAVA +if test -n "$JAVA"; then + echo "$as_me:$LINENO: result: $JAVA" >&5 +echo "${ECHO_T}$JAVA" >&6 +else + echo "$as_me:$LINENO: result: no" >&5 +echo "${ECHO_T}no" >&6 +fi + + # Extract the first word of "javac", so it can be a program name with args. set dummy javac; ac_word=$2 echo "$as_me:$LINENO: checking for $ac_word" >&5 @@ -1361,15 +1402,15 @@ fi -# Extract the first word of "java", so it can be a program name with args. -set dummy java; ac_word=$2 +# Extract the first word of "javah", so it can be a program name with args. +set dummy javah; ac_word=$2 echo "$as_me:$LINENO: checking for $ac_word" >&5 echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 -if test "${ac_cv_prog_JAVA+set}" = set; then +if test "${ac_cv_prog_JAVAH+set}" = set; then echo $ECHO_N "(cached) $ECHO_C" >&6 else - if test -n "$JAVA"; then - ac_cv_prog_JAVA="$JAVA" # Let the user override the test. + if test -n "$JAVAH"; then + ac_cv_prog_JAVAH="$JAVAH" # Let the user override the test. else as_save_IFS=$IFS; IFS=$PATH_SEPARATOR for as_dir in $PATH @@ -1378,7 +1419,7 @@ test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then - ac_cv_prog_JAVA="java" + ac_cv_prog_JAVAH="javah" echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 fi @@ -1387,10 +1428,10 @@ fi fi -JAVA=$ac_cv_prog_JAVA -if test -n "$JAVA"; then - echo "$as_me:$LINENO: result: $JAVA" >&5 -echo "${ECHO_T}$JAVA" >&6 +JAVAH=$ac_cv_prog_JAVAH +if test -n "$JAVAH"; then + echo "$as_me:$LINENO: result: $JAVAH" >&5 +echo "${ECHO_T}$JAVAH" >&6 else echo "$as_me:$LINENO: result: no" >&5 echo "${ECHO_T}no" >&6 @@ -1409,6 +1450,12 @@ echo "$as_me: WARNING: A Java compiler is required for the test suite, but it was not found" >&2;} fi +if test -z "$JAVAC" +then + { echo "$as_me:$LINENO: WARNING: A Java JNI header generator is required for the test suite, but it was not found" >&5 +echo "$as_me: WARNING: A Java JNI header generator is required for the test suite, but it was not found" >&2;} +fi + @@ -2109,8 +2156,9 @@ s, at ECHO_N@,$ECHO_N,;t t s, at ECHO_T@,$ECHO_T,;t t s, at LIBS@,$LIBS,;t t -s, at JAVAC@,$JAVAC,;t t s, at JAVA@,$JAVA,;t t +s, at JAVAC@,$JAVAC,;t t +s, at JAVAH@,$JAVAH,;t t s, at LLVM_SRC@,$LLVM_SRC,;t t s, at LLVM_OBJ@,$LLVM_OBJ,;t t s, at LIBOBJS@,$LIBOBJS,;t t From alkis at cs.uiuc.edu Wed Dec 8 00:56:07 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Wed, 8 Dec 2004 00:56:07 -0600 Subject: [llvm-commits] CVS: llvm-java/test/Programs/SingleSource/UnitTests/Makefile Message-ID: <200412080656.AAA24254@zion.cs.uiuc.edu> Changes in directory llvm-java/test/Programs/SingleSource/UnitTests: Makefile updated: 1.18 -> 1.19 --- Log message: Remove MultiArray test because the multinewarray bytecode is not implemented yet. --- Diffs of the changes: (+3 -2) Index: llvm-java/test/Programs/SingleSource/UnitTests/Makefile diff -u llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.18 llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.19 --- llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.18 Wed Dec 8 00:37:37 2004 +++ llvm-java/test/Programs/SingleSource/UnitTests/Makefile Wed Dec 8 00:55:56 2004 @@ -19,11 +19,12 @@ InterfaceCall \ LongCompare \ LookupSwitch \ - MultiArray \ StaticInitializers \ TableSwitch \ VirtualCall \ - VTable + VTable \ +# MultiArray \ + CPPFLAGS+=-I$(BUILD_SRC_ROOT)/include/llvm/Java BYTECODE_LIBRARY=1 From alkis at cs.uiuc.edu Wed Dec 8 01:06:56 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Wed, 8 Dec 2004 01:06:56 -0600 Subject: [llvm-commits] CVS: llvm-java/lib/ClassFile/ClassFile.cpp Message-ID: <200412080706.BAA31395@niobe.cs.uiuc.edu> Changes in directory llvm-java/lib/ClassFile: ClassFile.cpp updated: 1.29 -> 1.30 --- Log message: Fix crash when CLASSPATH is not in the environment --- Diffs of the changes: (+1 -1) Index: llvm-java/lib/ClassFile/ClassFile.cpp diff -u llvm-java/lib/ClassFile/ClassFile.cpp:1.29 llvm-java/lib/ClassFile/ClassFile.cpp:1.30 --- llvm-java/lib/ClassFile/ClassFile.cpp:1.29 Wed Sep 29 17:31:59 2004 +++ llvm-java/lib/ClassFile/ClassFile.cpp Wed Dec 8 01:06:42 2004 @@ -37,7 +37,7 @@ ClassPath("cp", cl::desc("A : separated list of directories"), cl::value_desc("class search path"), - cl::init(getenv("CLASSPATH"))); + cl::init(getenv("CLASSPATH") ? getenv("CLASSPATH") : "")); static cl::alias ClassPathA("classpath", cl::desc("Alias for -cp"), From alkis at cs.uiuc.edu Wed Dec 8 01:25:23 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Wed, 8 Dec 2004 01:25:23 -0600 Subject: [llvm-commits] CVS: llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll Message-ID: <200412080725.BAA03405@niobe.cs.uiuc.edu> Changes in directory llvm/test/Regression/Transforms/InstCombine: 2004-12-08-InstCombineCrash.ll added (r1.1) --- Log message: Add regression --- Diffs of the changes: (+14 -0) Index: llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll diff -c /dev/null llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll:1.1 *** /dev/null Wed Dec 8 01:25:20 2004 --- llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll Wed Dec 8 01:25:10 2004 *************** *** 0 **** --- 1,14 ---- + ; RUN: llvm-as %s -o - | opt -instcombine + + %struct.llvm_java_object_base = type opaque + "java/lang/Object" = type { %struct.llvm_java_object_base } + "java/lang/StringBuffer" = type { "java/lang/Object", int, { "java/lang/Object", uint, [0 x ushort] }*, bool } + + implementation ; Functions: + + void "java/lang/StringBuffer/append(Ljava/lang/String;)Ljava/lang/StringBuffer;"() { + bc0: + %tmp53 = getelementptr "java/lang/StringBuffer"* null, int 0, uint 1 ; [#uses=1] + store int 0, int* %tmp53 + ret void + } From criswell at cs.uiuc.edu Wed Dec 8 09:30:49 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed, 8 Dec 2004 09:30:49 -0600 Subject: [llvm-commits] [release_14] CVS: llvm-gcc/libstdc++-v3/src/globals.cc Message-ID: <200412081530.JAA03421@choi.cs.uiuc.edu> Changes in directory llvm-gcc/libstdc++-v3/src: globals.cc updated: 1.2 -> 1.2.6.1 --- Log message: Merging critical change into the release branch. This tricks LLVM to aligning these arrays on long boundaries (32 bit on i386, 64 bit on sparc), so that i386 runs faster and sparc doesn't bus error or segfault. --- Diffs of the changes: (+48 -46) Index: llvm-gcc/libstdc++-v3/src/globals.cc diff -u llvm-gcc/libstdc++-v3/src/globals.cc:1.2 llvm-gcc/libstdc++-v3/src/globals.cc:1.2.6.1 --- llvm-gcc/libstdc++-v3/src/globals.cc:1.2 Fri Jan 9 10:54:35 2004 +++ llvm-gcc/libstdc++-v3/src/globals.cc Wed Dec 8 09:30:35 2004 @@ -53,11 +53,13 @@ namespace std { +#define lsizeof(a) (((a)+sizeof(long)-1)/sizeof(long)) + // Standard stream objects. // NB: Iff is included, these definitions become wonky. - typedef char fake_istream[sizeof(istream)] + typedef long fake_istream[lsizeof(sizeof(istream)) ] __attribute__ ((aligned(__alignof__(istream)))); - typedef char fake_ostream[sizeof(ostream)] + typedef long fake_ostream[lsizeof(sizeof(ostream)) ] __attribute__ ((aligned(__alignof__(ostream)))); fake_istream cin; fake_ostream cout; @@ -65,9 +67,9 @@ fake_ostream clog; #ifdef _GLIBCXX_USE_WCHAR_T - typedef char fake_wistream[sizeof(wistream)] + typedef long fake_wistream[lsizeof(sizeof(wistream)) ] __attribute__ ((aligned(__alignof__(wistream)))); - typedef char fake_wostream[sizeof(wostream)] + typedef long fake_wostream[lsizeof(sizeof(wostream)) ] __attribute__ ((aligned(__alignof__(wostream)))); fake_wistream wcin; fake_wostream wcout; @@ -82,189 +84,189 @@ // We use different stream buffer types depending on whether // ios_base::sync_with_stdio(false) has been called. - typedef char fake_stdiobuf[sizeof(stdio_sync_filebuf)] + typedef long fake_stdiobuf[lsizeof(sizeof(stdio_sync_filebuf)) ] __attribute__ ((aligned(__alignof__(stdio_sync_filebuf)))); fake_stdiobuf buf_cout_sync; fake_stdiobuf buf_cin_sync; fake_stdiobuf buf_cerr_sync; - typedef char fake_filebuf[sizeof(stdio_filebuf)] + typedef long fake_filebuf[lsizeof(sizeof(stdio_filebuf)) ] __attribute__ ((aligned(__alignof__(stdio_filebuf)))); fake_filebuf buf_cout; fake_filebuf buf_cin; fake_filebuf buf_cerr; #ifdef _GLIBCXX_USE_WCHAR_T - typedef char fake_wstdiobuf[sizeof(stdio_sync_filebuf)] + typedef long fake_wstdiobuf[lsizeof(sizeof(stdio_sync_filebuf)) ] __attribute__ ((aligned(__alignof__(stdio_sync_filebuf)))); fake_wstdiobuf buf_wcout_sync; fake_wstdiobuf buf_wcin_sync; fake_wstdiobuf buf_wcerr_sync; - typedef char fake_wfilebuf[sizeof(stdio_filebuf)] + typedef long fake_wfilebuf[lsizeof(sizeof(stdio_filebuf)) ] __attribute__ ((aligned(__alignof__(stdio_filebuf)))); fake_wfilebuf buf_wcout; fake_wfilebuf buf_wcin; fake_wfilebuf buf_wcerr; #endif - typedef char fake_locale_Impl[sizeof(locale::_Impl)] + typedef long fake_locale_Impl[lsizeof(sizeof(locale::_Impl)) ] __attribute__ ((aligned(__alignof__(locale::_Impl)))); fake_locale_Impl c_locale_impl; - typedef char fake_locale[sizeof(locale)] + typedef long fake_locale[lsizeof(sizeof(locale)) ] __attribute__ ((aligned(__alignof__(locale)))); fake_locale c_locale; - typedef char fake_name_vec[sizeof(char*)] + typedef long fake_name_vec[lsizeof(sizeof(char*)) ] __attribute__ ((aligned(__alignof__(char*)))); fake_name_vec name_vec[6 + _GLIBCXX_NUM_CATEGORIES]; - typedef char fake_names[sizeof(char[2])] + typedef long fake_names[lsizeof(sizeof(char[2])) ] __attribute__ ((aligned(__alignof__(char[2])))); fake_names name_c[6 + _GLIBCXX_NUM_CATEGORIES]; - typedef char fake_facet_vec[sizeof(locale::facet*)] + typedef long fake_facet_vec[lsizeof(sizeof(locale::facet*)) ] __attribute__ ((aligned(__alignof__(locale::facet*)))); fake_facet_vec facet_vec[_GLIBCXX_NUM_FACETS]; - typedef char fake_cache_vec[sizeof(locale::facet*)] + typedef long fake_cache_vec[lsizeof(sizeof(locale::facet*)) ] __attribute__ ((aligned(__alignof__(locale::facet*)))); fake_cache_vec cache_vec[_GLIBCXX_NUM_FACETS]; - typedef char fake_ctype_c[sizeof(std::ctype)] + typedef long fake_ctype_c[lsizeof(sizeof(std::ctype)) ] __attribute__ ((aligned(__alignof__(std::ctype)))); fake_ctype_c ctype_c; - typedef char fake_collate_c[sizeof(std::collate)] + typedef long fake_collate_c[lsizeof(sizeof(std::collate)) ] __attribute__ ((aligned(__alignof__(std::collate)))); fake_collate_c collate_c; - typedef char fake_numpunct_c[sizeof(numpunct)] + typedef long fake_numpunct_c[lsizeof(sizeof (numpunct)) ] __attribute__ ((aligned(__alignof__(numpunct)))); fake_numpunct_c numpunct_c; - typedef char fake_num_get_c[sizeof(num_get)] + typedef long fake_num_get_c[lsizeof(sizeof (num_get)) ] __attribute__ ((aligned(__alignof__(num_get)))); fake_num_get_c num_get_c; - typedef char fake_num_put_c[sizeof(num_put)] + typedef long fake_num_put_c[lsizeof(sizeof(num_put)) ] __attribute__ ((aligned(__alignof__(num_put)))); fake_num_put_c num_put_c; - typedef char fake_codecvt_c[sizeof(codecvt)] + typedef long fake_codecvt_c[lsizeof(sizeof(codecvt)) ] __attribute__ ((aligned(__alignof__(codecvt)))); fake_codecvt_c codecvt_c; - typedef char fake_moneypunct_c[sizeof(moneypunct)] + typedef long fake_moneypunct_c[lsizeof(sizeof(moneypunct)) ] __attribute__ ((aligned(__alignof__(moneypunct)))); fake_moneypunct_c moneypunct_ct; fake_moneypunct_c moneypunct_cf; - typedef char fake_money_get_c[sizeof(money_get)] + typedef long fake_money_get_c[lsizeof(sizeof(money_get)) ] __attribute__ ((aligned(__alignof__(money_get)))); fake_money_get_c money_get_c; - typedef char fake_money_put_c[sizeof(money_put)] + typedef long fake_money_put_c[lsizeof(sizeof(money_put)) ] __attribute__ ((aligned(__alignof__(money_put)))); fake_money_put_c money_put_c; - typedef char fake_timepunct_c[sizeof(__timepunct)] + typedef long fake_timepunct_c[lsizeof(sizeof(__timepunct)) ] __attribute__ ((aligned(__alignof__(__timepunct)))); fake_timepunct_c timepunct_c; - typedef char fake_time_get_c[sizeof(time_get)] + typedef long fake_time_get_c[lsizeof(sizeof(time_get)) ] __attribute__ ((aligned(__alignof__(time_get)))); fake_time_get_c time_get_c; - typedef char fake_time_put_c[sizeof(time_put)] + typedef long fake_time_put_c[lsizeof(sizeof (time_put)) ] __attribute__ ((aligned(__alignof__(time_put)))); fake_time_put_c time_put_c; - typedef char fake_messages_c[sizeof(messages)] + typedef long fake_messages_c[lsizeof(sizeof (messages)) ] __attribute__ ((aligned(__alignof__(messages)))); fake_messages_c messages_c; #ifdef _GLIBCXX_USE_WCHAR_T - typedef char fake_wtype_w[sizeof(std::ctype)] + typedef long fake_wtype_w[lsizeof(sizeof (std::ctype)) ] __attribute__ ((aligned(__alignof__(std::ctype)))); fake_wtype_w ctype_w; - typedef char fake_wollate_w[sizeof(std::collate)] + typedef long fake_wollate_w[lsizeof(sizeof (std::collate)) ] __attribute__ ((aligned(__alignof__(std::collate)))); fake_wollate_w collate_w; - typedef char fake_numpunct_w[sizeof(numpunct)] + typedef long fake_numpunct_w[lsizeof(sizeof (numpunct)) ] __attribute__ ((aligned(__alignof__(numpunct)))); fake_numpunct_w numpunct_w; - typedef char fake_num_get_w[sizeof(num_get)] + typedef long fake_num_get_w[lsizeof(sizeof (num_get)) ] __attribute__ ((aligned(__alignof__(num_get)))); fake_num_get_w num_get_w; - typedef char fake_num_put_w[sizeof(num_put)] + typedef long fake_num_put_w[lsizeof(sizeof (num_put)) ] __attribute__ ((aligned(__alignof__(num_put)))); fake_num_put_w num_put_w; - typedef char fake_wodecvt_w[sizeof(codecvt)] + typedef long fake_wodecvt_w[lsizeof(sizeof (codecvt)) ] __attribute__ ((aligned(__alignof__(codecvt)))); fake_wodecvt_w codecvt_w; - typedef char fake_moneypunct_w[sizeof(moneypunct)] + typedef long fake_moneypunct_w[lsizeof(sizeof (moneypunct)) ] __attribute__ ((aligned(__alignof__(moneypunct)))); fake_moneypunct_w moneypunct_wt; fake_moneypunct_w moneypunct_wf; - typedef char fake_money_get_w[sizeof(money_get)] + typedef long fake_money_get_w[lsizeof(sizeof (money_get)) ] __attribute__ ((aligned(__alignof__(money_get)))); fake_money_get_w money_get_w; - typedef char fake_money_put_w[sizeof(money_put)] + typedef long fake_money_put_w[lsizeof(sizeof (money_put)) ] __attribute__ ((aligned(__alignof__(money_put)))); fake_money_put_w money_put_w; - typedef char fake_timepunct_w[sizeof(__timepunct)] + typedef long fake_timepunct_w[lsizeof(sizeof (__timepunct)) ] __attribute__ ((aligned(__alignof__(__timepunct)))); fake_timepunct_w timepunct_w; - typedef char fake_time_get_w[sizeof(time_get)] + typedef long fake_time_get_w[lsizeof(sizeof (time_get)) ] __attribute__ ((aligned(__alignof__(time_get)))); fake_time_get_w time_get_w; - typedef char fake_time_put_w[sizeof(time_put)] + typedef long fake_time_put_w[lsizeof(sizeof (time_put)) ] __attribute__ ((aligned(__alignof__(time_put)))); fake_time_put_w time_put_w; - typedef char fake_messages_w[sizeof(messages)] + typedef long fake_messages_w[lsizeof(sizeof (messages)) ] __attribute__ ((aligned(__alignof__(messages)))); fake_messages_w messages_w; #endif // Storage for "C" locale caches. - typedef char fake_num_cache_c[sizeof(std::__numpunct_cache)] + typedef long fake_num_cache_c[lsizeof(sizeof (std::__numpunct_cache)) ] __attribute__ ((aligned(__alignof__(std::__numpunct_cache)))); fake_num_cache_c numpunct_cache_c; - typedef char fake_money_cache_c[sizeof(std::__moneypunct_cache)] + typedef long fake_money_cache_c[lsizeof(sizeof (std::__moneypunct_cache)) ] __attribute__ ((aligned(__alignof__(std::__moneypunct_cache)))); fake_money_cache_c moneypunct_cache_ct; fake_money_cache_c moneypunct_cache_cf; - typedef char fake_time_cache_c[sizeof(std::__timepunct_cache)] + typedef long fake_time_cache_c[lsizeof(sizeof (std::__timepunct_cache)) ] __attribute__ ((aligned(__alignof__(std::__timepunct_cache)))); fake_time_cache_c timepunct_cache_c; #ifdef _GLIBCXX_USE_WCHAR_T - typedef char fake_num_cache_w[sizeof(std::__numpunct_cache)] + typedef long fake_num_cache_w[lsizeof(sizeof (std::__numpunct_cache)) ] __attribute__ ((aligned(__alignof__(std::__numpunct_cache)))); fake_num_cache_w numpunct_cache_w; - typedef char fake_money_cache_w[sizeof(std::__moneypunct_cache)] + typedef long fake_money_cache_w[lsizeof(sizeof (std::__moneypunct_cache)) ] __attribute__ ((aligned(__alignof__(std::__moneypunct_cache)))); fake_money_cache_w moneypunct_cache_wt; fake_money_cache_w moneypunct_cache_wf; - typedef char fake_time_cache_w[sizeof(std::__timepunct_cache)] + typedef long fake_time_cache_w[lsizeof(sizeof (std::__timepunct_cache)) ] __attribute__ ((aligned(__alignof__(std::__timepunct_cache)))); fake_time_cache_w timepunct_cache_w; #endif From criswell at cs.uiuc.edu Wed Dec 8 09:40:43 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed, 8 Dec 2004 09:40:43 -0600 Subject: [llvm-commits] CVS: llvm/test/QMTest/configuration expectations.darwin.qmr expectations.linux.qmr expectations.sunos.qmr expectations.unknown.qmr llvm.py llvmdb.py Message-ID: <200412081540.JAA03483@choi.cs.uiuc.edu> Changes in directory llvm/test/QMTest: configuration (r1.1) removed expectations.darwin.qmr (r1.6) removed expectations.linux.qmr (r1.12) removed expectations.sunos.qmr (r1.13) removed expectations.unknown.qmr (r1.7) removed llvm.py (r1.32) removed llvmdb.py (r1.15) removed --- Log message: Final removal of QMTest. --- Diffs of the changes: (+0 -0) From lattner at cs.uiuc.edu Wed Dec 8 10:05:16 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Wed, 8 Dec 2004 10:05:16 -0600 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Instrumentation/ProfilePaths/ProfilePaths.cpp Message-ID: <200412081605.iB8G5Gdk015693@apoc.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Instrumentation/ProfilePaths: ProfilePaths.cpp updated: 1.40 -> 1.41 --- Log message: Remove unneeded class qualifier, contributed by Bj?rn Wennberg --- Diffs of the changes: (+1 -1) Index: llvm/lib/Transforms/Instrumentation/ProfilePaths/ProfilePaths.cpp diff -u llvm/lib/Transforms/Instrumentation/ProfilePaths/ProfilePaths.cpp:1.40 llvm/lib/Transforms/Instrumentation/ProfilePaths/ProfilePaths.cpp:1.41 --- llvm/lib/Transforms/Instrumentation/ProfilePaths/ProfilePaths.cpp:1.40 Thu Nov 4 22:46:22 2004 +++ llvm/lib/Transforms/Instrumentation/ProfilePaths/ProfilePaths.cpp Wed Dec 8 10:05:02 2004 @@ -49,7 +49,7 @@ // Before this pass, make sure that there is only one // entry and only one exit node for the function in the CFG of the function // - void ProfilePaths::getAnalysisUsage(AnalysisUsage &AU) const { + void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired(); } }; From lattner at cs.uiuc.edu Wed Dec 8 10:11:07 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Wed, 8 Dec 2004 10:11:07 -0600 Subject: [llvm-commits] CVS: llvm/lib/System/Unix/Unix.h Message-ID: <200412081611.iB8GB7VB015713@apoc.cs.uiuc.edu> Changes in directory llvm/lib/System/Unix: Unix.h updated: 1.8 -> 1.9 --- Log message: Make this work with the ICC compiler, contributed by Bj?rn Wennberg --- Diffs of the changes: (+1 -0) Index: llvm/lib/System/Unix/Unix.h diff -u llvm/lib/System/Unix/Unix.h:1.8 llvm/lib/System/Unix/Unix.h:1.9 --- llvm/lib/System/Unix/Unix.h:1.8 Sun Nov 14 16:10:54 2004 +++ llvm/lib/System/Unix/Unix.h Wed Dec 8 10:10:52 2004 @@ -26,6 +26,7 @@ #include #include #include +#include inline void ThrowErrno(const std::string& prefix) { char buffer[MAXPATHLEN]; From lattner at cs.uiuc.edu Wed Dec 8 10:12:33 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Wed, 8 Dec 2004 10:12:33 -0600 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Instrumentation/ProfilePaths/Graph.cpp Message-ID: <200412081612.iB8GCXF4015727@apoc.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Instrumentation/ProfilePaths: Graph.cpp updated: 1.18 -> 1.19 --- Log message: Add support for compilers without argument dependent name lookup, contributed by Bj?rn Wennberg --- Diffs of the changes: (+1 -1) Index: llvm/lib/Transforms/Instrumentation/ProfilePaths/Graph.cpp diff -u llvm/lib/Transforms/Instrumentation/ProfilePaths/Graph.cpp:1.18 llvm/lib/Transforms/Instrumentation/ProfilePaths/Graph.cpp:1.19 --- llvm/lib/Transforms/Instrumentation/ProfilePaths/Graph.cpp:1.18 Wed Sep 1 17:55:36 2004 +++ llvm/lib/Transforms/Instrumentation/ProfilePaths/Graph.cpp Wed Dec 8 10:12:20 2004 @@ -383,7 +383,7 @@ //keep pulling out vertex of min wt from vt while(!vt.empty()){ - Node *u=*(min_element(vt.begin(), vt.end(), compare_nodes())); + Node *u=*(std::min_element(vt.begin(), vt.end(), compare_nodes())); DEBUG(std::cerr<<"popped wt"<<(u)->getWeight()<<"\n"; printNode(u)); From lattner at cs.uiuc.edu Wed Dec 8 10:14:05 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Wed, 8 Dec 2004 10:14:05 -0600 Subject: [llvm-commits] CVS: llvm/lib/AsmParser/llvmAsmParser.y Message-ID: <200412081614.iB8GE5cV015741@apoc.cs.uiuc.edu> Changes in directory llvm/lib/AsmParser: llvmAsmParser.y updated: 1.208 -> 1.209 --- Log message: Add support for compilers with arg dependent name lookup, contributed by Bj?rn Wennberg --- Diffs of the changes: (+2 -1) Index: llvm/lib/AsmParser/llvmAsmParser.y diff -u llvm/lib/AsmParser/llvmAsmParser.y:1.208 llvm/lib/AsmParser/llvmAsmParser.y:1.209 --- llvm/lib/AsmParser/llvmAsmParser.y:1.208 Mon Dec 6 16:18:25 2004 +++ llvm/lib/AsmParser/llvmAsmParser.y Wed Dec 8 10:13:53 2004 @@ -656,7 +656,8 @@ // TypeContains - Returns true if Ty directly contains E in it. // static bool TypeContains(const Type *Ty, const Type *E) { - return find(Ty->subtype_begin(), Ty->subtype_end(), E) != Ty->subtype_end(); + return std::find(Ty->subtype_begin(), Ty->subtype_end(), + E) != Ty->subtype_end(); } namespace { From reid at x10sys.com Wed Dec 8 10:18:40 2004 From: reid at x10sys.com (Reid Spencer) Date: Wed, 8 Dec 2004 10:18:40 -0600 Subject: [llvm-commits] CVS: llvm/docs/GettingStarted.html Message-ID: <200412081618.KAA24677@zion.cs.uiuc.edu> Changes in directory llvm/docs: GettingStarted.html updated: 1.82 -> 1.83 --- Log message: Add descriptions of missing top level directories. --- Diffs of the changes: (+29 -5) Index: llvm/docs/GettingStarted.html diff -u llvm/docs/GettingStarted.html:1.82 llvm/docs/GettingStarted.html:1.83 --- llvm/docs/GettingStarted.html:1.82 Sun Dec 5 11:48:03 2004 +++ llvm/docs/GettingStarted.html Wed Dec 8 10:18:26 2004 @@ -38,13 +38,16 @@
    4. Program layout
      1. CVS directories +
      2. llvm/examples
      3. llvm/include
      4. llvm/lib +
      5. llvm/projects
      6. llvm/runtime
      7. llvm/test
      8. llvm-test
      9. llvm/tools
      10. llvm/utils +
      11. llvm/win32
    5. An Example Using the LLVM Tool Chain @@ -1015,17 +1018,20 @@
      CVS directories
      -
      -

      Every directory checked out of CVS will contain a CVS directory; for the most part these can just be ignored.

      +
      + +
      llvm/examples
      +
      +

      This directory contains some simple examples of how to use the LLVM IR and + JIT.

      llvm/include
      -

      This directory contains public header files exported from the LLVM @@ -1054,7 +1060,6 @@

      llvm/lib
      -

      This directory contains most of the source files of the LLVM system. In LLVM, @@ -1115,6 +1120,16 @@

      +
      llvm/projects
      +
      +

      This directory contains projects that are not strictly part of LLVM but are + shipped with LLVM. This is also the directory where you should create your own + LLVM-based projects. See llvm/projects/sample for an example of how + to set up your own project. See llvm/projects/Stacker for a fully + functional example of a compiler front end.

      +
      + +
      llvm/runtime
      @@ -1331,6 +1346,15 @@
      + +
      llvm/win32
      +
      +

      This directory contains build scripts and project files for use with + Visual C++. This allows developers on Windows to build LLVM without the need + for cygwin. The contents of this directory should be considered experimental + at this time. +

      +
      An Example Using the LLVM Tool Chain @@ -1444,7 +1468,7 @@ Chris Lattner
      Reid Spencer
      The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/12/05 17:48:03 $ + Last modified: $Date: 2004/12/08 16:18:26 $ From lattner at cs.uiuc.edu Wed Dec 8 10:22:41 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Wed, 8 Dec 2004 10:22:41 -0600 Subject: [llvm-commits] CVS: llvm/lib/Analysis/DataStructure/Local.cpp Message-ID: <200412081622.iB8GMfSo015771@apoc.cs.uiuc.edu> Changes in directory llvm/lib/Analysis/DataStructure: Local.cpp updated: 1.118 -> 1.119 --- Log message: Work correctly with ICC, Patch contributed by Bj?rn Wennberg --- Diffs of the changes: (+16 -8) Index: llvm/lib/Analysis/DataStructure/Local.cpp diff -u llvm/lib/Analysis/DataStructure/Local.cpp:1.118 llvm/lib/Analysis/DataStructure/Local.cpp:1.119 --- llvm/lib/Analysis/DataStructure/Local.cpp:1.118 Mon Nov 8 15:08:28 2004 +++ llvm/lib/Analysis/DataStructure/Local.cpp Wed Dec 8 10:22:26 2004 @@ -629,9 +629,12 @@ // If this is freopen, merge the file descriptor passed in with the // result. - if (F->getName() == "freopen") - Result.mergeWith(getValueDest(**--CS.arg_end())); - + if (F->getName() == "freopen") { + // ICC doesn't handle getting the iterator, decrementing and + // dereferencing it in one operation without error. Do it in 2 steps + CallSite::arg_iterator compit = CS.arg_end(); + Result.mergeWith(getValueDest(**--compit)); + } return; } else if (F->getName() == "fclose" && CS.arg_end()-CS.arg_begin() ==1){ // fclose reads and deallocates the memory in an unknown way for the @@ -665,7 +668,8 @@ (F->getName() == "fwrite" || F->getName() == "fread")) { // fread writes the first operand, fwrite reads it. They both // read/write the FILE descriptor, and merges the FILE type. - DSNodeHandle H = getValueDest(**--CS.arg_end()); + CallSite::arg_iterator compit = CS.arg_end(); + DSNodeHandle H = getValueDest(**--compit); if (DSNode *N = H.getNode()) { N->setReadMarker()->setModifiedMarker(); const Type *ArgTy = F->getFunctionType()->getParamType(3); @@ -706,10 +710,12 @@ F->getName() == "_IO_putc") { // These functions read and write the memory for the file descriptor, // which is passes as the last argument. - DSNodeHandle H = getValueDest(**--CS.arg_end()); + CallSite::arg_iterator compit = CS.arg_end(); + DSNodeHandle H = getValueDest(**--compit); if (DSNode *N = H.getNode()) { N->setReadMarker()->setModifiedMarker(); - const Type *ArgTy = *--F->getFunctionType()->param_end(); + FunctionType::param_iterator compit2 = F->getFunctionType()->param_end(); + const Type *ArgTy = *--compit2; if (const PointerType *PTy = dyn_cast(ArgTy)) N->mergeTypeInfo(PTy->getElementType(), H.getOffset()); } @@ -727,7 +733,8 @@ // and read/write all other arguments. DSNodeHandle H = getValueDest(**CS.arg_begin()); if (DSNode *N = H.getNode()) { - const Type *ArgTy = *--F->getFunctionType()->param_end(); + FunctionType::param_iterator compit2 = F->getFunctionType()->param_end(); + const Type *ArgTy = *--compit2; if (const PointerType *PTy = dyn_cast(ArgTy)) N->mergeTypeInfo(PTy->getElementType(), H.getOffset()); } @@ -897,7 +904,8 @@ return; } else if (F->getName() == "modf" && CS.arg_end()-CS.arg_begin() == 2) { // This writes its second argument, and forces it to double. - DSNodeHandle H = getValueDest(**--CS.arg_end()); + CallSite::arg_iterator compit = CS.arg_end(); + DSNodeHandle H = getValueDest(**--compit); if (DSNode *N = H.getNode()) { N->setModifiedMarker(); N->mergeTypeInfo(Type::DoubleTy, H.getOffset()); From lattner at cs.uiuc.edu Wed Dec 8 10:23:00 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Wed, 8 Dec 2004 10:23:00 -0600 Subject: [llvm-commits] CVS: llvm/lib/VMCore/PassManagerT.h Message-ID: <200412081623.iB8GN0SE015781@apoc.cs.uiuc.edu> Changes in directory llvm/lib/VMCore: PassManagerT.h updated: 1.54 -> 1.55 --- Log message: Work correctly with MSVC and ICC, patch contributed by Bj?rn Wennberg --- Diffs of the changes: (+4 -4) Index: llvm/lib/VMCore/PassManagerT.h diff -u llvm/lib/VMCore/PassManagerT.h:1.54 llvm/lib/VMCore/PassManagerT.h:1.55 --- llvm/lib/VMCore/PassManagerT.h:1.54 Wed Oct 27 11:09:56 2004 +++ llvm/lib/VMCore/PassManagerT.h Wed Dec 8 10:22:48 2004 @@ -142,12 +142,12 @@ typedef typename Traits::BatcherClass BatcherClass; typedef typename Traits::ParentClass ParentClass; -#ifndef _MSC_VER - friend class PassManagerTraits::PassClass; - friend class PassManagerTraits::SubPassClass; -#else +#if defined(_MSC_VER) || defined(__INTEL_COMPILER) friend PassClass; friend SubPassClass; +#else + friend class PassManagerTraits::PassClass; + friend class PassManagerTraits::SubPassClass; #endif friend class PassManagerTraits; friend class ImmutablePass; From reid at x10sys.com Wed Dec 8 10:25:36 2004 From: reid at x10sys.com (Reid Spencer) Date: Wed, 8 Dec 2004 10:25:36 -0600 Subject: [llvm-commits] CVS: llvm/docs/GettingStarted.html Message-ID: <200412081625.KAA24764@zion.cs.uiuc.edu> Changes in directory llvm/docs: GettingStarted.html updated: 1.83 -> 1.84 --- Log message: * Change version numbers of tarballs from 1.3 to 1.4 * Add llvm-test-1.4.tar.gz as the tarball for the llvm-test module * Highlight the tarball name a little. --- Diffs of the changes: (+17 -18) Index: llvm/docs/GettingStarted.html diff -u llvm/docs/GettingStarted.html:1.83 llvm/docs/GettingStarted.html:1.84 --- llvm/docs/GettingStarted.html:1.83 Wed Dec 8 10:18:26 2004 +++ llvm/docs/GettingStarted.html Wed Dec 8 10:25:25 2004 @@ -571,28 +571,27 @@

      The files are as follows:

      -
      llvm-1.3.tar.gz -
      This is the source code to the LLVM suite. -

      +

      llvm-1.4.tar.gz
      +
      This is the source code for the LLVM libraries and tools.
      -
      cfrontend-1.3.source.tar.gz -
      This is the source release of the GCC front end. -

      +

      llvm-test-1.4.tar.gz
      +
      This is the source code for the LLVM test suite
      -
      cfrontend-1.3.sparc-sun-solaris2.8.tar.gz -
      This is the binary release of the GCC front end for Solaris/Sparc. -

      +

      cfrontend-1.4.source.tar.gz
      +
      This is the source release of the GCC front end.
      -
      cfrontend-1.3.i686-redhat-linux-gnu.tar.gz -
      This is the binary release of the GCC front end for Linux/x86. -

      +

      cfrontend-1.3.sparc-sun-solaris2.8.tar.gz
      +
      This is the binary release of the GCC front end for Solaris/Sparc. +
      -
      cfrontend-1.3.i386-unknown-freebsd5.1.tar.gz -
      This is the binary release of the GCC front end for FreeBSD/x86. -

      +

      cfrontend-1.3.i686-redhat-linux-gnu.tar.gz
      +
      This is the binary release of the GCC front end for Linux/x86.
      + +
      cfrontend-1.3.i386-unknown-freebsd5.1.tar.gz
      +
      This is the binary release of the GCC front end for FreeBSD/x86.
      -
      cfrontend-1.3.powerpc-apple-darwin7.0.0.tar.gz -
      This is the binary release of the GCC front end for MacOS X/PPC. +
      cfrontend-1.3.powerpc-apple-darwin7.0.0.tar.gz
      +
      This is the binary release of the GCC front end for MacOS X/PPC.
      @@ -1468,7 +1467,7 @@ Chris Lattner
      Reid Spencer
      The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/12/08 16:18:26 $ + Last modified: $Date: 2004/12/08 16:25:25 $ From criswell at cs.uiuc.edu Wed Dec 8 10:31:21 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed, 8 Dec 2004 10:31:21 -0600 Subject: [llvm-commits] CVS: llvm/test/Regression/CFrontend/2004-01-01-UnknownInitSize.c Message-ID: <200412081631.KAA08366@choi.cs.uiuc.edu> Changes in directory llvm/test/Regression/CFrontend: 2004-01-01-UnknownInitSize.c updated: 1.4 -> 1.5 --- Log message: xfail this across all platforms. --- Diffs of the changes: (+1 -1) Index: llvm/test/Regression/CFrontend/2004-01-01-UnknownInitSize.c diff -u llvm/test/Regression/CFrontend/2004-01-01-UnknownInitSize.c:1.4 llvm/test/Regression/CFrontend/2004-01-01-UnknownInitSize.c:1.5 --- llvm/test/Regression/CFrontend/2004-01-01-UnknownInitSize.c:1.4 Mon Nov 22 13:11:40 2004 +++ llvm/test/Regression/CFrontend/2004-01-01-UnknownInitSize.c Wed Dec 8 10:31:06 2004 @@ -3,7 +3,7 @@ /* * This regression test ensures that the C front end can compile initializers * even when it cannot determine the size (as below). - * XFAIL: linux,darwin + * XFAIL: * */ struct one { From criswell at cs.uiuc.edu Wed Dec 8 10:41:46 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed, 8 Dec 2004 10:41:46 -0600 Subject: [llvm-commits] CVS: llvm/test/Regression/CFrontend/2004-06-17-UnorderedCompares.c.tr Message-ID: <200412081641.KAA08392@choi.cs.uiuc.edu> Changes in directory llvm/test/Regression/CFrontend: 2004-06-17-UnorderedCompares.c.tr updated: 1.2 -> 1.3 --- Log message: Fix llvmgcc to use the TestRunner substition mechanism. --- Diffs of the changes: (+1 -1) Index: llvm/test/Regression/CFrontend/2004-06-17-UnorderedCompares.c.tr diff -u llvm/test/Regression/CFrontend/2004-06-17-UnorderedCompares.c.tr:1.2 llvm/test/Regression/CFrontend/2004-06-17-UnorderedCompares.c.tr:1.3 --- llvm/test/Regression/CFrontend/2004-06-17-UnorderedCompares.c.tr:1.2 Sat Dec 4 17:24:30 2004 +++ llvm/test/Regression/CFrontend/2004-06-17-UnorderedCompares.c.tr Wed Dec 8 10:41:34 2004 @@ -1,4 +1,4 @@ -// RUN: llvmgcc -xc -std=c99 %s -c -o - | llvm-dis | grep -v llvm.isunordered | not grep call +// RUN: %llvmgcc -xc -std=c99 %s -c -o - | llvm-dis | grep -v llvm.isunordered | not grep call // XFAIL: sparcv9 #include From criswell at cs.uiuc.edu Wed Dec 8 10:47:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed, 8 Dec 2004 10:47:26 -0600 Subject: [llvm-commits] CVS: llvm/docs/GettingStarted.html Message-ID: <200412081647.KAA08420@choi.cs.uiuc.edu> Changes in directory llvm/docs: GettingStarted.html updated: 1.84 -> 1.85 --- Log message: Update the version numbers of the pre-built LLVM GCC frontends. --- Diffs of the changes: (+5 -5) Index: llvm/docs/GettingStarted.html diff -u llvm/docs/GettingStarted.html:1.84 llvm/docs/GettingStarted.html:1.85 --- llvm/docs/GettingStarted.html:1.84 Wed Dec 8 10:25:25 2004 +++ llvm/docs/GettingStarted.html Wed Dec 8 10:47:14 2004 @@ -580,17 +580,17 @@
      cfrontend-1.4.source.tar.gz
      This is the source release of the GCC front end.
      -
      cfrontend-1.3.sparc-sun-solaris2.8.tar.gz
      +
      cfrontend-1.4.sparc-sun-solaris2.8.tar.gz
      This is the binary release of the GCC front end for Solaris/Sparc.
      -
      cfrontend-1.3.i686-redhat-linux-gnu.tar.gz
      +
      cfrontend-1.4.i686-redhat-linux-gnu.tar.gz
      This is the binary release of the GCC front end for Linux/x86.
      -
      cfrontend-1.3.i386-unknown-freebsd5.1.tar.gz
      +
      cfrontend-1.4.i386-unknown-freebsd5.1.tar.gz
      This is the binary release of the GCC front end for FreeBSD/x86.
      -
      cfrontend-1.3.powerpc-apple-darwin7.0.0.tar.gz
      +
      cfrontend-1.4.powerpc-apple-darwin7.0.0.tar.gz
      This is the binary release of the GCC front end for MacOS X/PPC.
      @@ -1467,7 +1467,7 @@ Chris Lattner
      Reid Spencer
      The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/12/08 16:25:25 $ + Last modified: $Date: 2004/12/08 16:47:14 $ From reid at x10sys.com Wed Dec 8 10:51:42 2004 From: reid at x10sys.com (Reid Spencer) Date: Wed, 8 Dec 2004 10:51:42 -0600 Subject: [llvm-commits] CVS: llvm/docs/GettingStarted.html Message-ID: <200412081651.KAA25062@zion.cs.uiuc.edu> Changes in directory llvm/docs: GettingStarted.html updated: 1.85 -> 1.86 --- Log message: Various 1.4ish corrections and additions. --- Diffs of the changes: (+59 -44) Index: llvm/docs/GettingStarted.html diff -u llvm/docs/GettingStarted.html:1.85 llvm/docs/GettingStarted.html:1.86 --- llvm/docs/GettingStarted.html:1.85 Wed Dec 8 10:47:14 2004 +++ llvm/docs/GettingStarted.html Wed Dec 8 10:51:31 2004 @@ -624,12 +624,23 @@ label:

        +
      • Release 1.4: RELEASE_14
      • Release 1.3: RELEASE_13
      • Release 1.2: RELEASE_12
      • Release 1.1: RELEASE_11
      • Release 1.0: RELEASE_1
      +

      If you would like to get the LLVM test suite (a separate package as of 1.4), +you get it from the CVS repository:

      +
      +  cd llvm/projects
+  cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co llvm-test
+
      +

      By placing it in the llvm/projects, it will be automatically +conifgured by the LLVM configure script as well as automatically updated when +you run cvs update.

      +

      If you would like to get the GCC front end source code, you can also get it from the CVS repository:

      @@ -703,10 +714,10 @@

      Once checked out from the CVS repository, the LLVM suite source code must be -configured via the configure script. This script sets variables in -llvm/Makefile.config and llvm/include/Config/config.h. It -also populates OBJ_ROOT with the Makefiles needed to begin building -LLVM.

      +configured via the configure script. This script sets variables in the +various *.in files, most notably llvm/Makefile.config and +llvm/include/Config/config.h. It also populates OBJ_ROOT with +the Makefiles needed to begin building LLVM.

      The following environment variables are used by the configure script to configure the build system:

      @@ -732,47 +743,40 @@

      The following options can be used to set or enable LLVM specific options:

      -
      --with-llvmgccdir=LLVMGCCDIR +
      --with-llvmgccdir=LLVMGCCDIR
      Path to the location where the LLVM GCC front end binaries and associated libraries were installed. This must be specified as an absolute pathname.

      -

      --enable-optimized + +
      --with-tclinclude
      +
      Path to the tcl include directory under which the tclsh can be + found. Use this if you have multiple tcl installations on your machine and you + want to use a specific one (8.x) for LLVM. LLVM only uses tcl for running the + dejagnu based test suite in llvm/test. If you don't specify this + option, the LLVM configure script will search for tcl 8.4 and 8.3 releases. +
      +
      --enable-optimized
      Enables optimized compilation by default (debugging symbols are removed and GCC optimization flags are enabled). The default is to use an unoptimized build (also known as a debug build).

      -

      --enable-jit + +
      --enable-jit
      Compile the Just In Time (JIT) compiler functionality. This is not available on all platforms. The default is dependent on platform, so it is best to explicitly enable it if you want it.

      -

      --enable-spec2000 -
      --enable-spec2000=<directory> -
      - Enable the use of SPEC2000 when testing LLVM. This is disabled by default - (unless configure finds SPEC2000 installed). By specifying - directory, you can tell configure where to find the SPEC2000 - benchmarks. If directory is left unspecified, configure - uses the default value - /home/vadve/shared/benchmarks/speccpu2000/benchspec. -

      -

      --enable-spec95 -
      --enable-spec95=<directory> -
      - Enable the use of SPEC95 when testing LLVM. It is similar to the - --enable-spec2000 option. -

      -

      --enable-povray -
      --enable-povray=<directory> -
      - Enable the use of Povray as an external test. Versions of Povray written - in C should work. This option is similar to the --enable-spec2000 - option. +
      +
      --enable-doxygen
      +
      Look for the doxygen program and enable construction of doxygen based + documentation from the source code. This is disabled by default because + generating the documentation can take a long time and producess 100s of + megabytes of output.

      To configure LLVM, follow these steps:

      @@ -785,13 +789,13 @@
    6. Run the configure script located in the LLVM source tree:
      - SRC_ROOT/configure + SRC_ROOT/configure --prefix=/install/path [other options]

    In addition to running configure, you must set the -LLVM_LIB_SEARCH_PATH environment variable in your startup scripts. -This environment variable is used to locate "system" libraries like +LLVM_LIB_SEARCH_PATH environment variable in your startup shell +scripts. This environment variable is used to locate "system" libraries like "-lc" and "-lm" when linking. This variable should be set to the absolute path of the bytecode-libs subdirectory of the GCC front end, or LLVMGCCDIR/bytecode-libs. For example, one might set @@ -862,7 +866,7 @@ generated C/C++ files, libraries, and executables.

    -

    gmake distclean +
    gmake dist-clean
    Removes everything that gmake clean does, but also removes files generated by configure. It attempts to return the source tree to the @@ -871,11 +875,12 @@
    gmake install
    - Installs LLVM libraries and tools in a heirarchy under $PREFIX, specified with - ./configure --prefix=[dir], defaults to /usr/local. + Installs LLVM header files, libraries, tools and documentation in a heirarchy + under $PREFIX, specified with ./configure --prefix=[dir], which + defaults to /usr/local.

    -

    gmake -C runtime install +
    gmake -C runtime install-bytecode
    Assuming you built LLVM into $OBJDIR, when this command is run, it will install bytecode libraries into the GCC front end's bytecode library @@ -884,6 +889,10 @@

    +

    Please see the Makefile Guide for further +details on these make targets and descriptions of other targets +available.

    +

    It is also possible to override default values from configure by declaring variables on the command line. The following are some examples:

    @@ -902,6 +911,11 @@
    Print what gmake is doing on standard output.

    + +

    gmake TOOL_VERBOSE=1
    +
    Ask each tool invoked by the makefiles to print out what it is doing on + the standard output. This also implies VERBOSE=1 so the makefile +

    Every directory in the LLVM object tree includes a Makefile to build @@ -943,9 +957,9 @@

    Tools -
    OBJ_ROOT/tools/Debug +
    OBJ_ROOT/Debug/bin
    Libraries -
    OBJ_ROOT/lib/Debug +
    OBJ_ROOT/Debug/lib

    @@ -953,9 +967,9 @@

    Tools -
    OBJ_ROOT/tools/Release +
    OBJ_ROOT/Release/bin
    Libraries -
    OBJ_ROOT/lib/Release +
    OBJ_ROOT/Release/lib

    @@ -963,9 +977,9 @@

    Tools -
    OBJ_ROOT/tools/Profile +
    OBJ_ROOT/Profile/bin
    Libraries -
    OBJ_ROOT/lib/Profile +
    OBJ_ROOT/Profile/lib
    @@ -980,7 +994,8 @@

    If you're running on a linux system that supports the "binfmt_misc" + href="http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html"> + binfmt_misc" module, and you have root access on the system, you can set your system up to execute LLVM bytecode files directly. To do this, use commands like this (the first command may not be required if you are already using the module):

    @@ -1467,7 +1482,7 @@ Chris Lattner
    Reid Spencer
    The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/12/08 16:47:14 $ + Last modified: $Date: 2004/12/08 16:51:31 $ From reid at x10sys.com Wed Dec 8 10:53:02 2004 From: reid at x10sys.com (Reid Spencer) Date: Wed, 8 Dec 2004 10:53:02 -0600 Subject: [llvm-commits] CVS: llvm/docs/TestingGuide.html Message-ID: <200412081653.KAA25122@zion.cs.uiuc.edu> Changes in directory llvm/docs: TestingGuide.html updated: 1.17 -> 1.18 --- Log message: Move documentation for various configuration options applicabe only to the llvm-test directory into this document from GettingStarted.html. --- Diffs of the changes: (+28 -2) Index: llvm/docs/TestingGuide.html diff -u llvm/docs/TestingGuide.html:1.17 llvm/docs/TestingGuide.html:1.18 --- llvm/docs/TestingGuide.html:1.17 Sun Dec 5 20:11:52 2004 +++ llvm/docs/TestingGuide.html Wed Dec 8 10:52:51 2004 @@ -455,7 +455,33 @@ research group. They may still be valuable, however, as a guide to writing your own TEST Makefile for any optimization or analysis passes that you develop with LLVM.

    - + +

    Note, when configuring the llvm-test module, you might want to +specify the following configuration options:

    +
    +
    --enable-spec2000 +
    --enable-spec2000=<directory> +
    + Enable the use of SPEC2000 when testing LLVM. This is disabled by default + (unless configure finds SPEC2000 installed). By specifying + directory, you can tell configure where to find the SPEC2000 + benchmarks. If directory is left unspecified, configure + uses the default value + /home/vadve/shared/benchmarks/speccpu2000/benchspec. +

    +

    --enable-spec95 +
    --enable-spec95=<directory> +
    + Enable the use of SPEC95 when testing LLVM. It is similar to the + --enable-spec2000 option. +

    +

    --enable-povray +
    --enable-povray=<directory> +
    + Enable the use of Povray as an external test. Versions of Povray written + in C should work. This option is similar to the --enable-spec2000 + option. +
    @@ -591,7 +617,7 @@ John T. Criswell
    The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/12/06 02:11:52 $ + Last modified: $Date: 2004/12/08 16:52:51 $ From criswell at cs.uiuc.edu Wed Dec 8 10:55:42 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed, 8 Dec 2004 10:55:42 -0600 Subject: [llvm-commits] CVS: llvm/docs/GettingStarted.html Message-ID: <200412081655.KAA12837@choi.cs.uiuc.edu> Changes in directory llvm/docs: GettingStarted.html updated: 1.86 -> 1.87 --- Log message: Fix spell'os. --- Diffs of the changes: (+4 -4) Index: llvm/docs/GettingStarted.html diff -u llvm/docs/GettingStarted.html:1.86 llvm/docs/GettingStarted.html:1.87 --- llvm/docs/GettingStarted.html:1.86 Wed Dec 8 10:51:31 2004 +++ llvm/docs/GettingStarted.html Wed Dec 8 10:55:27 2004 @@ -416,7 +416,7 @@
  • bzip2* - bzip2 command for distribution generation
  • bunzip2* - bunzip2 command for distribution checking
  • chmod - change permissions on a file
    • -
  • cat - output concatentation utility
    • +
  • cat - output concatenation utility
  • cp - copy files
  • date - print the current date/time
  • echo - print to standard output
    • @@ -638,7 +638,7 @@ cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co llvm-test

    By placing it in the llvm/projects, it will be automatically -conifgured by the LLVM configure script as well as automatically updated when +configured by the LLVM configure script as well as automatically updated when you run cvs update.

    If you would like to get the GCC front end source code, you can also get it @@ -875,7 +875,7 @@

    gmake install
    - Installs LLVM header files, libraries, tools and documentation in a heirarchy + Installs LLVM header files, libraries, tools and documentation in a hierarchy under $PREFIX, specified with ./configure --prefix=[dir], which defaults to /usr/local.

    @@ -1482,7 +1482,7 @@ Chris Lattner
    Reid Spencer
    The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/12/08 16:51:31 $ + Last modified: $Date: 2004/12/08 16:55:27 $ From tbrethou at cs.uiuc.edu Wed Dec 8 11:13:09 2004 From: tbrethou at cs.uiuc.edu (Tanya Brethour) Date: Wed, 8 Dec 2004 11:13:09 -0600 (CST) Subject: [llvm-commits] CVS: llvm/docs/GettingStarted.html Message-ID: <200412081713.LAA13050@kain.cs.uiuc.edu> Changes in directory llvm/docs: GettingStarted.html updated: 1.87 -> 1.88 --- Log message: Removed QMTest referrences. Updated ordering of notes. --- Diffs of the changes: (+5 -28) Index: llvm/docs/GettingStarted.html diff -u llvm/docs/GettingStarted.html:1.87 llvm/docs/GettingStarted.html:1.88 --- llvm/docs/GettingStarted.html:1.87 Wed Dec 8 10:55:27 2004 +++ llvm/docs/GettingStarted.html Wed Dec 8 11:12:52 2004 @@ -298,7 +298,7 @@ GCC 3.4.2 - C/C++ compiler (Note 4) + C/C++ compiler (Note 3) @@ -362,23 +362,9 @@ - QMTest - 2.0.3 - Automated test suite (Note 2, - Note 3) - - - - Python - 2.3 - Automated test suite (Note 2, - Note 3) - - - CVS >1.11 - CVS access to LLVM (Note 5) + CVS access to LLVM (Note 4) @@ -391,21 +377,12 @@ package.

  • Only needed if you want to run the automated test suite in the test directory.
    • -
  • These are needed to use the LLVM test suite. - Please note that newer versions of QMTest may not work with the LLVM - test suite. QMTest 2.0.3 can be retrieved from the QMTest CVS - repository using the following commands: -
      -
    • cvs -d :pserver:anoncvs at cvs.codesourcery.com:/home/qm/Repository login
      • -
    • When prompted, use anoncvs as the password.
      • -
    • cvs -d :pserver:anoncvs at cvs.codesourcery.com:/home/qm/Repository co -r release-2-0-3 qm
      • -
    • -
  • Only the C and C++ languages are needed so there's no +
  • Only the C and C++ languages are needed so there's no need to build the other languages for LLVM's purposes. See below for specific version info.
    • -
  • You only need CVS if you intend to build from the +
  • You only need CVS if you intend to build from the latest LLVM sources. If you're working from a release distribution, you don't need CVS.
    • @@ -1482,7 +1459,7 @@ Chris Lattner
    Reid Spencer
    The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/12/08 16:55:27 $ + Last modified: $Date: 2004/12/08 17:12:52 $ From tbrethou at cs.uiuc.edu Wed Dec 8 11:25:58 2004 From: tbrethou at cs.uiuc.edu (Tanya Brethour) Date: Wed, 8 Dec 2004 11:25:58 -0600 (CST) Subject: [llvm-commits] CVS: llvm/docs/Projects.html Message-ID: <200412081725.LAA13672@kain.cs.uiuc.edu> Changes in directory llvm/docs: Projects.html updated: 1.11 -> 1.12 --- Log message: Removed QMTest reference. --- Diffs of the changes: (+11 -12) Index: llvm/docs/Projects.html diff -u llvm/docs/Projects.html:1.11 llvm/docs/Projects.html:1.12 --- llvm/docs/Projects.html:1.11 Sun May 23 16:07:26 2004 +++ llvm/docs/Projects.html Wed Dec 8 11:25:46 2004 @@ -186,19 +186,18 @@ This subdirectory should contain tests that verify that your code works correctly. Automated tests are especially useful.

    - Currently, the LLVM build system provides little support for tests, - although some exists. Expanded support for tests will hopefully - occur in the future. In the meantime, the LLVM system does provide the - following: + Currently, the LLVM build system provides basic support for tests. + The LLVM system provides the following:

    • - LLVM provides several QMTest test classes that can be used to - create tests. They can be found in - llvm/test/QMTest/llvm.py. These test classes perform a - variety of functions, including code optimization tests, assembly - tests, and code analysis tests. The Makefile in - llvm/test provides the QMTest context needed by LLVM test - classes. + LLVM provides a tcl procedure that is used by Dejagnu to run + tests. It can be found in llvm/lib/llvm-dg.exp. This + test procedure uses RUN lines in the actual test case to determine + how to run the test. See the TestingGuide for more details. You + can easily write Makefile support similar to the Makefiles in llvm/test + to use Dejagnu to run your project's tests.
      • +

    • @@ -444,7 +443,7 @@ John Criswell
      The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/05/23 21:07:26 $ + Last modified: $Date: 2004/12/08 17:25:46 $ From tbrethou at cs.uiuc.edu Wed Dec 8 11:35:47 2004 From: tbrethou at cs.uiuc.edu (Tanya Brethour) Date: Wed, 8 Dec 2004 11:35:47 -0600 (CST) Subject: [llvm-commits] CVS: llvm/docs/TestingGuide.html Message-ID: <200412081735.LAA14993@kain.cs.uiuc.edu> Changes in directory llvm/docs: TestingGuide.html updated: 1.18 -> 1.19 --- Log message: Removed QMTest reference. --- Diffs of the changes: (+12 -118) Index: llvm/docs/TestingGuide.html diff -u llvm/docs/TestingGuide.html:1.18 llvm/docs/TestingGuide.html:1.19 --- llvm/docs/TestingGuide.html:1.18 Wed Dec 8 10:52:51 2004 +++ llvm/docs/TestingGuide.html Wed Dec 8 11:35:31 2004 @@ -23,7 +23,6 @@
    • LLVM Test Suite Tree
    • DejaGNU Structure
      • -
    • QMTest Structure
    • llvm-test Structure
    • Running the LLVM Tests
    • Running the nightly tester
      • @@ -60,18 +59,8 @@
      The Feature and Regressions tests are organized and run by DejaGNU.
      Expect
      Expect is required by DejaGNU.
      -
      tclsh
      -
      Tclsh is required by DejaGNU.
      - -
      QMTest
      -
      The LLVM test suite uses QMTest to organize and run tests. Note: -you will need QMTest -2.0.3 (source tar.gz file) to be successful. The tests do not run with -any other version. (optional, required only for QMTest)
      - -
      Python
      -
      You will need a Python interpreter that works with QMTest. Python will -need zlib and SAX support enabled. (optional, required only for QMTest)
      +
      tcl
      +
      Tcl is required by DejaGNU.
      F2C
      For now, LLVM does not have a Fortran front-end, but using F2C, we can run @@ -129,24 +118,6 @@
      Note: If you are running the tests with objdir != subdir you must have run the complete testsuite before you can specify a subdirectory.
      -

      To run the simple tests (i.e. those that do basic testing of -LLVM), using QMTest:

      -
      -% gmake -C llvm/test qmtest
-
      - -

      To run only the basic feature tests, QMTest supports the following -target:

      -
      -% gmake -C llvm/test Feature.t
-
      - -

      To run only the regression tests, QMTest supports the following -target:

      -
      -% gmake -C llvm/test Regression.t
-
      -

      To run the comprehensive test suite (tests that compile and execute whole programs), run the llvm-test tests:

      @@ -270,11 +241,6 @@ location of these external programs is configured by the llvm-test configure script.

      -
    • llvm/test/QMTest -

      This directory contains the QMTest information files. Inside this directory -are QMTest administration files and the Python code that implements the LLVM -test and database classes.

      • -
    @@ -285,7 +251,7 @@

    The LLVM test suite is partially driven by DejaGNU and partially driven by GNU Make. Specifically, the Features and Regression tests -are all driven by DejaGNU (and optionally QMTest). The llvm-test +are all driven by DejaGNU. The llvm-test module is currently driven by a set of Makefiles.

    The DejaGNU structure is very simple, but does require some @@ -356,78 +322,6 @@

    -
    QMTest Structure
    - - -
    - -

    The Feature and Regression tests can also be run using QMTest.

    - -

    The QMTest system needs to have several pieces of information available; -these pieces of configuration information are known collectively as the -"context" in QMTest parlance. Since the context for LLVM is relatively large, -the master Makefile in llvm/test sets it for you.

    - -

    The LLVM database class makes the subdirectories of llvm/test a QMTest test -database. For each directory that contains tests driven by QMTest, it knows -what type of test the source file is and how to run it.

    - -

    Hence, the QMTest namespace is essentially what you see in the Feature and -Regression directories, but there is some magic that the database class performs -(as described below).

    - -

    The QMTest namespace is currently composed of the following tests and test -suites:

    - -
      -
    • Feature - -

      These are the feature tests found in the Feature directory. -They are broken up into the following categories:

      - -
        -
      • ad -

        Assembler/Disassembler tests. These tests verify that a piece of LLVM - assembly language can be assembled into bytecode and then disassembled - into the original assembly language code. It does this several times to - ensure that assembled output can be disassembled and disassembler output - can be assembled. It also verifies that the give assembly language file - can be assembled correctly.

        • - -
      • opt -

        Optimizer tests. These tests verify that two of the optimizer passes - completely optimize a program (i.e. after a single pass, they cannot - optimize a program any further).

        • - -
      • mc -

        Machine code tests. These tests verify that the LLVM assembly - language file can be translated into native assembly code.

        • - -
      • cc -

        C code tests. These tests verify that the specified LLVM assembly - code can be converted into C source code using the C backend.

        • -
      - -

      The LLVM database class looks at every file in the Feature directory and -creates a fake test hierarchy containing -Feature.<testtype>.<testname>. So, if you add an LLVM -assembly language file to the Feature directory, it actually creates 5 new -tests: assembler/disassembler, assembler, optimizer, machine code, and C code. -

      • - -
    • Regression -

      These are the regression tests. There is one suite for each - subdirectory of the Regression directory. If you add a new subdirectory - there, you will need to modify, at least, the RegressionMap - variable in QMTest/llvmdb.py so that QMTest knows how to run the - tests in the new subdirectory.

      -
      • - -
    - -
    - -
    llvm-test Structure
    @@ -494,18 +388,18 @@ are not executed inside of the LLVM source tree. This is because the test suite creates temporary files during execution.

    -

    The master Makefile in llvm/test is capable of running only the QMTest driven +

    The master Makefile in llvm/test is capable of running only the DejaGNU driven tests. By default, it will run all of these tests.

    -

    To run only the QMTest driven tests, run gmake qmtest at the -command line in llvm/tests. To run a specific qmtest, suffix the test name with -".t" when running gmake.

    +

    To run only the DejaGNU driven tests, run gmake at the +command line in llvm/tests. To run a specific directory of tests, specify the TESTSUITE. +

    -

    For example, to run the Regression.LLC tests, type -gmake Regression.LLC.t in llvm/tests.

    +

    For example, to run the Regression tests, type +gmake TESTSUITE=Regression in llvm/tests.

    Note that there are no Makefiles in llvm/test/Features and -llvm/test/Regression. You must use QMTest from the llvm/test +llvm/test/Regression. You must use DejaGNU from the llvm/test directory to run them.

    To run the llvm-test suite, you need to use the following steps: @@ -547,7 +441,7 @@ choose.

    Some tests are known to fail. Some are bugs that we have not fixed yet; -others are features that we haven't added yet (or may never add). In QMTest, +others are features that we haven't added yet (or may never add). In DejaGNU, the result for such tests will be XFAIL (eXpected FAILure). In this way, you can tell the difference between an expected and unexpected failure.

    @@ -617,7 +511,7 @@ John T. Criswell
    The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/12/08 16:52:51 $ + Last modified: $Date: 2004/12/08 17:35:31 $ From tbrethou at cs.uiuc.edu Wed Dec 8 11:37:33 2004 From: tbrethou at cs.uiuc.edu (Tanya Brethour) Date: Wed, 8 Dec 2004 11:37:33 -0600 (CST) Subject: [llvm-commits] CVS: llvm/docs/TestingGuide.html Message-ID: <200412081737.LAA15023@kain.cs.uiuc.edu> Changes in directory llvm/docs: TestingGuide.html updated: 1.19 -> 1.20 --- Log message: Fixed typo in Dejagnu section. --- Diffs of the changes: (+2 -2) Index: llvm/docs/TestingGuide.html diff -u llvm/docs/TestingGuide.html:1.19 llvm/docs/TestingGuide.html:1.20 --- llvm/docs/TestingGuide.html:1.19 Wed Dec 8 11:35:31 2004 +++ llvm/docs/TestingGuide.html Wed Dec 8 11:37:21 2004 @@ -291,7 +291,7 @@
    %s
    The test file.
    -
    $t
    +
    %t
    Temporary filename: testscript.test_filename.tmp, where test_filename is the name of the test file. All temporary files are placed in the Output directory within the directory the test is @@ -511,7 +511,7 @@ John T. Criswell
    The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/12/08 17:35:31 $ + Last modified: $Date: 2004/12/08 17:37:21 $ From criswell at cs.uiuc.edu Wed Dec 8 11:54:09 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed, 8 Dec 2004 11:54:09 -0600 Subject: [llvm-commits] CVS: llvm/docs/GettingStarted.html Message-ID: <200412081754.LAA13026@choi.cs.uiuc.edu> Changes in directory llvm/docs: GettingStarted.html updated: 1.88 -> 1.89 --- Log message: Minor fixups. --- Diffs of the changes: (+22 -13) Index: llvm/docs/GettingStarted.html diff -u llvm/docs/GettingStarted.html:1.88 llvm/docs/GettingStarted.html:1.89 --- llvm/docs/GettingStarted.html:1.88 Wed Dec 8 11:12:52 2004 +++ llvm/docs/GettingStarted.html Wed Dec 8 11:53:54 2004 @@ -89,6 +89,12 @@ compiled into LLVM bytecode, a program can be manipulated with the LLVM tools from the LLVM suite.

    +

    +There is a third, optional piece called llvm-test. It is a suite of programs +with a testing harness that can be used to further test LLVM's functionality +and performance. +

    + @@ -526,7 +532,7 @@
    alias llvmgcc LLVMGCCDIR/bin/gcc
    alias llvmg++ LLVMGCCDIR/bin/g++
    - This alias allows you to use the LLVM C and C++ front ends without putting + These aliases allow you to use the LLVM C and C++ front ends without putting them in your PATH or typing in their complete pathnames. @@ -552,7 +558,7 @@
    This is the source code for the LLVM libraries and tools.
    llvm-test-1.4.tar.gz
    -
    This is the source code for the LLVM test suite
    +
    This is the source code for the LLVM test suite.
    cfrontend-1.4.source.tar.gz
    This is the source release of the GCC front end.
    @@ -626,7 +632,7 @@

    Please note that you must follow these -instructions to successfully build the LLVM C front-end.

    +instructions to successfully build the LLVM GCC front-end.

    @@ -725,7 +731,7 @@ Path to the location where the LLVM GCC front end binaries and associated libraries were installed. This must be specified as an absolute pathname. -

    +

    --with-tclinclude
    Path to the tcl include directory under which the tclsh can be @@ -733,13 +739,14 @@ want to use a specific one (8.x) for LLVM. LLVM only uses tcl for running the dejagnu based test suite in llvm/test. If you don't specify this option, the LLVM configure script will search for tcl 8.4 and 8.3 releases. +

    --enable-optimized
    Enables optimized compilation by default (debugging symbols are removed and GCC optimization flags are enabled). The default is to use an unoptimized build (also known as a debug build). -

    +

    --enable-jit
    @@ -747,7 +754,7 @@ available on all platforms. The default is dependent on platform, so it is best to explicitly enable it if you want it. -

    +

    --enable-doxygen
    Look for the doxygen program and enable construction of doxygen based @@ -824,7 +831,7 @@

    gmake

    If the build fails, please check here to see if you -are using a known broken version of GCC to compile LLVM with.

    +are using a version of GCC that is known not to compile LLVM.

    If you have multiple processors in your machine, you may wish to use some of @@ -852,7 +859,8 @@

    gmake install
    - Installs LLVM header files, libraries, tools and documentation in a hierarchy + Installs LLVM header files, libraries, tools, and documentation in a + hierarchy under $PREFIX, specified with ./configure --prefix=[dir], which defaults to /usr/local.

    @@ -891,7 +899,7 @@

    gmake TOOL_VERBOSE=1
    Ask each tool invoked by the makefiles to print out what it is doing on - the standard output. This also implies VERBOSE=1 so the makefile + the standard output. This also implies VERBOSE=1.

    @@ -1145,9 +1153,10 @@
    llvm-test
    -

    This is not a directory in the normal llvm module, it is a separate CVS +

    This is not a directory in the normal llvm module; it is a separate CVS module that must be checked out (usually to projects/llvm-test). This - module contains a comprehensive correctness, performance and benchmarking test + module contains a comprehensive correctness, performance, and benchmarking + test suite for LLVM. It is a separate CVS module because not every LLVM user is interested in downloading or building such a comprehensive test. For further details on this test suite, please see the @@ -1342,7 +1351,7 @@

    This directory contains build scripts and project files for use with Visual C++. This allows developers on Windows to build LLVM without the need - for cygwin. The contents of this directory should be considered experimental + for Cygwin. The contents of this directory should be considered experimental at this time.

    @@ -1459,7 +1468,7 @@ Chris Lattner
    Reid Spencer
    The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/12/08 17:12:52 $ + Last modified: $Date: 2004/12/08 17:53:54 $ From reid at x10sys.com Wed Dec 8 12:00:41 2004 From: reid at x10sys.com (Reid Spencer) Date: Wed, 8 Dec 2004 12:00:41 -0600 Subject: [llvm-commits] CVS: llvm/docs/GettingStarted.html Message-ID: <200412081800.MAA26248@zion.cs.uiuc.edu> Changes in directory llvm/docs: GettingStarted.html updated: 1.89 -> 1.90 --- Log message: Add llvm-ld tool Note that both llvmc and llvm-ld are experimental in 1.4 --- Diffs of the changes: (+12 -2) Index: llvm/docs/GettingStarted.html diff -u llvm/docs/GettingStarted.html:1.89 llvm/docs/GettingStarted.html:1.90 --- llvm/docs/GettingStarted.html:1.89 Wed Dec 8 11:53:54 2004 +++ llvm/docs/GettingStarted.html Wed Dec 8 12:00:30 2004 @@ -1194,7 +1194,9 @@ pre-processing, translation, optimization, assembly, and linking of programs all from one command line. llvmc also takes care of processing the dependent libraries found in bytecode. This reduces the need to get the - traditional -l<name> options right on the command line. + traditional -l<name> options right on the command line. Please + note that this tool is new in 1.4 and considered experimental. It will be + fully supported in 1.5.
    llvm-ar
    The archiver produces an archive containing @@ -1209,6 +1211,14 @@
    The disassembler transforms the LLVM bytecode to human readable LLVM assembly.
    +
    llvm-ld
    +
    llvm-ld is very similar to gccld and provides a general purpose + and extensible linker for LLVM. This is the linker invoked by llvmc. + It allows optimization modules to be loaded so that language specific + optimizations can be applied at link time. Please note that this tool is new + in LLVM 1.4 and still considered experimental. It will be fully supported in + LLVM 1.5.
    +
    llvm-link
    llvm-link, not surprisingly, links multiple LLVM modules into a single program.
    @@ -1468,7 +1478,7 @@ Chris Lattner
    Reid Spencer
    The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/12/08 17:53:54 $ + Last modified: $Date: 2004/12/08 18:00:30 $ From criswell at cs.uiuc.edu Wed Dec 8 12:01:41 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed, 8 Dec 2004 12:01:41 -0600 Subject: [llvm-commits] CVS: llvm/docs/FAQ.html Message-ID: <200412081801.MAA13098@choi.cs.uiuc.edu> Changes in directory llvm/docs: FAQ.html updated: 1.25 -> 1.26 --- Log message: We don't have python test classes anymore. --- Diffs of the changes: (+1 -5) Index: llvm/docs/FAQ.html diff -u llvm/docs/FAQ.html:1.25 llvm/docs/FAQ.html:1.26 --- llvm/docs/FAQ.html:1.25 Fri Dec 3 17:58:18 2004 +++ llvm/docs/FAQ.html Wed Dec 8 12:01:27 2004 @@ -168,10 +168,6 @@
  • The GCC front end code is not as portable as the LLVM suite, so it may not compile as well on unsupported platforms.
    • -
  • The Python test classes are more UNIX-centric than they should be, so - porting to non-UNIX like platforms (i.e. Windows, MacOS 9) will require some - effort.
    • -
  • The LLVM build system relies heavily on UNIX shell tools, like the Bourne Shell and sed. Porting to systems without these tools (MacOS 9, Plan 9) will require more effort.
    • @@ -558,7 +554,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"> LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/12/03 23:58:18 $ + Last modified: $Date: 2004/12/08 18:01:27 $ From criswell at cs.uiuc.edu Wed Dec 8 12:04:26 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed, 8 Dec 2004 12:04:26 -0600 Subject: [llvm-commits] CVS: llvm/docs/GettingStarted.html Message-ID: <200412081804.MAA13130@choi.cs.uiuc.edu> Changes in directory llvm/docs: GettingStarted.html updated: 1.90 -> 1.91 --- Log message: Mention in the exposition that lli can JIT on PowerPC now. --- Diffs of the changes: (+2 -2) Index: llvm/docs/GettingStarted.html diff -u llvm/docs/GettingStarted.html:1.90 llvm/docs/GettingStarted.html:1.91 --- llvm/docs/GettingStarted.html:1.90 Wed Dec 8 12:00:30 2004 +++ llvm/docs/GettingStarted.html Wed Dec 8 12:04:14 2004 @@ -1228,7 +1228,7 @@ can directly execute LLVM bytecode (although very slowly...). In addition to a simple interpreter, lli also has a tracing mode (entered by specifying -trace on the command line). Finally, for - architectures that support it (currently only x86 and Sparc), by default, + architectures that support it (currently x86, Sparc, and PowerPC), by default, lli will function as a Just-In-Time compiler (if the functionality was compiled in), and will execute the code much faster than the interpreter. @@ -1478,7 +1478,7 @@ Chris Lattner
    Reid Spencer
    The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/12/08 18:00:30 $ + Last modified: $Date: 2004/12/08 18:04:14 $ From tbrethou at cs.uiuc.edu Wed Dec 8 12:14:07 2004 From: tbrethou at cs.uiuc.edu (Tanya Brethour) Date: Wed, 8 Dec 2004 12:14:07 -0600 (CST) Subject: [llvm-commits] CVS: llvm/docs/MakefileGuide.html WritingAnLLVMPass.html Message-ID: <200412081814.MAA15947@kain.cs.uiuc.edu> Changes in directory llvm/docs: MakefileGuide.html updated: 1.20 -> 1.21 WritingAnLLVMPass.html updated: 1.35 -> 1.36 --- Log message: Fixed broken links. --- Diffs of the changes: (+9 -7) Index: llvm/docs/MakefileGuide.html diff -u llvm/docs/MakefileGuide.html:1.20 llvm/docs/MakefileGuide.html:1.21 --- llvm/docs/MakefileGuide.html:1.20 Tue Dec 7 22:26:23 2004 +++ llvm/docs/MakefileGuide.html Wed Dec 8 12:13:51 2004 @@ -246,7 +246,7 @@

    In some situations, it is desireable to build a single bytecode module from a variety of sources, instead of an archive, shared library, or bytecode library. Bytecode modules can be specified in addition to any of the other - types of libraries by defining the MODULE_NAME + types of libraries by defining the MODULE_NAME variable. For example:

    
       LIBRARYNAME = mylib
@@ -414,10 +414,10 @@
 
    check
    
 
    
   
    This target can be invoked from anywhere within a project's directories
-  but always invokes the check-local target 
+  but always invokes the check-local target 
   in the project's test directory, if it exists and has a 
   Makefile. A warning is produced otherwise.  If 
-  TESTSUITE is defined on the make
+  TESTSUITE is defined on the make
   command line, it will be passed down to the invocation of 
   make check-local in the test directory. The intended usage 
   for this is to assist in running specific suites of tests. If
@@ -608,7 +608,7 @@
     files that are not automatically distributed.
     
    FAKE_SOURCES(optional)
     
    
-    
    This variable is like SOURCES except that
+    
    This variable is like SOURCES except that
     the source files don't need to exist. The makefiles only use
     FAKE_SOURCES to create the names of derived objects that should be
     included in the directory's result. It is assumed that the project's
@@ -658,6 +658,8 @@
     
    Specifies the name of the LLVM code generation target that the
     current directory builds. Setting this variable enables additional rules to
     build .inc files from .td files. 
    
+    
    TESTSUITE
    
+    
    Specifies the directory of tests to run in llvm/test.
    
     
    TOOLNAME
    
     
    Specifies the name of the tool that the current directory should
     build.
    
@@ -951,7 +953,7 @@
 
   Reid Spencer
    
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/12/08 04:26:23 $
+  Last modified: $Date: 2004/12/08 18:13:51 $
 
 
 


Index: llvm/docs/WritingAnLLVMPass.html
diff -u llvm/docs/WritingAnLLVMPass.html:1.35 llvm/docs/WritingAnLLVMPass.html:1.36
--- llvm/docs/WritingAnLLVMPass.html:1.35	Thu Nov 18 19:26:37 2004
+++ llvm/docs/WritingAnLLVMPass.html	Wed Dec  8 12:13:51 2004
@@ -1212,7 +1212,7 @@
 
 
    
 
    The Statistic
+href="http://llvm.cs.uiuc.edu/doxygen/Statistic_8h-source.html">Statistic
 class, is designed to be an easy way to expose various success
 metrics from passes.  These statistics are printed at the end of a
 run, when the -stats command line option is enabled on the command
@@ -1589,7 +1589,7 @@
 
   Chris Lattner
    
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/11/19 01:26:37 $
+  Last modified: $Date: 2004/12/08 18:13:51 $
 
 
 





From lattner at cs.uiuc.edu  Wed Dec  8 12:22:30 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed, 8 Dec 2004 12:22:30 -0600
Subject: [llvm-commits] CVS: llvm-www/www-index.html 
Message-ID: <200412081822.iB8IMU9V016086@apoc.cs.uiuc.edu>



Changes in directory llvm-www:

www-index.html updated: 1.116 -> 1.117
---
Log message:

PPC Jits too


---
Diffs of the changes:  (+1 -1)

Index: llvm-www/www-index.html
diff -u llvm-www/www-index.html:1.116 llvm-www/www-index.html:1.117
--- llvm-www/www-index.html:1.116	Wed Sep 22 22:57:58 2004
+++ llvm-www/www-index.html	Wed Dec  8 12:22:18 2004
@@ -36,7 +36,7 @@
 front-end, a link-time optimization framework with a growing set of global
 and interprocedural analyses and transformations, static back-ends for the X86,
 PowerPC, and SPARC V9 architectures, a back-end which emits portable C code, and
-a Just-In-Time compiler for X86 and SPARC V9 processors. See "Current Projects" for information about other
 components under development.
    
 





From tbrethou at cs.uiuc.edu  Wed Dec  8 12:24:22 2004
From: tbrethou at cs.uiuc.edu (Tanya Brethour)
Date: Wed, 8 Dec 2004 12:24:22 -0600 (CST)
Subject: [llvm-commits] CVS: llvm-www/Developers.html 
Message-ID: <200412081824.MAA15995@kain.cs.uiuc.edu>



Changes in directory llvm-www:

Developers.html updated: 1.17 -> 1.18
---
Log message:

Updating new location of Vikram's picture.


---
Diffs of the changes:  (+1 -1)

Index: llvm-www/Developers.html
diff -u llvm-www/Developers.html:1.17 llvm-www/Developers.html:1.18
--- llvm-www/Developers.html:1.17	Wed Oct 20 22:55:37 2004
+++ llvm-www/Developers.html	Wed Dec  8 12:24:12 2004
@@ -18,7 +18,7 @@
   
     Vikram Adve
     
-        vadve
     
    Brian Gaeke





From tbrethou at cs.uiuc.edu  Wed Dec  8 12:25:50 2004
From: tbrethou at cs.uiuc.edu (Tanya Brethour)
Date: Wed, 8 Dec 2004 12:25:50 -0600 (CST)
Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html 
Message-ID: <200412081825.MAA16025@kain.cs.uiuc.edu>



Changes in directory llvm/docs:

ReleaseNotes.html updated: 1.277 -> 1.278
---
Log message:

Fixed broken link.


---
Diffs of the changes:  (+2 -2)

Index: llvm/docs/ReleaseNotes.html
diff -u llvm/docs/ReleaseNotes.html:1.277 llvm/docs/ReleaseNotes.html:1.278
--- llvm/docs/ReleaseNotes.html:1.277	Tue Dec  7 02:39:08 2004
+++ llvm/docs/ReleaseNotes.html	Wed Dec  8 12:25:34 2004
@@ -451,7 +451,7 @@
   
  • Explicit Reg Vars: Defining variables residing in specified registers.
    • 
   
  • Vector Extensions: Using vector instructions through built-in functions.
    • 
   
  • Target Builtins:   Built-in functions specific to particular targets.
    • 
-  
  • Thread-Local: Per-thread variables.
    • 
+  
  • Thread-Local: Per-thread variables.
    • 
   
  • Pragmas: Pragmas accepted by GCC.
    • 
   
 
@@ -716,7 +716,7 @@
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" />
 
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/12/07 08:39:08 $
+  Last modified: $Date: 2004/12/08 18:25:34 $
 
 
 





From tbrethou at cs.uiuc.edu  Wed Dec  8 12:29:51 2004
From: tbrethou at cs.uiuc.edu (Tanya Brethour)
Date: Wed, 8 Dec 2004 12:29:51 -0600 (CST)
Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html 
Message-ID: <200412081829.MAA16055@kain.cs.uiuc.edu>



Changes in directory llvm/docs:

ReleaseNotes.html updated: 1.278 -> 1.279
---
Log message:

Fixed a broken link to gcc manual.


---
Diffs of the changes:  (+2 -2)

Index: llvm/docs/ReleaseNotes.html
diff -u llvm/docs/ReleaseNotes.html:1.278 llvm/docs/ReleaseNotes.html:1.279
--- llvm/docs/ReleaseNotes.html:1.278	Wed Dec  8 12:25:34 2004
+++ llvm/docs/ReleaseNotes.html	Wed Dec  8 12:29:38 2004
@@ -536,7 +536,7 @@
   
  • Case Ranges: `case 1 ... 9' and such.
    • 
   
  • Mixed Declarations: Mixing declarations and code.
    • 
   
  • Function Prototypes: Prototype declarations and old-style definitions.
    • 
-  
  • C++ Comments: C++ comments are recognized.
    • 
+  
  • C++ Comments: C++ comments are recognized.
    • 
   
  • Dollar Signs: Dollar sign is allowed in identifiers.
    • 
   
  • Character Escapes: \e stands for the character <ESC>.
    • 
   
  • Alignment: Inquiring about the alignment of a type or variable.
    • 
@@ -716,7 +716,7 @@
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" />
 
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/12/08 18:25:34 $
+  Last modified: $Date: 2004/12/08 18:29:38 $
 
 
 





From alkis at cs.uiuc.edu  Wed Dec  8 12:30:22 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Wed, 8 Dec 2004 12:30:22 -0600
Subject: [llvm-commits] CVS: llvm/tools/llvmc/class.in 
Message-ID: <200412081830.MAA26720@zion.cs.uiuc.edu>



Changes in directory llvm/tools/llvmc:

class.in added (r1.1)
---
Log message:

Add first try on a class -> llvm configuration file for llvmc.


---
Diffs of the changes:  (+67 -0)

Index: llvm/tools/llvmc/class.in
diff -c /dev/null llvm/tools/llvmc/class.in:1.1
*** /dev/null	Wed Dec  8 12:30:21 2004
--- llvm/tools/llvmc/class.in	Wed Dec  8 12:30:11 2004
***************
*** 0 ****
--- 1,67 ----
+ # Java Configuration File For llvmc
+ 
+ ##########################################################
+ # Language definitions
+ ##########################################################
+   lang.name=Java
+   lang.opt1=-simplifycfg -mem2reg -instcombine
+   lang.opt2=
+   lang.opt3=
+   lang.opt4=
+   lang.opt5=
+   lang.libs=@LLVM_OBJ_ROOT@/projects/Java/Debug/lib
+ 
+ ##########################################################
+ # Pre-processor definitions
+ ##########################################################
+ 
+   # Java doesn't have a preprocessor but the following
+   # allows the -E option to be supported
+   preprocessor.command=cp %in% %out%
+   preprocessor.required=false
+ 
+ ##########################################################
+ # Translator definitions
+ ##########################################################
+ 
+   # To compile java class files, we just run the
+   # class2llvm compiler with the correct classpath.
+   translator.command=\
+     @LLVM_OBJ_ROOT@/projects/Java/Debug/binclass2llvm \
+       %in% %force% -o %out% %time% %stats% %args%
+ 
+   # class2llvm doesn't preprocess but we set this to true
+   # so that we don't run the cp command by default.
+   translator.preprocesses=true
+ 
+   # The translator is required to run.
+   translator.required=true
+ 
+   # class2llvm outputs llvm bytecode
+   translator.output=bytecode
+ 
+ ##########################################################
+ # Optimizer definitions
+ ##########################################################
+   
+   # For optimization, we use the LLVM "opt" program
+   optimizer.command=@LLVM_BINDIR@/opt \
+     %in% %force% -o %out% %opt% %time% %stats% %args%
+ 
+   optimizer.required = true
+ 
+   # opt doesn't translate
+   optimizer.translates=false
+ 
+   # opt doesn't preprocess
+   optimizer.preprocesses=false
+ 
+   # opt produces bytecode
+   optimizer.output=bytecode
+ 
+ ##########################################################
+ # Assembler definitions
+ ##########################################################
+   assembler.command=\
+     @LLVM_BINDIR@/llc \
+       %in% %force% -o %out% %target% %time% %stats% %args%





From tbrethou at cs.uiuc.edu  Wed Dec  8 12:35:13 2004
From: tbrethou at cs.uiuc.edu (Tanya Brethour)
Date: Wed, 8 Dec 2004 12:35:13 -0600 (CST)
Subject: [llvm-commits] CVS: llvm/docs/ProgrammersManual.html 
Message-ID: <200412081835.MAA16082@kain.cs.uiuc.edu>



Changes in directory llvm/docs:

ProgrammersManual.html updated: 1.72 -> 1.73
---
Log message:

Fixed broken link to Bruce Eckle's book.


---
Diffs of the changes:  (+2 -2)

Index: llvm/docs/ProgrammersManual.html
diff -u llvm/docs/ProgrammersManual.html:1.72 llvm/docs/ProgrammersManual.html:1.73
--- llvm/docs/ProgrammersManual.html:1.72	Mon Nov  1 03:11:57 2004
+++ llvm/docs/ProgrammersManual.html	Wed Dec  8 12:34:56 2004
@@ -212,7 +212,7 @@
 
  • Bjarne Stroustrup's C++
 Page
    • 
 
-
  • 
+
  • 
 Bruce Eckel's Thinking in C++, 2nd ed. Volume 2 Revision 4.0 (even better, get
 the book).
    • 
 
@@ -2059,7 +2059,7 @@
   Dinakar Dhurjati and
   Chris Lattner
    
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/11/01 09:11:57 $
+  Last modified: $Date: 2004/12/08 18:34:56 $
 
 
 





From alkis at cs.uiuc.edu  Wed Dec  8 12:43:50 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Wed, 8 Dec 2004 12:43:50 -0600
Subject: [llvm-commits] 
	CVS: llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll
Message-ID: <200412081843.MAA27175@zion.cs.uiuc.edu>



Changes in directory llvm/test/Regression/Transforms/InstCombine:

2004-12-08-InstCombineCrash.ll updated: 1.1 -> 1.2
---
Log message:

Mark this as an XFAIL until a fix is worked out.


---
Diffs of the changes:  (+1 -0)

Index: llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll
diff -u llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll:1.1 llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll:1.2
--- llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll:1.1	Wed Dec  8 01:25:10 2004
+++ llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll	Wed Dec  8 12:43:39 2004
@@ -1,4 +1,5 @@
 ; RUN: llvm-as %s -o - | opt -instcombine
+; XFAIL: *
 
 	%struct.llvm_java_object_base = type opaque
 	"java/lang/Object" = type { %struct.llvm_java_object_base }





From reid at x10sys.com  Wed Dec  8 12:56:12 2004
From: reid at x10sys.com (Reid Spencer)
Date: Wed, 08 Dec 2004 10:56:12 -0800
Subject: [llvm-commits] CVS: llvm-www/Developers.html
In-Reply-To: <200412081824.MAA15995@kain.cs.uiuc.edu>
References: <200412081824.MAA15995@kain.cs.uiuc.edu>
Message-ID: <1102532171.24317.133.camel@bashful.x10sys.com>

While we're at it, Bill Wendling's picture is currently being hosted on
my x10sys server. That doesn't really make sense. Could you move this to
a UIUC server and update the link? The picture is at:

http://llvm.x10sys.com/rspencer/Bill.jpeg

Reid.

On Wed, 2004-12-08 at 10:24, Tanya Brethour wrote:
> Changes in directory llvm-www:
> 
> Developers.html updated: 1.17 -> 1.18
> ---
> Log message:
> 
> Updating new location of Vikram's picture.
> 
> 
> ---
> Diffs of the changes:  (+1 -1)
> 
> Index: llvm-www/Developers.html
> diff -u llvm-www/Developers.html:1.17 llvm-www/Developers.html:1.18
> --- llvm-www/Developers.html:1.17	Wed Oct 20 22:55:37 2004
> +++ llvm-www/Developers.html	Wed Dec  8 12:24:12 2004
> @@ -18,7 +18,7 @@
>    
>      Vikram Adve
>      
> -         +                  alt="vadve"/>
>      
>     Brian Gaeke
> 
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20041208/4c7eee3c/attachment.bin 

From tbrethou at cs.uiuc.edu  Wed Dec  8 12:56:35 2004
From: tbrethou at cs.uiuc.edu (Tanya Brethour)
Date: Wed, 8 Dec 2004 12:56:35 -0600 (CST)
Subject: [llvm-commits] CVS: llvm-www/img/BillWendlingPhoto.jpeg 
Message-ID: <200412081856.MAA16175@kain.cs.uiuc.edu>



Changes in directory llvm-www/img:

BillWendlingPhoto.jpeg added (r1.1)
---
Log message:

Adding Bills picture to cvs.


---
Diffs of the changes:  (+0 -0)

Index: llvm-www/img/BillWendlingPhoto.jpeg





From tbrethou at cs.uiuc.edu  Wed Dec  8 12:57:25 2004
From: tbrethou at cs.uiuc.edu (Tanya Brethour)
Date: Wed, 8 Dec 2004 12:57:25 -0600 (CST)
Subject: [llvm-commits] CVS: llvm-www/Developers.html 
Message-ID: <200412081857.MAA16200@kain.cs.uiuc.edu>



Changes in directory llvm-www:

Developers.html updated: 1.18 -> 1.19
---
Log message:

Moved Bills picture to llvm server.


---
Diffs of the changes:  (+1 -1)

Index: llvm-www/Developers.html
diff -u llvm-www/Developers.html:1.18 llvm-www/Developers.html:1.19
--- llvm-www/Developers.html:1.18	Wed Dec  8 12:24:12 2004
+++ llvm-www/Developers.html	Wed Dec  8 12:57:15 2004
@@ -70,7 +70,7 @@
      
  
     Bill Wendling
-    Bill
+    Bill
   
 
 





From lattner at cs.uiuc.edu  Wed Dec  8 13:00:59 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed, 8 Dec 2004 13:00:59 -0600
Subject: [llvm-commits] CVS: llvm/docs/.cvsignore 
Message-ID: <200412081900.iB8J0xk7016185@apoc.cs.uiuc.edu>



Changes in directory llvm/docs:

.cvsignore added (r1.1)
---
Log message:

ignore generated file


---
Diffs of the changes:  (+2 -0)

Index: llvm/docs/.cvsignore
diff -c /dev/null llvm/docs/.cvsignore:1.1
*** /dev/null	Wed Dec  8 13:00:55 2004
--- llvm/docs/.cvsignore	Wed Dec  8 13:00:45 2004
***************
*** 0 ****
--- 1,2 ----
+ doxygen.cfg
+ 





From reid at x10sys.com  Wed Dec  8 13:01:11 2004
From: reid at x10sys.com (Reid Spencer)
Date: Wed, 8 Dec 2004 13:01:11 -0600
Subject: [llvm-commits] CVS: llvm/docs/CommandGuide/Makefile 
Message-ID: <200412081901.NAA27503@zion.cs.uiuc.edu>



Changes in directory llvm/docs/CommandGuide:

Makefile updated: 1.8 -> 1.9
---
Log message:

Build the man and ps versions of the command guide as well when 
BUILD_FOR_WEBSITE is set.


---
Diffs of the changes:  (+20 -5)

Index: llvm/docs/CommandGuide/Makefile
diff -u llvm/docs/CommandGuide/Makefile:1.8 llvm/docs/CommandGuide/Makefile:1.9
--- llvm/docs/CommandGuide/Makefile:1.8	Tue Dec  7 22:43:40 2004
+++ llvm/docs/CommandGuide/Makefile	Wed Dec  8 13:01:01 2004
@@ -8,6 +8,7 @@
 ##===----------------------------------------------------------------------===##
 
 ifdef BUILD_FOR_WEBSITE
+
 # This special case is for keeping the CommandGuide on the LLVM web site
 # up to date automatically as the documents are checked in. It must build
 # the POD files to HTML only and keep them in the src directories. It must also
@@ -15,13 +16,27 @@
 # make -s BUILD_FOR_WEBSITE=1 inside the cvs commit script.
 
 POD  := $(wildcard *.pod)
-HTML := $(patsubst %.pod,html/%.html, $(POD))
+HTML := $(patsubst %.pod, html/%.html, $(POD))
+MAN  := $(patsubst %.pod, man/man1/%.1, $(POD))
+PS   := $(patsubst %.pod, ps/%.ps, $(POD))
 
-all: $(HTML)
+all: $(HTML) $(MAN) $(PS)
 
-html/%.html : %.pod
-	pod2html --css=manpage.css --htmlroot=. --podpath=. \
-	  --noindex --infile=$< --outfile=$@ --title=$*
+.SUFFIXES:
+.SUFFIXES: .html .pod .1 .ps
+
+html/%.html: %.pod
+	pod2html --css=manpage.css --htmlroot=. \
+	  --podpath=. --noindex --infile=$< --outfile=$@ --title=$*
+
+man/man1/%.1: %.pod
+	pod2man --release=1.4 --center="LLVM Command Guide" $< $@
+
+ps/%.ps: man/man1/%.1
+	groff -Tps -man $< > $@
+
+clean:
+	rm -f pod2htm*.*~~ $(HTML) $(MAN) $(PS)
 
 else 
 





From lattner at cs.uiuc.edu  Wed Dec  8 13:05:58 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed, 8 Dec 2004 13:05:58 -0600
Subject: [llvm-commits] CVS: llvm/docs/ProgrammersManual.html 
Message-ID: <200412081905.iB8J5wHe016266@apoc.cs.uiuc.edu>



Changes in directory llvm/docs:

ProgrammersManual.html updated: 1.73 -> 1.74
---
Log message:

Test commit


---
Diffs of the changes:  (+2 -1)

Index: llvm/docs/ProgrammersManual.html
diff -u llvm/docs/ProgrammersManual.html:1.73 llvm/docs/ProgrammersManual.html:1.74
--- llvm/docs/ProgrammersManual.html:1.73	Wed Dec  8 12:34:56 2004
+++ llvm/docs/ProgrammersManual.html	Wed Dec  8 13:05:44 2004
@@ -20,6 +20,7 @@
       
  • The -time-passes option
    • 
       
  • How to use the LLVM Makefile system
    • 
       
  • How to write a regression test
    • 
+
 --> 
     
   
@@ -2059,7 +2060,7 @@
   Dinakar Dhurjati and
   Chris Lattner
    
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/12/08 18:34:56 $
+  Last modified: $Date: 2004/12/08 19:05:44 $
 
 
 





From lattner at cs.uiuc.edu  Wed Dec  8 13:07:18 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed, 8 Dec 2004 13:07:18 -0600
Subject: [llvm-commits] CVS: CVSROOT/update-www.sh 
Message-ID: <200412081907.iB8J7IPX016311@apoc.cs.uiuc.edu>



Changes in directory CVSROOT:

update-www.sh updated: 1.6 -> 1.7
---
Log message:

Use gmake to run stuff


---
Diffs of the changes:  (+1 -1)

Index: CVSROOT/update-www.sh
diff -u CVSROOT/update-www.sh:1.6 CVSROOT/update-www.sh:1.7
--- CVSROOT/update-www.sh:1.6	Tue Dec  7 23:44:01 2004
+++ CVSROOT/update-www.sh	Wed Dec  8 13:07:08 2004
@@ -11,7 +11,7 @@
 
 # Make the HTML docs from POD source
 cd /home/vadve/shared/llvm-wwwroot/docs/CommandGuide
-make -s BUILD_FOR_WEBSITE=1
+gmake -s BUILD_FOR_WEBSITE=1
 
 # Give access to any of the files we just checked in to the group
 find . -user $USER -exec chmod g+w {} \;





From tbrethou at cs.uiuc.edu  Wed Dec  8 13:08:53 2004
From: tbrethou at cs.uiuc.edu (Tanya Brethour)
Date: Wed, 8 Dec 2004 13:08:53 -0600 (CST)
Subject: [llvm-commits] CVS: llvm-www/releases/1.0/docs/ReleaseNotes.html 
Message-ID: <200412081908.NAA16233@kain.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.0/docs:

ReleaseNotes.html updated: 1.50 -> 1.51
---
Log message:

Fixed some broken links.


---
Diffs of the changes:  (+2 -2)

Index: llvm-www/releases/1.0/docs/ReleaseNotes.html
diff -u llvm-www/releases/1.0/docs/ReleaseNotes.html:1.50 llvm-www/releases/1.0/docs/ReleaseNotes.html:1.51
--- llvm-www/releases/1.0/docs/ReleaseNotes.html:1.50	Mon Jun 21 22:44:38 2004
+++ llvm-www/releases/1.0/docs/ReleaseNotes.html	Wed Dec  8 13:08:42 2004
@@ -310,7 +310,7 @@
   
  • Return Address: Getting the return or frame address of a function. 
   
  • Vector Extensions: Using vector instructions through built-in functions. 
   
  • Target Builtins:   Built-in functions specific to particular targets. 
-  
  • Thread-Local: Per-thread variables. 
+  
  • Thread-Local: Per-thread variables. 
   
  • Pragmas: Pragmas accepted by GCC. 
   
    
 
@@ -382,7 +382,7 @@
   
  • Mixed Declarations: 	Mixing declarations and code. 
 
   
  • Function Prototypes:  Prototype declarations and old-style definitions. 
-  
  • C++ Comments: C++ comments are recognized. 
+  
  • C++ Comments: C++ comments are recognized. 
   
  • Dollar Signs: Dollar sign is allowed in identifiers. 
   
  • Character Escapes: \e stands for the character <ESC>. 
   
  • Alignment: Inquiring about the alignment of a type or variable. 





From tbrethou at cs.uiuc.edu  Wed Dec  8 13:10:24 2004
From: tbrethou at cs.uiuc.edu (Tanya Brethour)
Date: Wed, 8 Dec 2004 13:10:24 -0600 (CST)
Subject: [llvm-commits] CVS: llvm-www/releases/1.1/docs/ReleaseNotes.html 
Message-ID: <200412081910.NAA16255@kain.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.1/docs:

ReleaseNotes.html updated: 1.40 -> 1.41
---
Log message:

Fixed some broken links.


---
Diffs of the changes:  (+3 -3)

Index: llvm-www/releases/1.1/docs/ReleaseNotes.html
diff -u llvm-www/releases/1.1/docs/ReleaseNotes.html:1.40 llvm-www/releases/1.1/docs/ReleaseNotes.html:1.41
--- llvm-www/releases/1.1/docs/ReleaseNotes.html:1.40	Mon Jun 21 22:45:20 2004
+++ llvm-www/releases/1.1/docs/ReleaseNotes.html	Wed Dec  8 13:10:14 2004
@@ -498,7 +498,7 @@
   
  • Return Address: Getting the return or frame address of a function.
    • 
   
  • Vector Extensions: Using vector instructions through built-in functions.
    • 
   
  • Target Builtins:   Built-in functions specific to particular targets.
    • 
-  
  • Thread-Local: Per-thread variables.
    • 
+  
  • Thread-Local: Per-thread variables.
    • 
   
  • Pragmas: Pragmas accepted by GCC.
    • 
   
 
@@ -581,7 +581,7 @@
   
  • Case Ranges: `case 1 ... 9' and such.
    • 
   
  • Mixed Declarations: Mixing declarations and code.
    • 
   
  • Function Prototypes: Prototype declarations and old-style definitions.
    • 
-  
  • C++ Comments: C++ comments are recognized.
    • 
+  
  • C++ Comments: C++ comments are recognized.
    • 
   
  • Dollar Signs: Dollar sign is allowed in identifiers.
    • 
   
  • Character Escapes: \e stands for the character <ESC>.
    • 
   
  • Alignment: Inquiring about the alignment of a type or variable.
    • 
@@ -767,7 +767,7 @@
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" />
 
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/06/22 03:45:20 $
+  Last modified: $Date: 2004/12/08 19:10:14 $
 
 
 





From tbrethou at cs.uiuc.edu  Wed Dec  8 13:12:47 2004
From: tbrethou at cs.uiuc.edu (Tanya Brethour)
Date: Wed, 8 Dec 2004 13:12:47 -0600 (CST)
Subject: [llvm-commits] CVS: llvm-www/releases/1.2/docs/ReleaseNotes.html 
Message-ID: <200412081912.NAA16276@kain.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.2/docs:

ReleaseNotes.html updated: 1.25 -> 1.26
---
Log message:

Fixed a few broken links.


---
Diffs of the changes:  (+3 -3)

Index: llvm-www/releases/1.2/docs/ReleaseNotes.html
diff -u llvm-www/releases/1.2/docs/ReleaseNotes.html:1.25 llvm-www/releases/1.2/docs/ReleaseNotes.html:1.26
--- llvm-www/releases/1.2/docs/ReleaseNotes.html:1.25	Fri Jul 23 14:39:39 2004
+++ llvm-www/releases/1.2/docs/ReleaseNotes.html	Wed Dec  8 13:12:37 2004
@@ -439,7 +439,7 @@
   
  • Explicit Reg Vars: Defining variables residing in specified registers.
    • 
   
  • Vector Extensions: Using vector instructions through built-in functions.
    • 
   
  • Target Builtins:   Built-in functions specific to particular targets.
    • 
-  
  • Thread-Local: Per-thread variables.
    • 
+  
  • Thread-Local: Per-thread variables.
    • 
   
  • Pragmas: Pragmas accepted by GCC.
    • 
   
 
@@ -523,7 +523,7 @@
   
  • Case Ranges: `case 1 ... 9' and such.
    • 
   
  • Mixed Declarations: Mixing declarations and code.
    • 
   
  • Function Prototypes: Prototype declarations and old-style definitions.
    • 
-  
  • C++ Comments: C++ comments are recognized.
    • 
+  
  • C++ Comments: C++ comments are recognized.
    • 
   
  • Dollar Signs: Dollar sign is allowed in identifiers.
    • 
   
  • Character Escapes: \e stands for the character <ESC>.
    • 
   
  • Alignment: Inquiring about the alignment of a type or variable.
    • 
@@ -692,7 +692,7 @@
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" />
 
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/07/23 19:39:39 $
+  Last modified: $Date: 2004/12/08 19:12:37 $
 
 
 





From tbrethou at cs.uiuc.edu  Wed Dec  8 13:14:43 2004
From: tbrethou at cs.uiuc.edu (Tanya Brethour)
Date: Wed, 8 Dec 2004 13:14:43 -0600 (CST)
Subject: [llvm-commits] CVS: llvm-www/releases/1.3/docs/ReleaseNotes.html 
Message-ID: <200412081914.NAA16295@kain.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.3/docs:

ReleaseNotes.html updated: 1.10 -> 1.11
---
Log message:

Fixed broken links.


---
Diffs of the changes:  (+3 -3)

Index: llvm-www/releases/1.3/docs/ReleaseNotes.html
diff -u llvm-www/releases/1.3/docs/ReleaseNotes.html:1.10 llvm-www/releases/1.3/docs/ReleaseNotes.html:1.11
--- llvm-www/releases/1.3/docs/ReleaseNotes.html:1.10	Thu Nov 25 00:32:22 2004
+++ llvm-www/releases/1.3/docs/ReleaseNotes.html	Wed Dec  8 13:14:32 2004
@@ -527,7 +527,7 @@
   
  • Explicit Reg Vars: Defining variables residing in specified registers.
    • 
   
  • Vector Extensions: Using vector instructions through built-in functions.
    • 
   
  • Target Builtins:   Built-in functions specific to particular targets.
    • 
-  
  • Thread-Local: Per-thread variables.
    • 
+  
  • Thread-Local: Per-thread variables.
    • 
   
  • Pragmas: Pragmas accepted by GCC.
    • 
   
 
@@ -612,7 +612,7 @@
   
  • Case Ranges: `case 1 ... 9' and such.
    • 
   
  • Mixed Declarations: Mixing declarations and code.
    • 
   
  • Function Prototypes: Prototype declarations and old-style definitions.
    • 
-  
  • C++ Comments: C++ comments are recognized.
    • 
+  
  • C++ Comments: C++ comments are recognized.
    • 
   
  • Dollar Signs: Dollar sign is allowed in identifiers.
    • 
   
  • Character Escapes: \e stands for the character <ESC>.
    • 
   
  • Alignment: Inquiring about the alignment of a type or variable.
    • 
@@ -792,7 +792,7 @@
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" />
 
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/11/25 06:32:22 $
+  Last modified: $Date: 2004/12/08 19:14:32 $
 
 
 





From tbrethou at cs.uiuc.edu  Wed Dec  8 13:16:46 2004
From: tbrethou at cs.uiuc.edu (Tanya Brethour)
Date: Wed, 8 Dec 2004 13:16:46 -0600 (CST)
Subject: [llvm-commits] 
	CVS: llvm-www/releases/1.3/docs/ProgrammersManual.html
Message-ID: <200412081916.NAA16316@kain.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.3/docs:

ProgrammersManual.html updated: 1.1 -> 1.2
---
Log message:

Fixed broken link.


---
Diffs of the changes:  (+2 -2)

Index: llvm-www/releases/1.3/docs/ProgrammersManual.html
diff -u llvm-www/releases/1.3/docs/ProgrammersManual.html:1.1 llvm-www/releases/1.3/docs/ProgrammersManual.html:1.2
--- llvm-www/releases/1.3/docs/ProgrammersManual.html:1.1	Fri Aug 13 17:03:04 2004
+++ llvm-www/releases/1.3/docs/ProgrammersManual.html	Wed Dec  8 13:16:35 2004
@@ -206,7 +206,7 @@
 
  • Bjarne Stroustrup's C++
 Page
    • 
 
-
  • 
+
  • 
 Bruce Eckel's Thinking in C++, 2nd ed. Volume 2 Revision 4.0 (even better, get
 the book).
    • 
 
@@ -2044,7 +2044,7 @@
   Dinakar Dhurjati and
   Chris Lattner
    
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/08/13 22:03:04 $
+  Last modified: $Date: 2004/12/08 19:16:35 $
 
 
 





From lattner at cs.uiuc.edu  Wed Dec  8 14:01:24 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed, 8 Dec 2004 14:01:24 -0600
Subject: [llvm-commits] CVS: llvm/lib/Linker/LinkItems.cpp 
Message-ID: <200412082001.iB8K1OwH016997@apoc.cs.uiuc.edu>



Changes in directory llvm/lib/Linker:

LinkItems.cpp updated: 1.1 -> 1.2
---
Log message:

Turn this error back into a warning, fixing the povray regression


---
Diffs of the changes:  (+2 -2)

Index: llvm/lib/Linker/LinkItems.cpp
diff -u llvm/lib/Linker/LinkItems.cpp:1.1 llvm/lib/Linker/LinkItems.cpp:1.2
--- llvm/lib/Linker/LinkItems.cpp:1.1	Sun Dec  5 13:14:55 2004
+++ llvm/lib/Linker/LinkItems.cpp	Wed Dec  8 14:01:10 2004
@@ -50,9 +50,9 @@
     // If the pathname does not exist, then simply return if we're doing a 
     // native link and give a warning if we're doing a bytecode link.
     if (!Native) {
-      std::cerr << progname << ": error: Cannot find library '"
+      std::cerr << progname << ": warning: Cannot find library '"
                 << Lib << "'\n";
-      return true;
+      return false;
     }
   }
 





From criswell at cs.uiuc.edu  Wed Dec  8 14:30:23 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 8 Dec 2004 14:30:23 -0600
Subject: [llvm-commits] CVS: llvm-test/Runtime/Makefile 
Message-ID: <200412082030.OAA23917@choi.cs.uiuc.edu>



Changes in directory llvm-test/Runtime:

Makefile (r1.1) removed
---
Log message:

Remove these as they are no longer needed.


---
Diffs of the changes:  (+0 -0)




From criswell at cs.uiuc.edu  Wed Dec  8 14:30:33 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 8 Dec 2004 14:30:33 -0600
Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/amiga/Makefile.pup
	Makefile.sas 
Message-ID: <200412082030.OAA23931@choi.cs.uiuc.edu>



Changes in directory llvm-test/Runtime/zlib/amiga:

Makefile.pup (r1.1) removed
Makefile.sas (r1.1) removed
---
Log message:

Remove these as they are no longer needed.



---
Diffs of the changes:  (+0 -0)




From criswell at cs.uiuc.edu  Wed Dec  8 14:30:33 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 8 Dec 2004 14:30:33 -0600
Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/contrib/README.contrib
	visual-basic.txt 
Message-ID: <200412082030.OAA23932@choi.cs.uiuc.edu>



Changes in directory llvm-test/Runtime/zlib/contrib:

README.contrib (r1.1) removed
visual-basic.txt (r1.1) removed
---
Log message:

Remove these as they are no longer needed.



---
Diffs of the changes:  (+0 -0)




From criswell at cs.uiuc.edu  Wed Dec  8 14:30:33 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 8 Dec 2004 14:30:33 -0600
Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/as400/bndsrc compile.clp
	readme.txt zlib.inc 
Message-ID: <200412082030.OAA23939@choi.cs.uiuc.edu>



Changes in directory llvm-test/Runtime/zlib/as400:

bndsrc (r1.1) removed
compile.clp (r1.1) removed
readme.txt (r1.1) removed
zlib.inc (r1.1) removed
---
Log message:

Remove these as they are no longer needed.



---
Diffs of the changes:  (+0 -0)




From criswell at cs.uiuc.edu  Wed Dec  8 14:30:52 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 8 Dec 2004 14:30:52 -0600
Subject: [llvm-commits] CVS: llvm-test/Runtime/zlib/ChangeLog FAQ INDEX
	LICENSE.TXT Makefile Makefile.in Makefile.orig README
	adler32.c algorithm.txt compress.c configure crc32.c crc32.h
	deflate.c deflate.h example.c gzio.c infback.c inffast.c
	inffast.h inffixed.h inflate.c inflate.h inftrees.c
	inftrees.h minigzip.c trees.c trees.h uncompr.c zconf.h
	zconf.in.h zlib.3 zlib.h zutil.c zutil.h 
Message-ID: <200412082030.OAA23986@choi.cs.uiuc.edu>



Changes in directory llvm-test/Runtime/zlib:

ChangeLog (r1.1) removed
FAQ (r1.1) removed
INDEX (r1.1) removed
LICENSE.TXT (r1.1) removed
Makefile (r1.1) removed
Makefile.in (r1.1) removed
Makefile.orig (r1.1) removed
README (r1.1) removed
adler32.c (r1.1) removed
algorithm.txt (r1.1) removed
compress.c (r1.1) removed
configure (r1.1) removed
crc32.c (r1.1) removed
crc32.h (r1.1) removed
deflate.c (r1.1) removed
deflate.h (r1.1) removed
example.c (r1.1) removed
gzio.c (r1.1) removed
infback.c (r1.1) removed
inffast.c (r1.1) removed
inffast.h (r1.1) removed
inffixed.h (r1.1) removed
inflate.c (r1.1) removed
inflate.h (r1.1) removed
inftrees.c (r1.1) removed
inftrees.h (r1.1) removed
minigzip.c (r1.1) removed
trees.c (r1.1) removed
trees.h (r1.1) removed
uncompr.c (r1.1) removed
zconf.h (r1.1) removed
zconf.in.h (r1.1) removed
zlib.3 (r1.1) removed
zlib.h (r1.1) removed
zutil.c (r1.1) removed
zutil.h (r1.1) removed
---
Log message:

Remove these as they are no longer needed.



---
Diffs of the changes:  (+0 -0)




From criswell at cs.uiuc.edu  Wed Dec  8 14:32:05 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 8 Dec 2004 14:32:05 -0600
Subject: [llvm-commits] CVS: llvm-test/Makefile 
Message-ID: <200412082032.OAA24021@choi.cs.uiuc.edu>



Changes in directory llvm-test:

Makefile updated: 1.26 -> 1.27
---
Log message:

Removed llvm-test/Runtime as it is not needed.


---
Diffs of the changes:  (+0 -1)

Index: llvm-test/Makefile
diff -u llvm-test/Makefile:1.26 llvm-test/Makefile:1.27
--- llvm-test/Makefile:1.26	Mon Dec  6 15:21:30 2004
+++ llvm-test/Makefile	Wed Dec  8 14:31:53 2004
@@ -13,7 +13,6 @@
 ##===----------------------------------------------------------------------===##
 
 LEVEL = .
-DIRS = Runtime
 PARALLEL_DIRS = SingleSource MultiSource External
 
 include $(LEVEL)/Makefile.programs





From criswell at cs.uiuc.edu  Wed Dec  8 14:32:08 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 8 Dec 2004 14:32:08 -0600
Subject: [llvm-commits] CVS: llvm-test/External/Povray/Makefile 
Message-ID: <200412082032.OAA24027@choi.cs.uiuc.edu>



Changes in directory llvm-test/External/Povray:

Makefile updated: 1.12 -> 1.13
---
Log message:

Removed llvm-test/Runtime as it is not needed.



---
Diffs of the changes:  (+2 -2)

Index: llvm-test/External/Povray/Makefile
diff -u llvm-test/External/Povray/Makefile:1.12 llvm-test/External/Povray/Makefile:1.13
--- llvm-test/External/Povray/Makefile:1.12	Mon Dec  6 15:20:54 2004
+++ llvm-test/External/Povray/Makefile	Wed Dec  8 14:31:56 2004
@@ -7,8 +7,8 @@
 SourceDir = $(POVRAY_ROOT)/source
 
 CPPFLAGS += -I$(POVRAY_ROOT)/source/unix -I$(BUILD_SRC_ROOT)/runtime/libpng -DPREFIX=\"$(BUILD_OBJ_DIR)\" -DSYSCONFDIR=\"$(POVRAY_ROOT)\" -DPOV_LIB_DIR=\"$(BUILD_OBJ_DIR)/lib\" -IOutput/src -UHAVE_LIBVGA
-LIBS +=    -L$(BUILD_OBJ_ROOT)/$(CONFIGURATION)/lib -lpng -lz -lm
-LDFLAGS += -L$(BUILD_OBJ_ROOT)/$(CONFIGURATION)/lib -lpng -lz -lm
+LIBS +=    -lpng -lz -lm
+LDFLAGS += -lpng -lz -lm
 
 RUN_OPTIONS = -I$(POVRAY_ROOT)/scenes/advanced/chess2.pov -L$(POVRAY_ROOT)/include -GA$<.junk -O-
 include $(LEVEL)/MultiSource/Makefile.multisrc





From criswell at cs.uiuc.edu  Wed Dec  8 14:36:01 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 8 Dec 2004 14:36:01 -0600
Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html 
Message-ID: <200412082036.OAA24066@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

ReleaseNotes.html updated: 1.279 -> 1.280
---
Log message:

The noreturn GCC extension is now supported.
Fixed some minor typos.


---
Diffs of the changes:  (+6 -5)

Index: llvm/docs/ReleaseNotes.html
diff -u llvm/docs/ReleaseNotes.html:1.279 llvm/docs/ReleaseNotes.html:1.280
--- llvm/docs/ReleaseNotes.html:1.279	Wed Dec  8 12:29:38 2004
+++ llvm/docs/ReleaseNotes.html	Wed Dec  8 14:35:47 2004
@@ -132,7 +132,7 @@
   C/C++ and Stacker front ends support generating the required dependencies. 
   The linker now supports using this information to ensure required libaries are
   linked into the module. This minimizes the need to use the -l option
-  when using llvmc
+  when using llvmc.
   
   
  • The LLVM makefiles have been improved to build LLVM much faster and 
   includes new targets (like dist-check, uninstall). One important user-visible
@@ -297,7 +297,7 @@
 
 
    
 
-
    LLVM is known to work in the following platforms:
    
+
    LLVM is known to work on the following platforms:
    
 
 
      
 
    • Intel and AMD machines running Red Hat Linux and FreeBSD (and probably 
@@ -472,10 +472,11 @@
       return.
      
 
       Supported: format, format_arg, non_null,
-      constructor, destructor, unused,
+      noreturn, constructor, destructor,
+      unused,
       deprecated, warn_unused_result, weak
      
 
-      Ignored: noreturn, noinline,
+      Ignored: noinline,
       always_inline, pure, const, nothrow,
       malloc, no_instrument_function, cdecl
      
 
@@ -716,7 +717,7 @@
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" />
 
   The LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2004/12/08 18:29:38 $
+  Last modified: $Date: 2004/12/08 20:35:47 $
 
 
 





From criswell at cs.uiuc.edu  Wed Dec  8 14:39:47 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 8 Dec 2004 14:39:47 -0600
Subject: [llvm-commits] CVS: llvm-test/LICENSE.TXT 
Message-ID: <200412082039.OAA24087@choi.cs.uiuc.edu>



Changes in directory llvm-test:

LICENSE.TXT updated: 1.4 -> 1.5
---
Log message:

Removed libpng and zlib.


---
Diffs of the changes:  (+0 -2)

Index: llvm-test/LICENSE.TXT
diff -u llvm-test/LICENSE.TXT:1.4 llvm-test/LICENSE.TXT:1.5
--- llvm-test/LICENSE.TXT:1.4	Tue Dec  7 10:38:58 2004
+++ llvm-test/LICENSE.TXT	Wed Dec  8 14:39:33 2004
@@ -92,5 +92,3 @@
 SingleSource Tests: llvm-test/SingleSource/Benchmarks/Misc
                     llvm-test/SingleSource/CustomChecked
                     llvm-test/SingleSource/Gizmos
-zlib:               llvm-test/Runtime/zlib
-libpng:             llvm-test/Runtime/libpng





From lattner at cs.uiuc.edu  Wed Dec  8 14:59:32 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed, 8 Dec 2004 14:59:32 -0600
Subject: [llvm-commits] CVS: llvm/include/llvm/ADT/HashExtras.h 
Message-ID: <200412082059.iB8KxWQ3017952@apoc.cs.uiuc.edu>



Changes in directory llvm/include/llvm/ADT:

HashExtras.h updated: 1.11 -> 1.12
---
Log message:

Define the pointer hash struct before the string one, to improve compatibility
with ICC.  Patch contributed by Bj?rn Wennberg.


---
Diffs of the changes:  (+6 -6)

Index: llvm/include/llvm/ADT/HashExtras.h
diff -u llvm/include/llvm/ADT/HashExtras.h:1.11 llvm/include/llvm/ADT/HashExtras.h:1.12
--- llvm/include/llvm/ADT/HashExtras.h:1.11	Wed Sep  1 17:55:34 2004
+++ llvm/include/llvm/ADT/HashExtras.h	Wed Dec  8 14:59:18 2004
@@ -23,12 +23,6 @@
 // Cannot specialize hash template from outside of the std namespace.
 namespace HASH_NAMESPACE {
 
-template <> struct hash {
-  size_t operator()(std::string const &str) const {
-    return hash()(str.c_str());
-  }
-};
-
 // Provide a hash function for arbitrary pointers...
 template  struct hash {
   inline size_t operator()(const T *Val) const {
@@ -36,6 +30,12 @@
   }
 };
 
+template <> struct hash {
+  size_t operator()(std::string const &str) const {
+    return hash()(str.c_str());
+  }
+};
+
 }  // End namespace std
 
 #endif





From lattner at cs.uiuc.edu  Wed Dec  8 15:01:12 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed, 8 Dec 2004 15:01:12 -0600
Subject: [llvm-commits] CVS: llvm/lib/Analysis/AliasAnalysis.cpp 
Message-ID: <200412082101.iB8L1CuN018711@apoc.cs.uiuc.edu>



Changes in directory llvm/lib/Analysis:

AliasAnalysis.cpp updated: 1.20 -> 1.21
---
Log message:

Properly extern this.


---
Diffs of the changes:  (+3 -1)

Index: llvm/lib/Analysis/AliasAnalysis.cpp
diff -u llvm/lib/Analysis/AliasAnalysis.cpp:1.20 llvm/lib/Analysis/AliasAnalysis.cpp:1.21
--- llvm/lib/Analysis/AliasAnalysis.cpp:1.20	Thu Jul 29 12:14:54 2004
+++ llvm/lib/Analysis/AliasAnalysis.cpp	Wed Dec  8 15:00:59 2004
@@ -188,5 +188,7 @@
 // the risk of AliasAnalysis being used, but the default implementation not
 // being linked into the tool that uses it.
 //
-extern void llvm::BasicAAStub();
+namespace llvm {
+  extern void BasicAAStub();
+}
 static IncludeFile INCLUDE_BASICAA_CPP((void*)&BasicAAStub);





From lattner at cs.uiuc.edu  Wed Dec  8 15:04:08 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed, 8 Dec 2004 15:04:08 -0600
Subject: [llvm-commits] 
	CVS: llvm/lib/Analysis/DataStructure/DataStructure.cpp
Message-ID: <200412082104.iB8L48c3018910@apoc.cs.uiuc.edu>



Changes in directory llvm/lib/Analysis/DataStructure:

DataStructure.cpp updated: 1.184 -> 1.185
---
Log message:

Move method out of line for better ICC support
Add some ifdefs for some stuff I like to be able to toggle easily


---
Diffs of the changes:  (+11 -0)

Index: llvm/lib/Analysis/DataStructure/DataStructure.cpp
diff -u llvm/lib/Analysis/DataStructure/DataStructure.cpp:1.184 llvm/lib/Analysis/DataStructure/DataStructure.cpp:1.185
--- llvm/lib/Analysis/DataStructure/DataStructure.cpp:1.184	Sun Oct 31 13:57:43 2004
+++ llvm/lib/Analysis/DataStructure/DataStructure.cpp	Wed Dec  8 15:03:56 2004
@@ -27,6 +27,8 @@
 #include 
 using namespace llvm;
 
+#define COLLAPSE_ARRAYS_AGGRESSIVELY 0
+
 namespace {
   Statistic<> NumFolds          ("dsa", "Number of nodes completely folded");
   Statistic<> NumCallNodesMerged("dsa", "Number of call nodes merged");
@@ -651,12 +653,14 @@
   // If the two nodes are of different size, and the smaller node has the array
   // bit set, collapse!
   if (NSize != CurNodeH.getNode()->getSize()) {
+#if COLLAPSE_ARRAYS_AGGRESSIVELY
     if (NSize < CurNodeH.getNode()->getSize()) {
       if (NH.getNode()->isArray())
         NH.getNode()->foldNodeCompletely();
     } else if (CurNodeH.getNode()->isArray()) {
       NH.getNode()->foldNodeCompletely();
     }
+#endif
   }
 
   // Merge the type entries of the two nodes together...    
@@ -895,6 +899,7 @@
       } else if (SN->getSize() != DN->getSize()) {
         // If the two nodes are of different size, and the smaller node has the
         // array bit set, collapse!
+#if COLLAPSE_ARRAYS_AGGRESSIVELY
         if (SN->getSize() < DN->getSize()) {
           if (SN->isArray()) {
             DN->foldNodeCompletely();
@@ -904,6 +909,7 @@
           DN->foldNodeCompletely();
           DN = NH.getNode();
         }
+#endif
       }
     
       // Merge the type entries of the two nodes together...    
@@ -1934,6 +1940,11 @@
   DEBUG(AssertGraphOK(); GlobalsGraph->AssertGraphOK());
 }
 
+void DSGraph::AssertNodeContainsGlobal(const DSNode *N, GlobalValue *GV) const {
+  assert(std::find(N->getGlobals().begin(), N->getGlobals().end(), GV) !=
+         N->getGlobals().end() && "Global value not in node!");
+}
+
 void DSGraph::AssertCallSiteInGraph(const DSCallSite &CS) const {
   if (CS.isIndirectCall()) {
     AssertNodeInGraph(CS.getCalleeNode());





From lattner at cs.uiuc.edu  Wed Dec  8 15:04:23 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed, 8 Dec 2004 15:04:23 -0600
Subject: [llvm-commits] 
	CVS: llvm/include/llvm/Analysis/DataStructure/DSGraph.h
Message-ID: <200412082104.iB8L4NU8018920@apoc.cs.uiuc.edu>



Changes in directory llvm/include/llvm/Analysis/DataStructure:

DSGraph.h updated: 1.81 -> 1.82
---
Log message:

Move method out of line


---
Diffs of the changes:  (+1 -4)

Index: llvm/include/llvm/Analysis/DataStructure/DSGraph.h
diff -u llvm/include/llvm/Analysis/DataStructure/DSGraph.h:1.81 llvm/include/llvm/Analysis/DataStructure/DSGraph.h:1.82
--- llvm/include/llvm/Analysis/DataStructure/DSGraph.h:1.81	Wed Jul  7 01:29:26 2004
+++ llvm/include/llvm/Analysis/DataStructure/DSGraph.h	Wed Dec  8 15:04:10 2004
@@ -372,10 +372,7 @@
     assert((!N || N->getParentGraph() == this) &&
            "AssertNodeInGraph: Node is not in graph!");
   }
-  void AssertNodeContainsGlobal(const DSNode *N, GlobalValue *GV) const {
-    assert(std::find(N->getGlobals().begin(), N->getGlobals().end(), GV) !=
-           N->getGlobals().end() && "Global value not in node!");
-  }
+  void AssertNodeContainsGlobal(const DSNode *N, GlobalValue *GV) const;
 
   void AssertCallSiteInGraph(const DSCallSite &CS) const;
   void AssertCallNodesInGraph() const;





From criswell at cs.uiuc.edu  Wed Dec  8 15:52:33 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 8 Dec 2004 15:52:33 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/CFEBuildInstrs.html 
Message-ID: <200412082152.PAA20320@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

CFEBuildInstrs.html updated: 1.32 -> 1.32.2.1
---
Log message:

The test/Programs suite is now in llvm-test.
Rename C frontend to GCC frontend to be consistent with other docs and to
help people understand that it's "just not a C compiler."



---
Diffs of the changes:  (+13 -14)

Index: llvm/docs/CFEBuildInstrs.html
diff -u llvm/docs/CFEBuildInstrs.html:1.32 llvm/docs/CFEBuildInstrs.html:1.32.2.1
--- llvm/docs/CFEBuildInstrs.html:1.32	Sat Dec  4 02:13:20 2004
+++ llvm/docs/CFEBuildInstrs.html	Wed Dec  8 15:52:17 2004
@@ -45,7 +45,6 @@
 
 
        
   
      1. you really, really, really can't use the binaries we distribute
        2. 
-  
      2. you need GCC to fix some of the header files on your system
        3. 
   
      3. you are an elite GCC hacker.
        4. 
 
      
 
@@ -59,7 +58,7 @@
 
 
 
      
-
      If you are building LLVM and the C front-end under Cygwin, please note that
+
      If you are building LLVM and the GCC front-end under Cygwin, please note that
 the LLVM and GCC makefiles do not correctly handle spaces in paths.  To deal
 with this issue, make sure that your LLVM and GCC source and build trees are 
 located in a top-level directory (like /cygdrive/c/llvm and 
@@ -76,7 +75,7 @@
 
 
 
      
-
      If you are building LLVM and the C front-end under AIX, do NOT use GNU
+
      If you are building LLVM and the GCC front-end under AIX, do NOT use GNU
 Binutils.  They are not stable under AIX and may produce incorrect and/or
 invalid code.  Instead, use the system assembler and linker.
 
      
@@ -121,7 +120,7 @@
    • -

  • Configure, build, and install the C front-end:

    +

  • Configure, build, and install the GCC front-end:

    Linux/x86:
    @@ -176,7 +175,7 @@

    • Fix 1: If you have system header files that include inline assembly, you may have to modify them to remove the inline - assembly, and install the modified versions in + assembly and install the modified versions in $CFEINSTALL/lib/gcc/target-triplet/3.4-llvm/include.

    • Fix 2: If you are building the C++ front-end on a CPU we @@ -186,10 +185,10 @@ and apply a patch so that it does not use inline assembly.
    -

    Porting to a new architecture: If you are porting the new front-end - to a new architecture, or compiling in a different configuration that we have - previously, there are probably several changes you will have to make to the GCC - target to get it to work correctly. These include:

    +

    Porting to a new architecture: If you are porting the front-end + to a new architecture or compiling in a configuration that we have + not tried previously, there are probably several changes you will have to make + to the GCC target to get it to work correctly. These include:

    • Often targets include special assembler or linker flags which @@ -216,7 +215,7 @@

    • Go back into the LLVM source tree proper. Rerun configure, using the --with-llvmgccdir=$CFEINSTALL option to specify the path -to the newly built C front-end.

      • +to the newly built GCC front-end.

    • If you edited header files during the C/C++ front-end build as described in "Fix 1" above, you must now copy those header files from @@ -228,7 +227,7 @@

    • Rebuild your CVS tree. This shouldn't cause the whole thing to be rebuilt, but it should build the runtime libraries. After the tree is - built, install the runtime libraries into your C front-end build tree. + built, install the runtime libraries into your GCC front-end build tree. These are the commands you need.

        % gmake
@@ -255,8 +254,8 @@
 following means:
      
  
        
   
      •  compiling and running a "hello, LLVM" program in C and C++.
        • 
-  
      •  running the tests under test/Programs using gmake -C
-   test/Programs
        • 
+  
      •  running the regression tests in llvm/test
+  
      •  running the tests found in the llvm-test CVS module
        •
    • @@ -333,7 +332,7 @@ Brian Gaeke
    LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/12/04 08:13:20 $ + Last modified: $Date: 2004/12/08 21:52:17 $ From alkis at cs.uiuc.edu Wed Dec 8 16:05:13 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Wed, 8 Dec 2004 16:05:13 -0600 Subject: [llvm-commits] CVS: llvm-java/class Message-ID: <200412082205.QAA31614@zion.cs.uiuc.edu> Changes in directory llvm-java: class added (r1.1) --- Log message: Move llvm configuration file in the Java project. --- Diffs of the changes: (+65 -0) Index: llvm-java/class diff -c /dev/null llvm-java/class:1.1 *** /dev/null Wed Dec 8 16:05:12 2004 --- llvm-java/class Wed Dec 8 16:05:02 2004 *************** *** 0 **** --- 1,65 ---- + # Java Configuration File For llvmc + + ########################################################## + # Language definitions + ########################################################## + lang.name=Java + lang.opt1=-simplifycfg -mem2reg -instcombine + lang.opt2= + lang.opt3= + lang.opt4= + lang.opt5= + # lang.libs=@LLVM_OBJ_ROOT@/projects/Java/Debug/lib + + ########################################################## + # Pre-processor definitions + ########################################################## + + # Java doesn't have a preprocessor but the following + # allows the -E option to be supported + preprocessor.command=cp %in% %out% + preprocessor.required=false + + ########################################################## + # Translator definitions + ########################################################## + + # To compile java class files, we just run the + # class2llvm compiler with the correct classpath. + translator.command=class2llvm \ + %in% %force% -o %out% %time% %stats% %args% + + # class2llvm doesn't preprocess but we set this to true + # so that we don't run the cp command by default. + translator.preprocesses=true + + # The translator is required to run. + translator.required=true + + # class2llvm outputs llvm bytecode + translator.output=bytecode + + ########################################################## + # Optimizer definitions + ########################################################## + + # For optimization, we use the LLVM "opt" program + optimizer.command=opt \ + %in% %force% -o %out% %opt% %time% %stats% %args% + + optimizer.required = true + + # opt doesn't translate + optimizer.translates=false + + # opt doesn't preprocess + optimizer.preprocesses=false + + # opt produces bytecode + optimizer.output=bytecode + + ########################################################## + # Assembler definitions + ########################################################## + assembler.command=llc \ + %in% %force% -o %out% %target% %time% %stats% %args% From lattner at cs.uiuc.edu Wed Dec 8 16:18:50 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Wed, 8 Dec 2004 16:18:50 -0600 Subject: [llvm-commits] CVS: llvm/test/Regression/Transforms/InstCombine/2004-12-08-RemInfiniteLoop.ll Message-ID: <200412082218.iB8MIoix029193@apoc.cs.uiuc.edu> Changes in directory llvm/test/Regression/Transforms/InstCombine: 2004-12-08-RemInfiniteLoop.ll added (r1.1) --- Log message: This testcase causes the instruction combiner to go spiraling into an infinite loop. --- Diffs of the changes: (+6 -0) Index: llvm/test/Regression/Transforms/InstCombine/2004-12-08-RemInfiniteLoop.ll diff -c /dev/null llvm/test/Regression/Transforms/InstCombine/2004-12-08-RemInfiniteLoop.ll:1.1 *** /dev/null Wed Dec 8 16:18:46 2004 --- llvm/test/Regression/Transforms/InstCombine/2004-12-08-RemInfiniteLoop.ll Wed Dec 8 16:18:35 2004 *************** *** 0 **** --- 1,6 ---- + ; RUN: llvm-as < %s | opt -instcombine + + int %test(int %X) { + %Y = rem int %X, undef + ret int %Y + } From lattner at cs.uiuc.edu Wed Dec 8 16:20:47 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Wed, 8 Dec 2004 16:20:47 -0600 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Scalar/InstructionCombining.cpp Message-ID: <200412082220.iB8MKlHB029491@apoc.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Scalar: InstructionCombining.cpp updated: 1.288 -> 1.289 --- Log message: Fix Transforms/InstCombine/2004-12-08-RemInfiniteLoop.ll --- Diffs of the changes: (+2 -1) Index: llvm/lib/Transforms/Scalar/InstructionCombining.cpp diff -u llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.288 llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.289 --- llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.288 Sun Nov 28 15:31:15 2004 +++ llvm/lib/Transforms/Scalar/InstructionCombining.cpp Wed Dec 8 16:20:34 2004 @@ -309,7 +309,8 @@ // Constants can be considered to be negated values if they can be folded... if (Constant *C = dyn_cast(V)) - return ConstantExpr::getNeg(C); + if (!isa(C)) + return ConstantExpr::getNeg(C); return 0; } From reid at x10sys.com Wed Dec 8 16:58:44 2004 From: reid at x10sys.com (Reid Spencer) Date: Wed, 8 Dec 2004 16:58:44 -0600 Subject: [llvm-commits] CVS: llvm/Makefile.rules Message-ID: <200412082258.QAA00425@zion.cs.uiuc.edu> Changes in directory llvm: Makefile.rules updated: 1.255 -> 1.256 --- Log message: Implement the LLVM_DO_NOT_BUILD feature. If a file of that name is present in a directory that LLVM normally builds, it will skip building the directory entirely. This is useful for allowing a bunch of projects to live in the source tree but not be compiled from time to time. --- Diffs of the changes: (+12 -5) Index: llvm/Makefile.rules diff -u llvm/Makefile.rules:1.255 llvm/Makefile.rules:1.256 --- llvm/Makefile.rules:1.255 Tue Dec 7 22:34:51 2004 +++ llvm/Makefile.rules Wed Dec 8 16:58:34 2004 @@ -231,7 +231,6 @@ CXX.Flags += -v LD.Flags += -v VERBOSE := 1 -else endif # Adjust settings for verbose mode @@ -370,7 +369,9 @@ $(MKDIR) $$dir; \ cp $(BUILD_SRC_DIR)/$$dir/Makefile $$dir/Makefile; \ fi; \ - ($(MAKE) -C $$dir $@ ) || exit 1; \ + if [ ! -f $$dir/LLVM_DO_NOT_BUILD ]; then \ + ($(MAKE) -C $$dir $@ ) || exit 1; \ + fi ; \ done endif @@ -385,7 +386,9 @@ $(MKDIR) $$dir; \ cp $(BUILD_SRC_DIR)/$$dir/Makefile $$dir/Makefile; \ fi; \ - ($(MAKE) -C $$dir $@ ) || exit 0; \ + if [ ! -f $$dir/LLVM_DO_NOT_BUILD ]; then \ + ($(MAKE) -C $$dir $@ ) || exit 0; \ + fi ; \ done endif @@ -411,7 +414,9 @@ $(MKDIR) $(@D); \ cp $(BUILD_SRC_DIR)/$(@D)/Makefile $(@D)/Makefile; \ fi; \ - $(MAKE) -C $(@D) $(subst $(@D)/.make,,$@) + if [ ! -f $$dir/LLVM_DO_NOT_BUILD ]; then \ + $(MAKE) -C $(@D) $(subst $(@D)/.make,,$@) ; \ + fi endif #--------------------------------------------------------- @@ -429,7 +434,9 @@ $(MKDIR) $$dir; \ cp $(BUILD_SRC_DIR)/$$dir/Makefile $$dir/Makefile; \ fi; \ - ($(MAKE) -C$$dir $@ ) || exit 1; \ + if [ ! -f $$dir/LLVM_DO_NOT_BUILD ]; then \ + ($(MAKE) -C$$dir $@ ) || exit 1; \ + fi ; \ fi \ done endif From reid at x10sys.com Wed Dec 8 17:07:38 2004 From: reid at x10sys.com (Reid Spencer) Date: Wed, 8 Dec 2004 17:07:38 -0600 Subject: [llvm-commits] CVS: llvm/autoconf/configure.ac Message-ID: <200412082307.RAA00637@zion.cs.uiuc.edu> Changes in directory llvm/autoconf: configure.ac updated: 1.138 -> 1.139 --- Log message: Remove last remnants of Python/QMTest support --- Diffs of the changes: (+27 -35) Index: llvm/autoconf/configure.ac diff -u llvm/autoconf/configure.ac:1.138 llvm/autoconf/configure.ac:1.139 --- llvm/autoconf/configure.ac:1.138 Tue Nov 30 02:11:54 2004 +++ llvm/autoconf/configure.ac Wed Dec 8 17:07:27 2004 @@ -262,8 +262,6 @@ AC_PATH_PROG(GZIP,[gzip],[true gzip]) AC_PATH_PROG(POD2HTML,[pod2html],[true pod2html]) AC_PATH_PROG(POD2MAN,[pod2man],[true pod2man]) -AC_PATH_PROG(PYTHON,[python],[true python]) -AC_PATH_PROG(QMTEST,[qmtest],[true qmtest]) AC_PATH_PROG(RUNTEST,[runtest],[true runtest]) DJ_AC_PATH_TCLSH AC_PATH_PROG(ZIP,[zip],[true zip]) @@ -289,22 +287,41 @@ AC_MSG_CHECKING([tool compatibility]) -dnl Ensure that compilation tools are GCC; we use GCC specific extensions -if test "$GCC" != "yes" +dnl Ensure that compilation tools are GCC or a GNU compatible compiler such as +dnl ICC; we use GCC specific options in the makefiles so the compiler needs +dnl to support those options. +dnl "icc" emits gcc signatures +dnl "icc -no-gcc" emits no gcc signature BUT is still compatible +ICC=no +IXX=no +case $CC in + icc*|icpc*) + ICC=yes + IXX=yes + ;; + *) + ;; +esac + +if test "$GCC" != "yes" && test "$ICC" != "yes" then - AC_MSG_ERROR([gcc required but not found]) + AC_MSG_ERROR([gcc|icc required but not found]) fi + dnl Ensure that compilation tools are GCC; we use GCC specific extensions -if test "$GXX" != "yes" +if test "$GXX" != "yes" && test "$IXX" != "yes" then - AC_MSG_ERROR([g++ required but not found]) + AC_MSG_ERROR([g++|icc required but not found]) fi dnl Verify that GCC is version 3.0 or higher -gccmajor=`$CC --version | head -n 1 | awk '{print $NF;}' | cut -d. -f1` -if test "$gccmajor" -lt "3" +if test "$GCC" = "yes" then - AC_MSG_ERROR([gcc 3.x required, but you have a lower version]) + gccmajor=`$CC --version | head -n 1 | awk '{print $NF;}' | cut -d. -f1` + if test "$gccmajor" -lt "3" + then + AC_MSG_ERROR([gcc 3.x required, but you have a lower version]) + fi fi dnl Check for GNU Make. We use its extensions, so don't build without it @@ -316,31 +333,6 @@ dnl Tool compatibility is okay if we make it here. AC_MSG_RESULT([ok]) -dnl Generate warnings for things not found but not strictly needed -if test "$PYTHON" = "false" ; then - AC_MSG_WARN([Python is required for the test suite, but it was not found]) -fi -if test "$QMTEST" = "false" ; then - AC_MSG_WARN([QMTest is required for the test suite, but it was not found]) -fi -if test "$RUNTEST" = "false" ; then - AC_MSG_WARN([runtest (Deja-Gnu) is required for the test sute, but it was not found]) -fi -pyversion=`$PYTHON -V 2>&1 | cut -d\ -f2` -pymajor=`echo $pyversion | cut -d. -f1` -pyminor=`echo $pyversion | cut -d. -f2` -if test "$pymajor" -ge "2" ; then - if test "$pymajor" -eq "2" ; then - if test "$pyminor" -lt "2" ; then - AC_MSG_WARN([QMTest requires Python 2.2 or later]) - fi - fi -else - AC_MSG_WARN([QMTest requires Python 2.2 or later]) -fi - -AC_MSG_RESULT([]) - dnl===-----------------------------------------------------------------------=== dnl=== dnl=== SECTION 5: Check for libraries From reid at x10sys.com Wed Dec 8 17:07:38 2004 From: reid at x10sys.com (Reid Spencer) Date: Wed, 8 Dec 2004 17:07:38 -0600 Subject: [llvm-commits] CVS: llvm/Makefile.config.in configure Message-ID: <200412082307.RAA00640@zion.cs.uiuc.edu> Changes in directory llvm: Makefile.config.in updated: 1.41 -> 1.42 configure updated: 1.147 -> 1.148 --- Log message: Remove last remnants of Python/QMTest support --- Diffs of the changes: (+54 -152) Index: llvm/Makefile.config.in diff -u llvm/Makefile.config.in:1.41 llvm/Makefile.config.in:1.42 --- llvm/Makefile.config.in:1.41 Tue Nov 30 02:11:54 2004 +++ llvm/Makefile.config.in Wed Dec 8 17:07:27 2004 @@ -85,7 +85,6 @@ GZIP := @GZIP@ POD2HTML := @POD2HTML@ POD2MAN := @POD2MAN@ -PYTHON := @PYTHON@ RUNTEST := @RUNTEST@ TCLSH := @TCLSH@ ZIP := @ZIP@ Index: llvm/configure diff -u llvm/configure:1.147 llvm/configure:1.148 --- llvm/configure:1.147 Thu Dec 2 01:31:22 2004 +++ llvm/configure Wed Dec 8 17:07:27 2004 @@ -476,7 +476,7 @@ # include #endif" -ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS LLVM_COPYRIGHT subdirs build build_cpu build_vendor build_os host host_cpu host_vendor host_os target target_cpu target_vendor target_os OS ARCH ENDIAN CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT ENABLE_OPTIMIZED JIT ENABLE_DOXYGEN LLVMGCCDIR CPP CXX CXXFLAGS ac_ct_CXX LEX LEXLIB LEX_OUTPUT_ROOT FLEX YACC BISON ifGNUmake LN_S DATE FIND GREP MKDIR MV PAX RANLIB ac_ct_RANLIB RM SED TAR INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA BZIP2 DOT DOXYGEN ETAGS GROFF GZIP POD2HTML POD2MAN PYTHON QMTEST RUNTEST TCLSH ZIP EGREP INSTALL_LTDL_TRUE INSTALL_LTDL_FALSE CONVENIENCE_LTDL_TRUE CONVENIENCE_LTDL_FALSE LIBADD_DL ECHO AR ac_ct_AR STRIP ac! _ct_STRIP CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL ETAGSFLAGS ALLOCA MMAP_FILE LLVMGCC LLVMCC1 LLVMCC1PLUS SHLIBEXT LLVM_PREFIX LLVM_BINDIR LLVM_LIBDIR LLVM_DATADIR LLVM_DOCSDIR LLVM_ETCDIR LLVM_INCLUDEDIR LLVM_INFODIR LLVM_MANDIR LLVM_CONFIGTIME LIBOBJS LTLIBOBJS' +ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS LLVM_COPYRIGHT subdirs build build_cpu build_vendor build_os host host_cpu host_vendor host_os target target_cpu target_vendor target_os OS ARCH ENDIAN CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT ENABLE_OPTIMIZED JIT ENABLE_DOXYGEN LLVMGCCDIR CPP CXX CXXFLAGS ac_ct_CXX LEX LEXLIB LEX_OUTPUT_ROOT FLEX YACC BISON ifGNUmake LN_S DATE FIND GREP MKDIR MV PAX RANLIB ac_ct_RANLIB RM SED TAR INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA BZIP2 DOT DOXYGEN ETAGS GROFF GZIP POD2HTML POD2MAN RUNTEST TCLSH ZIP EGREP INSTALL_LTDL_TRUE INSTALL_LTDL_FALSE CONVENIENCE_LTDL_TRUE CONVENIENCE_LTDL_FALSE LIBADD_DL ECHO AR ac_ct_AR STRIP ac_ct_STRIP CXXC! PP F77 FFLAGS ac_ct_F77 LIBTOOL ETAGSFLAGS ALLOCA MMAP_FILE LLVMGCC LLVMCC1 LLVMCC1PLUS SHLIBEXT LLVM_PREFIX LLVM_BINDIR LLVM_LIBDIR LLVM_DATADIR LLVM_DOCSDIR LLVM_ETCDIR LLVM_INCLUDEDIR LLVM_INFODIR LLVM_MANDIR LLVM_CONFIGTIME LIBOBJS LTLIBOBJS' ac_subst_files='' # Initialize some variables set by options. @@ -5336,86 +5336,6 @@ echo "${ECHO_T}no" >&6 fi -# Extract the first word of "python", so it can be a program name with args. -set dummy python; ac_word=$2 -echo "$as_me:$LINENO: checking for $ac_word" >&5 -echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 -if test "${ac_cv_path_PYTHON+set}" = set; then - echo $ECHO_N "(cached) $ECHO_C" >&6 -else - case $PYTHON in - [\\/]* | ?:[\\/]*) - ac_cv_path_PYTHON="$PYTHON" # Let the user override the test with a path. - ;; - *) - as_save_IFS=$IFS; IFS=$PATH_SEPARATOR -for as_dir in $PATH -do - IFS=$as_save_IFS - test -z "$as_dir" && as_dir=. - for ac_exec_ext in '' $ac_executable_extensions; do - if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then - ac_cv_path_PYTHON="$as_dir/$ac_word$ac_exec_ext" - echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 - break 2 - fi -done -done - - test -z "$ac_cv_path_PYTHON" && ac_cv_path_PYTHON="true python" - ;; -esac -fi -PYTHON=$ac_cv_path_PYTHON - -if test -n "$PYTHON"; then - echo "$as_me:$LINENO: result: $PYTHON" >&5 -echo "${ECHO_T}$PYTHON" >&6 -else - echo "$as_me:$LINENO: result: no" >&5 -echo "${ECHO_T}no" >&6 -fi - -# Extract the first word of "qmtest", so it can be a program name with args. -set dummy qmtest; ac_word=$2 -echo "$as_me:$LINENO: checking for $ac_word" >&5 -echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 -if test "${ac_cv_path_QMTEST+set}" = set; then - echo $ECHO_N "(cached) $ECHO_C" >&6 -else - case $QMTEST in - [\\/]* | ?:[\\/]*) - ac_cv_path_QMTEST="$QMTEST" # Let the user override the test with a path. - ;; - *) - as_save_IFS=$IFS; IFS=$PATH_SEPARATOR -for as_dir in $PATH -do - IFS=$as_save_IFS - test -z "$as_dir" && as_dir=. - for ac_exec_ext in '' $ac_executable_extensions; do - if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then - ac_cv_path_QMTEST="$as_dir/$ac_word$ac_exec_ext" - echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 - break 2 - fi -done -done - - test -z "$ac_cv_path_QMTEST" && ac_cv_path_QMTEST="true qmtest" - ;; -esac -fi -QMTEST=$ac_cv_path_QMTEST - -if test -n "$QMTEST"; then - echo "$as_me:$LINENO: result: $QMTEST" >&5 -echo "${ECHO_T}$QMTEST" >&6 -else - echo "$as_me:$LINENO: result: no" >&5 -echo "${ECHO_T}no" >&6 -fi - # Extract the first word of "runtest", so it can be a program name with args. set dummy runtest; ac_word=$2 echo "$as_me:$LINENO: checking for $ac_word" >&5 @@ -8190,7 +8110,7 @@ lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext < conftest.$ac_ext + echo '#line 10104 "configure"' > conftest.$ac_ext if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 (eval $ac_compile) 2>&5 ac_status=$? @@ -10666,7 +10586,7 @@ # Provide some information about the compiler. -echo "$as_me:10669:" \ +echo "$as_me:10589:" \ "checking for Fortran 77 compiler version" >&5 ac_compiler=`set X $ac_compile; echo $2` { (eval echo "$as_me:$LINENO: \"$ac_compiler --version &5\"") >&5 @@ -11723,11 +11643,11 @@ -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:11726: $lt_compile\"" >&5) + (eval echo "\"\$as_me:11646: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:11730: \$? = $ac_status" >&5 + echo "$as_me:11650: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -11966,11 +11886,11 @@ -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:11969: $lt_compile\"" >&5) + (eval echo "\"\$as_me:11889: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:11973: \$? = $ac_status" >&5 + echo "$as_me:11893: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -12026,11 +11946,11 @@ -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:12029: $lt_compile\"" >&5) + (eval echo "\"\$as_me:11949: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:12033: \$? = $ac_status" >&5 + echo "$as_me:11953: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -14211,7 +14131,7 @@ lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext < conftest.$ac_ext <&5) + (eval echo "\"\$as_me:16425: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:16509: \$? = $ac_status" >&5 + echo "$as_me:16429: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -16562,11 +16482,11 @@ -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:16565: $lt_compile\"" >&5) + (eval echo "\"\$as_me:16485: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:16569: \$? = $ac_status" >&5 + echo "$as_me:16489: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -17923,7 +17843,7 @@ lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext < conftest.$ac_ext <&5) + (eval echo "\"\$as_me:18781: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:18865: \$? = $ac_status" >&5 + echo "$as_me:18785: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -18918,11 +18838,11 @@ -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:18921: $lt_compile\"" >&5) + (eval echo "\"\$as_me:18841: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:18925: \$? = $ac_status" >&5 + echo "$as_me:18845: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -20957,11 +20877,11 @@ -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:20960: $lt_compile\"" >&5) + (eval echo "\"\$as_me:20880: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:20964: \$? = $ac_status" >&5 + echo "$as_me:20884: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -21200,11 +21120,11 @@ -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:21203: $lt_compile\"" >&5) + (eval echo "\"\$as_me:21123: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:21207: \$? = $ac_status" >&5 + echo "$as_me:21127: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -21260,11 +21180,11 @@ -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:21263: $lt_compile\"" >&5) + (eval echo "\"\$as_me:21183: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:21267: \$? = $ac_status" >&5 + echo "$as_me:21187: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -23445,7 +23365,7 @@ lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext < conftest.$ac_ext <&5 echo $ECHO_N "checking tool compatibility... $ECHO_C" >&6 -if test "$GCC" != "yes" +ICC=no +IXX=no +case $CC in + icc*|icpc*) + ICC=yes + IXX=yes + ;; + *) + ;; +esac + +if test "$GCC" != "yes" && test "$ICC" != "yes" then - { { echo "$as_me:$LINENO: error: gcc required but not found" >&5 -echo "$as_me: error: gcc required but not found" >&2;} + { { echo "$as_me:$LINENO: error: gcc|icc required but not found" >&5 +echo "$as_me: error: gcc|icc required but not found" >&2;} { (exit 1); exit 1; }; } fi -if test "$GXX" != "yes" + +if test "$GXX" != "yes" && test "$IXX" != "yes" then - { { echo "$as_me:$LINENO: error: g++ required but not found" >&5 -echo "$as_me: error: g++ required but not found" >&2;} + { { echo "$as_me:$LINENO: error: g++|icc required but not found" >&5 +echo "$as_me: error: g++|icc required but not found" >&2;} { (exit 1); exit 1; }; } fi -gccmajor=`$CC --version | head -n 1 | awk '{print $NF;}' | cut -d. -f1` -if test "$gccmajor" -lt "3" +if test "$GCC" = "yes" then - { { echo "$as_me:$LINENO: error: gcc 3.x required, but you have a lower version" >&5 + gccmajor=`$CC --version | head -n 1 | awk '{print $NF;}' | cut -d. -f1` + if test "$gccmajor" -lt "3" + then + { { echo "$as_me:$LINENO: error: gcc 3.x required, but you have a lower version" >&5 echo "$as_me: error: gcc 3.x required, but you have a lower version" >&2;} { (exit 1); exit 1; }; } + fi fi if test -z "$llvm_cv_gnu_make_command" @@ -24605,36 +24540,6 @@ echo "$as_me:$LINENO: result: ok" >&5 echo "${ECHO_T}ok" >&6 -if test "$PYTHON" = "false" ; then - { echo "$as_me:$LINENO: WARNING: Python is required for the test suite, but it was not found" >&5 -echo "$as_me: WARNING: Python is required for the test suite, but it was not found" >&2;} -fi -if test "$QMTEST" = "false" ; then - { echo "$as_me:$LINENO: WARNING: QMTest is required for the test suite, but it was not found" >&5 -echo "$as_me: WARNING: QMTest is required for the test suite, but it was not found" >&2;} -fi -if test "$RUNTEST" = "false" ; then - { echo "$as_me:$LINENO: WARNING: runtest (Deja-Gnu) is required for the test sute, but it was not found" >&5 -echo "$as_me: WARNING: runtest (Deja-Gnu) is required for the test sute, but it was not found" >&2;} -fi -pyversion=`$PYTHON -V 2>&1 | cut -d\ -f2` -pymajor=`echo $pyversion | cut -d. -f1` -pyminor=`echo $pyversion | cut -d. -f2` -if test "$pymajor" -ge "2" ; then - if test "$pymajor" -eq "2" ; then - if test "$pyminor" -lt "2" ; then - { echo "$as_me:$LINENO: WARNING: QMTest requires Python 2.2 or later" >&5 -echo "$as_me: WARNING: QMTest requires Python 2.2 or later" >&2;} - fi - fi -else - { echo "$as_me:$LINENO: WARNING: QMTest requires Python 2.2 or later" >&5 -echo "$as_me: WARNING: QMTest requires Python 2.2 or later" >&2;} -fi - -echo "$as_me:$LINENO: result: " >&5 -echo "${ECHO_T}" >&6 - echo "$as_me:$LINENO: checking for elf_begin in -lelf" >&5 @@ -30327,8 +30232,6 @@ s, at GZIP@,$GZIP,;t t s, at POD2HTML@,$POD2HTML,;t t s, at POD2MAN@,$POD2MAN,;t t -s, at PYTHON@,$PYTHON,;t t -s, at QMTEST@,$QMTEST,;t t s, at RUNTEST@,$RUNTEST,;t t s, at TCLSH@,$TCLSH,;t t s, at ZIP@,$ZIP,;t t From llvm at cs.uiuc.edu Wed Dec 8 17:07:38 2004 From: llvm at cs.uiuc.edu (LLVM) Date: Wed, 8 Dec 2004 17:07:38 -0600 Subject: [llvm-commits] CVS: llvm/test/Scripts/prcontext.py Message-ID: <200412082307.RAA00634@zion.cs.uiuc.edu> Changes in directory llvm/test/Scripts: prcontext.py (r1.1) removed --- Log message: Remove last remnants of Python/QMTest support --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Wed Dec 8 17:09:48 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed, 8 Dec 2004 17:09:48 -0600 Subject: [llvm-commits] [release_14] CVS: llvm/docs/TestingGuide.html Message-ID: <200412082309.RAA09972@choi.cs.uiuc.edu> Changes in directory llvm/docs: TestingGuide.html updated: 1.20 -> 1.20.2.1 --- Log message: Minor fixes. --- Diffs of the changes: (+9 -7) Index: llvm/docs/TestingGuide.html diff -u llvm/docs/TestingGuide.html:1.20 llvm/docs/TestingGuide.html:1.20.2.1 --- llvm/docs/TestingGuide.html:1.20 Wed Dec 8 11:37:21 2004 +++ llvm/docs/TestingGuide.html Wed Dec 8 17:09:33 2004 @@ -102,7 +102,7 @@ programs in C and C++ is in the llvm-test module. This module should be checked out to the llvm/projects directory. When you configure the llvm module, the llvm-test module -will be automatically configured. Or you can do it manually.

    +will be automatically configured. Alternatively, you can configure the llvm-test module manually.

    To run all of the simple tests in LLVM using DejaGNU, use the master Makefile in the llvm/test directory:

    @@ -140,7 +140,7 @@
 
    The LLVM test suite contains two major categories of tests: code
 fragments and whole programs. Code fragments are in the llvm module
 under the directory under the llvm/test directory. The whole programs
-test suite are n the llvm-test module under the main directory.
    
+test suite are in the llvm-test module under the main directory.
    
 
 
 
@@ -251,12 +251,13 @@
 
    
 
    The LLVM test suite is partially driven by DejaGNU and partially
 driven by GNU Make. Specifically, the Features and Regression tests
-are all driven by DejaGNU. The llvm-test
+are all driven by DejaGNU. The llvm-test
 module is currently driven by a set of Makefiles.
    
 
 
    The DejaGNU structure is very simple, but does require some
-information to be set. This information is gathered via configure and
-is written to a file, site.exp in llvm/test. The llvm/test
+information to be set. This information is gathered via configure and
+is written to a file, site.exp in llvm/test. The
+llvm/test
 Makefile does this work for you.
    
 
 
    In order for DejaGNU to work, each directory of tests must have a
@@ -392,7 +393,8 @@
 tests. By default, it will run all of these tests.
    
 
 
    To run only the DejaGNU driven tests, run gmake at the
-command line in llvm/tests.  To run a specific directory of tests, specify the TESTSUITE.
+command line in llvm/tests.  To run a specific directory of tests, use the
+TESTSUITE variable.
 
    
 
 
    For example, to run the Regression tests, type 
@@ -511,7 +513,7 @@
 
   John T. Criswell
    
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/12/08 17:37:21 $
+  Last modified: $Date: 2004/12/08 23:09:33 $
 
 
 





From alkis at cs.uiuc.edu  Wed Dec  8 17:10:41 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Wed, 8 Dec 2004 17:10:41 -0600
Subject: [llvm-commits] 
	CVS: llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll
Message-ID: <200412082310.RAA00705@zion.cs.uiuc.edu>



Changes in directory llvm/test/Regression/Transforms/InstCombine:

2004-12-08-InstCombineCrash.ll updated: 1.2 -> 1.3
---
Log message:

Fix this regression and remove the XFAIL from this test.


---
Diffs of the changes:  (+0 -1)

Index: llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll
diff -u llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll:1.2 llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll:1.3
--- llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll:1.2	Wed Dec  8 12:43:39 2004
+++ llvm/test/Regression/Transforms/InstCombine/2004-12-08-InstCombineCrash.ll	Wed Dec  8 17:10:30 2004
@@ -1,5 +1,4 @@
 ; RUN: llvm-as %s -o - | opt -instcombine
-; XFAIL: *
 
 	%struct.llvm_java_object_base = type opaque
 	"java/lang/Object" = type { %struct.llvm_java_object_base }





From alkis at cs.uiuc.edu  Wed Dec  8 17:10:41 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Wed, 8 Dec 2004 17:10:41 -0600
Subject: [llvm-commits] 
	CVS: llvm/lib/Transforms/Scalar/InstructionCombining.cpp
Message-ID: <200412082310.RAA00708@zion.cs.uiuc.edu>



Changes in directory llvm/lib/Transforms/Scalar:

InstructionCombining.cpp updated: 1.289 -> 1.290
---
Log message:

Fix this regression and remove the XFAIL from this test.


---
Diffs of the changes:  (+5 -3)

Index: llvm/lib/Transforms/Scalar/InstructionCombining.cpp
diff -u llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.289 llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.290
--- llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.289	Wed Dec  8 16:20:34 2004
+++ llvm/lib/Transforms/Scalar/InstructionCombining.cpp	Wed Dec  8 17:10:30 2004
@@ -4216,9 +4216,11 @@
 
     // Instruction isn't dead, see if we can constant propagate it...
     if (Constant *C = ConstantFoldInstruction(I)) {
+      Value* Ptr = I->getOperand(0);
       if (isa(I) &&
-          cast(I->getOperand(0))->isNullValue() &&
-          !isa(C)) {
+          cast(Ptr)->isNullValue() &&
+          !isa(C) &&
+          cast(Ptr->getType())->getElementType()->isSized()) {
         // If this is a constant expr gep that is effectively computing an
         // "offsetof", fold it into 'cast int X to T*' instead of 'gep 0, 0, 12'
         bool isFoldableGEP = true;
@@ -4226,7 +4228,7 @@
           if (!isa(I->getOperand(i)))
             isFoldableGEP = false;
         if (isFoldableGEP) {
-          uint64_t Offset = TD->getIndexedOffset(I->getOperand(0)->getType(),
+          uint64_t Offset = TD->getIndexedOffset(Ptr->getType(),
                              std::vector(I->op_begin()+1, I->op_end()));
           C = ConstantUInt::get(Type::ULongTy, Offset);
           C = ConstantExpr::getCast(C, TD->getIntPtrType());





From lattner at cs.uiuc.edu  Wed Dec  8 17:41:32 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed, 8 Dec 2004 17:41:32 -0600
Subject: [llvm-commits] 
	CVS: llvm/test/Regression/Transforms/InstCombine/sink_instruction.ll
Message-ID: <200412082341.iB8NfWOD012342@apoc.cs.uiuc.edu>



Changes in directory llvm/test/Regression/Transforms/InstCombine:

sink_instruction.ll added (r1.1)
---
Log message:

new testcase


---
Diffs of the changes:  (+17 -0)

Index: llvm/test/Regression/Transforms/InstCombine/sink_instruction.ll
diff -c /dev/null llvm/test/Regression/Transforms/InstCombine/sink_instruction.ll:1.1
*** /dev/null	Wed Dec  8 17:41:27 2004
--- llvm/test/Regression/Transforms/InstCombine/sink_instruction.ll	Wed Dec  8 17:41:16 2004
***************
*** 0 ****
--- 1,17 ----
+ ; RUN: llvm-as < %s | opt -instcombine | llvm-dis | %prcontext div 1 | grep ret
+ 
+ ;; This tests that the instructions in the entry blocks are sunk into each
+ ;; arm of the 'if'.
+ 
+ int %foo(bool %C, int %A, int %B) {
+ entry:
+ 	%tmp.2 = div int %A, %B
+ 	%tmp.9 = add int %B, %A
+ 	br bool %C, label %then, label %endif
+ 
+ then:
+ 	ret int %tmp.9
+ 
+ endif:
+ 	ret int %tmp.2
+ }





From alkis at cs.uiuc.edu  Wed Dec  8 17:42:22 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Wed, 8 Dec 2004 17:42:22 -0600
Subject: [llvm-commits] 
	CVS: llvm/test/Regression/Analysis/BasicAA/2004-12-08-BasicAACrash.ll
Message-ID: <200412082342.RAA01187@zion.cs.uiuc.edu>



Changes in directory llvm/test/Regression/Analysis/BasicAA:

2004-12-08-BasicAACrash.ll added (r1.1)
---
Log message:

Add testcase and fix for another case where we query the size an
abstract type.


---
Diffs of the changes:  (+24 -0)

Index: llvm/test/Regression/Analysis/BasicAA/2004-12-08-BasicAACrash.ll
diff -c /dev/null llvm/test/Regression/Analysis/BasicAA/2004-12-08-BasicAACrash.ll:1.1
*** /dev/null	Wed Dec  8 17:42:21 2004
--- llvm/test/Regression/Analysis/BasicAA/2004-12-08-BasicAACrash.ll	Wed Dec  8 17:42:11 2004
***************
*** 0 ****
--- 1,24 ----
+ ; RUN: llvm-as < %s | opt -licm
+ 
+ "java/lang/Object" = type { %struct.llvm_java_object_base }
+ 	"java/lang/StringBuffer" = type { "java/lang/Object", int, { "java/lang/Object", uint, [0 x ushort] }*, bool }
+ 	%struct.llvm_java_object_base = type opaque
+ 
+ implementation   ; Functions:
+ 
+ void "java/lang/StringBuffer/setLength(I)V"(%struct.llvm_java_object_base*) {
+ bc0:
+ 	br bool false, label %bc40, label %bc65
+ 
+ bc65:		; preds = %bc0, %bc40
+ 	ret void
+ 
+ bc40:		; preds = %bc0, %bc40
+ 	%tmp75 = cast %struct.llvm_java_object_base* %0 to "java/lang/StringBuffer"*		; <"java/lang/StringBuffer"*> [#uses=1]
+ 	%tmp76 = getelementptr "java/lang/StringBuffer"* %tmp75, int 0, uint 1		;  [#uses=1]
+ 	store int 0, int* %tmp76
+ 	%tmp381 = cast %struct.llvm_java_object_base* %0 to "java/lang/StringBuffer"*		; <"java/lang/StringBuffer"*> [#uses=1]
+ 	%tmp392 = getelementptr "java/lang/StringBuffer"* %tmp381, int 0, uint 1		;  [#uses=1]
+ 	%tmp403 = load int* %tmp392		;  [#uses=0]
+ 	br bool false, label %bc40, label %bc65
+ }





From alkis at cs.uiuc.edu  Wed Dec  8 17:42:22 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Wed, 8 Dec 2004 17:42:22 -0600
Subject: [llvm-commits] CVS: llvm/lib/Analysis/BasicAliasAnalysis.cpp 
Message-ID: <200412082342.RAA01190@zion.cs.uiuc.edu>



Changes in directory llvm/lib/Analysis:

BasicAliasAnalysis.cpp updated: 1.59 -> 1.60
---
Log message:

Add testcase and fix for another case where we query the size an
abstract type.


---
Diffs of the changes:  (+12 -7)

Index: llvm/lib/Analysis/BasicAliasAnalysis.cpp
diff -u llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.59 llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.60
--- llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.59	Tue Dec  7 02:11:24 2004
+++ llvm/lib/Analysis/BasicAliasAnalysis.cpp	Wed Dec  8 17:42:11 2004
@@ -410,13 +410,18 @@
           // the size of the argument... build an index vector that is equal to
           // the arguments provided, except substitute 0's for any variable
           // indexes we find...
-          for (unsigned i = 0; i != GEPOperands.size(); ++i)
-            if (!isa(GEPOperands[i]))
-              GEPOperands[i] =Constant::getNullValue(GEPOperands[i]->getType());
-          int64_t Offset = getTargetData().getIndexedOffset(BasePtr->getType(),
-                                                            GEPOperands);
-          if (Offset >= (int64_t)V2Size || Offset <= -(int64_t)V1Size)
-            return NoAlias;
+          if (cast(
+                BasePtr->getType())->getElementType()->isSized()) {
+            for (unsigned i = 0; i != GEPOperands.size(); ++i)
+              if (!isa(GEPOperands[i]))
+                GEPOperands[i] =
+                  Constant::getNullValue(GEPOperands[i]->getType());
+            int64_t Offset =
+              getTargetData().getIndexedOffset(BasePtr->getType(), GEPOperands);
+
+            if (Offset >= (int64_t)V2Size || Offset <= -(int64_t)V1Size)
+              return NoAlias;
+          }
         }
       }
     }





From lattner at cs.uiuc.edu  Wed Dec  8 17:44:12 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed, 8 Dec 2004 17:44:12 -0600
Subject: [llvm-commits] 
	CVS: llvm/lib/Transforms/Scalar/InstructionCombining.cpp
Message-ID: <200412082344.iB8NiCRV012376@apoc.cs.uiuc.edu>



Changes in directory llvm/lib/Transforms/Scalar:

InstructionCombining.cpp updated: 1.290 -> 1.291
---
Log message:

Do extremely simple sinking of instructions when they are only used in a
successor block.  This turns cases like this:

x = a op b
if (c) {
  use x
}

into:

if (c) {
  x = a op b
  use x
}

This triggers 3965 times in spec, and is tested by 
Regression/Transforms/InstCombine/sink_instruction.ll

This appears to expose a bug in the X86 backend for 177.mesa, which I'm 
looking in to.



---
Diffs of the changes:  (+52 -1)

Index: llvm/lib/Transforms/Scalar/InstructionCombining.cpp
diff -u llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.290 llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.291
--- llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.290	Wed Dec  8 17:10:30 2004
+++ llvm/lib/Transforms/Scalar/InstructionCombining.cpp	Wed Dec  8 17:43:58 2004
@@ -43,12 +43,13 @@
 #include "llvm/Transforms/Utils/BasicBlockUtils.h"
 #include "llvm/Transforms/Utils/Local.h"
 #include "llvm/Support/CallSite.h"
+#include "llvm/Support/Debug.h"
 #include "llvm/Support/GetElementPtrTypeIterator.h"
 #include "llvm/Support/InstIterator.h"
 #include "llvm/Support/InstVisitor.h"
 #include "llvm/Support/PatternMatch.h"
-#include "llvm/Support/Debug.h"
 #include "llvm/ADT/Statistic.h"
+#include "llvm/ADT/STLExtras.h"
 #include 
 using namespace llvm;
 using namespace llvm::PatternMatch;
@@ -57,6 +58,7 @@
   Statistic<> NumCombined ("instcombine", "Number of insts combined");
   Statistic<> NumConstProp("instcombine", "Number of constant folds");
   Statistic<> NumDeadInst ("instcombine", "Number of dead inst eliminated");
+  Statistic<> NumSunkInst ("instcombine", "Number of instructions sunk");
 
   class InstCombiner : public FunctionPass,
                        public InstVisitor {
@@ -4189,6 +4191,32 @@
                  WorkList.end());
 }
 
+
+/// TryToSinkInstruction - Try to move the specified instruction from its
+/// current block into the beginning of DestBlock, which can only happen if it's
+/// safe to move the instruction past all of the instructions between it and the
+/// end of its block.
+static bool TryToSinkInstruction(Instruction *I, BasicBlock *DestBlock) {
+  assert(I->hasOneUse() && "Invariants didn't hold!");
+
+  // Cannot move control-flow-involving instructions.
+  if (isa(I) || isa(I) || isa(I)) return false;
+  
+  // Do not sink alloca instructions out of the entry block.
+  if (isa(I) && I->getParent() == &DestBlock->getParent()->front())
+    return false;
+
+  if (isa(I)) return false;
+
+  BasicBlock::iterator InsertPos = DestBlock->begin();
+  while (isa(InsertPos)) ++InsertPos;
+
+  BasicBlock *SrcBlock = I->getParent();
+  DestBlock->getInstList().splice(InsertPos, SrcBlock->getInstList(), I);  
+  ++NumSunkInst;
+  return true;
+}
+
 bool InstCombiner::runOnFunction(Function &F) {
   bool Changed = false;
   TD = &getAnalysis();
@@ -4246,6 +4274,29 @@
       continue;
     }
 
+    // See if we can trivially sink this instruction to a successor basic block.
+    if (I->hasOneUse()) {
+      BasicBlock *BB = I->getParent();
+      BasicBlock *UserParent = cast(I->use_back())->getParent();
+      if (UserParent != BB) {
+        bool UserIsSuccessor = false;
+        // See if the user is one of our successors.
+        for (succ_iterator SI = succ_begin(BB), E = succ_end(BB); SI != E; ++SI)
+          if (*SI == UserParent) {
+            UserIsSuccessor = true;
+            break;
+          }
+
+        // If the user is one of our immediate successors, and if that successor
+        // only has us as a predecessors (we'd have to split the critical edge
+        // otherwise), we can keep going.
+        if (UserIsSuccessor && !isa(I->use_back()) &&
+            next(pred_begin(UserParent)) == pred_end(UserParent))
+          // Okay, the CFG is simple enough, try to sink this instruction.
+          Changed |= TryToSinkInstruction(I, UserParent);
+      }
+    }
+
     // Now that we have an instruction, try combining it to simplify it...
     if (Instruction *Result = visit(*I)) {
       ++NumCombined;





From alkis at cs.uiuc.edu  Wed Dec  8 17:56:25 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Wed, 8 Dec 2004 17:56:25 -0600
Subject: [llvm-commits] 
	CVS: llvm/test/Regression/Analysis/BasicAA/2004-12-08-BasicAACrash2.ll
Message-ID: <200412082356.RAA01464@zion.cs.uiuc.edu>



Changes in directory llvm/test/Regression/Analysis/BasicAA:

2004-12-08-BasicAACrash2.ll added (r1.1)
---
Log message:

Add testcase and fix for yet another case where we query the size an
abstract type.


---
Diffs of the changes:  (+22 -0)

Index: llvm/test/Regression/Analysis/BasicAA/2004-12-08-BasicAACrash2.ll
diff -c /dev/null llvm/test/Regression/Analysis/BasicAA/2004-12-08-BasicAACrash2.ll:1.1
*** /dev/null	Wed Dec  8 17:56:25 2004
--- llvm/test/Regression/Analysis/BasicAA/2004-12-08-BasicAACrash2.ll	Wed Dec  8 17:56:15 2004
***************
*** 0 ****
--- 1,22 ----
+ ; RUN: llvm-as < %s | opt -dse
+ 
+ "java/lang/Object" = type { %struct.llvm_java_object_base }
+ 	"java/lang/StringBuffer" = type { "java/lang/Object", int, { "java/lang/Object", uint, [0 x ushort] }*, bool }
+ 	%struct.llvm_java_object_base = type opaque
+ 
+ implementation   ; Functions:
+ 
+ void "java/lang/StringBuffer/ensureCapacity_unsynchronized(I)V"() {
+ bc0:
+ 	%tmp = getelementptr "java/lang/StringBuffer"* null, int 0, uint 3		;  [#uses=1]
+ 	br bool false, label %bc16, label %bc7
+ 
+ bc16:		; preds = %bc0
+ 	%tmp91 = getelementptr "java/lang/StringBuffer"* null, int 0, uint 2		; <{ "java/lang/Object", uint, [0 x ushort] }**> [#uses=1]
+ 	store { "java/lang/Object", uint, [0 x ushort] }* null, { "java/lang/Object", uint, [0 x ushort] }** %tmp91
+ 	store bool false, bool* %tmp
+ 	ret void
+ 
+ bc7:		; preds = %bc0
+ 	ret void
+ }





From alkis at cs.uiuc.edu  Wed Dec  8 17:56:25 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Wed, 8 Dec 2004 17:56:25 -0600
Subject: [llvm-commits] CVS: llvm/lib/Analysis/BasicAliasAnalysis.cpp 
Message-ID: <200412082356.RAA01467@zion.cs.uiuc.edu>



Changes in directory llvm/lib/Analysis:

BasicAliasAnalysis.cpp updated: 1.60 -> 1.61
---
Log message:

Add testcase and fix for yet another case where we query the size an
abstract type.


---
Diffs of the changes:  (+11 -9)

Index: llvm/lib/Analysis/BasicAliasAnalysis.cpp
diff -u llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.60 llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.61
--- llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.60	Wed Dec  8 17:42:11 2004
+++ llvm/lib/Analysis/BasicAliasAnalysis.cpp	Wed Dec  8 17:56:15 2004
@@ -456,7 +456,7 @@
   if (BasePtr1Ty != BasePtr2Ty)
     return MayAlias;
 
-  const Type *GEPPointerTy = BasePtr1Ty;
+  const PointerType *GEPPointerTy = cast(BasePtr1Ty);
 
   // Find the (possibly empty) initial sequence of equal values... which are not
   // necessarily constants.
@@ -657,14 +657,16 @@
     }
   }
   
-  int64_t Offset1 = getTargetData().getIndexedOffset(GEPPointerTy, GEP1Ops);
-  int64_t Offset2 = getTargetData().getIndexedOffset(GEPPointerTy, GEP2Ops);
-  assert(Offset1 < Offset2 &&"There is at least one different constant here!");
-
-  if ((uint64_t)(Offset2-Offset1) >= SizeMax) {
-    //std::cerr << "Determined that these two GEP's don't alias [" 
-    //          << SizeMax << " bytes]: \n" << *GEP1 << *GEP2;
-    return NoAlias;
+  if (GEPPointerTy->getElementType()->isSized()) {
+    int64_t Offset1 = getTargetData().getIndexedOffset(GEPPointerTy, GEP1Ops);
+    int64_t Offset2 = getTargetData().getIndexedOffset(GEPPointerTy, GEP2Ops);
+    assert(Offset1= SizeMax) {
+      //std::cerr << "Determined that these two GEP's don't alias [" 
+      //          << SizeMax << " bytes]: \n" << *GEP1 << *GEP2;
+      return NoAlias;
+    }
   }
   return MayAlias;
 }





From alkis at cs.uiuc.edu  Wed Dec  8 18:01:00 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Wed, 8 Dec 2004 18:01:00 -0600
Subject: [llvm-commits] CVS: llvm-java/test/Makefile.test 
Message-ID: <200412090001.SAA01596@zion.cs.uiuc.edu>



Changes in directory llvm-java/test:

Makefile.test updated: 1.25 -> 1.26
---
Log message:

Now the optimization passes can handle the code generated by the
java-fe, enable them :-)


---
Diffs of the changes:  (+1 -1)

Index: llvm-java/test/Makefile.test
diff -u llvm-java/test/Makefile.test:1.25 llvm-java/test/Makefile.test:1.26
--- llvm-java/test/Makefile.test:1.25	Sun Dec  5 17:04:01 2004
+++ llvm-java/test/Makefile.test	Wed Dec  8 18:00:49 2004
@@ -24,7 +24,7 @@
 # rule to link bytecode with runtime
 %.llvm %.llvm.bc: %.linked.bc $(LibDir)/libjrt.bca $(EXTRA_OBJS) $(LOPT)
 	$(Echo) Linking $< with the Java runtime
-	$(Verb)$(GCCLD) -disable-opt -o=$*.llvm $< -L $(LibDir) $(EXTRA_OBJS)
+	$(Verb)$(GCCLD) -o=$*.llvm $< -L $(LibDir) $(EXTRA_OBJS)
 
 # rule to make assembly from bytecode
 %.dis-ll: %.bc





From alkis at cs.uiuc.edu  Wed Dec  8 18:01:00 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Wed, 8 Dec 2004 18:01:00 -0600
Subject: [llvm-commits] 
	CVS: llvm-java/test/Programs/SingleSource/Makefile.singlesrc
Message-ID: <200412090001.SAA01599@zion.cs.uiuc.edu>



Changes in directory llvm-java/test/Programs/SingleSource:

Makefile.singlesrc updated: 1.11 -> 1.12
---
Log message:

Now the optimization passes can handle the code generated by the
java-fe, enable them :-)


---
Diffs of the changes:  (+3 -9)

Index: llvm-java/test/Programs/SingleSource/Makefile.singlesrc
diff -u llvm-java/test/Programs/SingleSource/Makefile.singlesrc:1.11 llvm-java/test/Programs/SingleSource/Makefile.singlesrc:1.12
--- llvm-java/test/Programs/SingleSource/Makefile.singlesrc:1.11	Sun Dec  5 19:00:31 2004
+++ llvm-java/test/Programs/SingleSource/Makefile.singlesrc	Wed Dec  8 18:00:49 2004
@@ -12,18 +12,12 @@
 	$(Echo) Compiling $< to bytecode
 	$(Verb)$(CLASS2LLVM) -cp $(CLASSPATH):Output $(subst /,.,$(*F)) -o=$@
 
-# OPT_PASSES := -simplifycfg -mem2reg -globalopt -globaldce \
-#               -ipconstprop -deadargelim -instcombine -simplifycfg \
-#               -inline -argpromotion -raise -tailduplicate -simplifycfg \
-#               -scalarrepl -instcombine -tailcallelim -simplifycfg \
-#               -licm -instcombine -indvars -loop-unroll -instcombine \
-#               -load-vn -gcse -sccp -instcombine -dse -adce -simplifycfg \
-#               -deadtypeelim -constmerge
-
 OPT_PASSES := -simplifycfg -mem2reg -globalopt -globaldce \
               -ipconstprop -deadargelim -instcombine -simplifycfg \
               -inline -argpromotion -raise -tailduplicate -simplifycfg \
-              -gcse -sccp -adce -simplifycfg \
+              -scalarrepl -instcombine -tailcallelim -simplifycfg \
+              -licm -instcombine -indvars -loop-unroll -instcombine \
+              -load-vn -gcse -sccp -instcombine -dse -adce -simplifycfg \
               -deadtypeelim -constmerge
 
 # optimize raw bytecode





From alkis at cs.uiuc.edu  Wed Dec  8 22:11:24 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Wed, 8 Dec 2004 22:11:24 -0600
Subject: [llvm-commits] 
	CVS: llvm-java/test/Programs/SingleSource/UnitTests/FieldAccess.java
Message-ID: <200412090411.WAA04238@zion.cs.uiuc.edu>



Changes in directory llvm-java/test/Programs/SingleSource/UnitTests:

FieldAccess.java updated: 1.3 -> 1.4
---
Log message:

Pull FieldAccess class into FieldAccessDerived to make the test case cleaner

---
Diffs of the changes:  (+5 -3)

Index: llvm-java/test/Programs/SingleSource/UnitTests/FieldAccess.java
diff -u llvm-java/test/Programs/SingleSource/UnitTests/FieldAccess.java:1.3 llvm-java/test/Programs/SingleSource/UnitTests/FieldAccess.java:1.4
--- llvm-java/test/Programs/SingleSource/UnitTests/FieldAccess.java:1.3	Wed Nov 24 03:04:59 2004
+++ llvm-java/test/Programs/SingleSource/UnitTests/FieldAccess.java	Wed Dec  8 22:11:13 2004
@@ -3,13 +3,15 @@
     float f;
 }
 
-public class FieldAccess extends FieldAccessBase
-{
+class FieldAccessDerived extends FieldAccessBase {
     int i;
     double d;
+}
 
+public class FieldAccess
+{
     public static void main(String[] args) {
-        FieldAccess b = new FieldAccess();
+        FieldAccessDerived b = new FieldAccessDerived();
         b.d = 4.0;
         b.i = 3;
         b.f = 2.0F;





From alkis at cs.uiuc.edu  Wed Dec  8 22:19:00 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Wed, 8 Dec 2004 22:19:00 -0600
Subject: [llvm-commits] 
	CVS: llvm-java/test/Programs/SingleSource/UnitTests/MultipleInterfaces.java
Message-ID: <200412090419.WAA04450@zion.cs.uiuc.edu>



Changes in directory llvm-java/test/Programs/SingleSource/UnitTests:

MultipleInterfaces.java added (r1.1)
---
Log message:

Add test case that breaks the current object model: multiple interface inheritance

---
Diffs of the changes:  (+43 -0)

Index: llvm-java/test/Programs/SingleSource/UnitTests/MultipleInterfaces.java
diff -c /dev/null llvm-java/test/Programs/SingleSource/UnitTests/MultipleInterfaces.java:1.1
*** /dev/null	Wed Dec  8 22:19:00 2004
--- llvm-java/test/Programs/SingleSource/UnitTests/MultipleInterfaces.java	Wed Dec  8 22:18:50 2004
***************
*** 0 ****
--- 1,43 ----
+ interface MultipleInterfacesI1
+ {
+     public int i1();
+ }
+ 
+ interface MultipleInterfacesI2
+ {
+     public int i2();
+ }
+ 
+ interface MultipleInterfacesI3 extends MultipleInterfacesI1, MultipleInterfacesI2
+ {
+     public int i3();
+ }
+ 
+ class MultipleInterfacesClass implements MultipleInterfacesI3
+ {
+     public int i1() { return 3; }
+     public int i2() { return 3; }
+     public int i3() { return 3; }
+ }
+ 
+ public class MultipleInterfaces
+ {
+     public static void main(String[] args) {
+         MultipleInterfacesClass o = new MultipleInterfacesClass();
+         MultipleInterfacesI1 i1 = o;
+         MultipleInterfacesI2 i2 = o;
+         MultipleInterfacesI3 i3 = o;
+ 
+         Test.print_int_ln(o.i1());
+         Test.print_int_ln(o.i2());
+         Test.print_int_ln(o.i3());
+ 
+         Test.print_int_ln(i1.i1());
+ 
+         Test.print_int_ln(i2.i2());
+ 
+         Test.print_int_ln(i3.i1());
+         Test.print_int_ln(i3.i2());
+         Test.print_int_ln(i3.i3());
+     }
+ }





From alkis at cs.uiuc.edu  Wed Dec  8 22:20:07 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Wed, 8 Dec 2004 22:20:07 -0600
Subject: [llvm-commits] 
	CVS: llvm-java/test/Programs/SingleSource/UnitTests/MultipleInterfaces.java
Message-ID: <200412090420.WAA04510@zion.cs.uiuc.edu>



Changes in directory llvm-java/test/Programs/SingleSource/UnitTests:

MultipleInterfaces.java updated: 1.1 -> 1.2
---
Log message:

Return different values from the various methods of the implementing class

---
Diffs of the changes:  (+2 -2)

Index: llvm-java/test/Programs/SingleSource/UnitTests/MultipleInterfaces.java
diff -u llvm-java/test/Programs/SingleSource/UnitTests/MultipleInterfaces.java:1.1 llvm-java/test/Programs/SingleSource/UnitTests/MultipleInterfaces.java:1.2
--- llvm-java/test/Programs/SingleSource/UnitTests/MultipleInterfaces.java:1.1	Wed Dec  8 22:18:50 2004
+++ llvm-java/test/Programs/SingleSource/UnitTests/MultipleInterfaces.java	Wed Dec  8 22:19:56 2004
@@ -15,8 +15,8 @@
 
 class MultipleInterfacesClass implements MultipleInterfacesI3
 {
-    public int i1() { return 3; }
-    public int i2() { return 3; }
+    public int i1() { return 1; }
+    public int i2() { return 2; }
     public int i3() { return 3; }
 }
 





From criswell at cs.uiuc.edu  Wed Dec  8 22:27:08 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 8 Dec 2004 22:27:08 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/LangRef.html 
Message-ID: <200412090427.WAA30940@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

LangRef.html updated: 1.77 -> 1.77.2.1
---
Log message:

Nobody expects the Spanish Inquisition!
Fixed the number of terminator instructions from five to six.
Other minor fixes.


---
Diffs of the changes:  (+7 -7)

Index: llvm/docs/LangRef.html
diff -u llvm/docs/LangRef.html:1.77 llvm/docs/LangRef.html:1.77.2.1
--- llvm/docs/LangRef.html:1.77	Mon Nov  1 02:19:36 2004
+++ llvm/docs/LangRef.html	Wed Dec  8 22:26:53 2004
@@ -724,7 +724,7 @@
 finished. These terminator instructions typically yield a 'void'
 value: they produce control flow, not values (the one exception being
 the 'invoke' instruction).
    
-
    There are five different terminator instructions: the 'There are six different terminator instructions: the 'ret' instruction, the 'br'
 instruction, the 'switch' instruction,
 the 'invoke' instruction, the '
 
    Binary operators are used to do most of the computation in a
 program.  They require two operands, execute an operation on them, and
-produce a single value.  Although, that single value might represent 
+produce a single value.  The operands might represent 
 multiple data, as is the case with the packed data type. 
 The result value of a binary operator is not
 necessarily the same type as its operands.
    
@@ -1135,7 +1135,7 @@
 
    
 
    Bitwise binary operators are used to do various forms of
 bit-twiddling in a program.  They are generally very efficient
-instructions, and can commonly be strength reduced from other
+instructions and can commonly be strength reduced from other
 instructions.  They require two operands, execute an operation on them,
 and produce a single value.  The resulting value of the bitwise binary
 operators is always the same type as its first operand.
    
@@ -1360,7 +1360,7 @@
 
    A key design point of an SSA-based representation is how it
 represents memory.  In LLVM, no memory locations are in SSA form, which
 makes things very simple.  This section describes how to read, write,
-allocate and free memory in LLVM.
    
+allocate, and free memory in LLVM.
    
 
    
 
 
     'malloc'
@@ -1408,7 +1408,7 @@
 that was allocated with the 'malloc'
 instruction.
    
 
    Semantics:
    
-
    Access to the memory pointed to by the pointer is not longer defined
+
    Access to the memory pointed to by the pointer is no longer defined
 after this instruction executes.
    
 
    Example:
    
 
      %array  = malloc [4 x ubyte]                    ; yields {[4 x ubyte]*}:array
@@ -1428,7 +1428,7 @@
 stack frame of the procedure that is live until the current function
 returns to its caller.
    
 
    Arguments:
    
-
    The the 'alloca' instruction allocates sizeof(<type>)*NumElements
+
    The 'alloca' instruction allocates sizeof(<type>)*NumElements
 bytes of memory on the runtime stack, returning a pointer of the
 appropriate type to the program.  The second form of the instruction is
 a shorter version of the first that defaults to allocating one element.
    
@@ -2670,7 +2670,7 @@
 
   Chris Lattner
    
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/11/01 08:19:36 $
+  Last modified: $Date: 2004/12/09 04:26:53 $
 
 
 





From criswell at cs.uiuc.edu  Wed Dec  8 22:27:51 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 8 Dec 2004 22:27:51 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/CommandGuide/llvm-ar.pod
Message-ID: <200412090427.WAA30988@choi.cs.uiuc.edu>



Changes in directory llvm/docs/CommandGuide:

llvm-ar.pod updated: 1.8 -> 1.8.2.1
---
Log message:

Removed notes about zlib compression as we no longer support it.


---
Diffs of the changes:  (+6 -7)

Index: llvm/docs/CommandGuide/llvm-ar.pod
diff -u llvm/docs/CommandGuide/llvm-ar.pod:1.8 llvm/docs/CommandGuide/llvm-ar.pod:1.8.2.1
--- llvm/docs/CommandGuide/llvm-ar.pod:1.8	Sun Nov 28 21:37:15 2004
+++ llvm/docs/CommandGuide/llvm-ar.pod	Wed Dec  8 22:27:37 2004
@@ -23,7 +23,7 @@
 files. However, it cannot be used to write them.  While the B command 
 produces files that are I identical to the format used by other C 
 implementations, it has two significant departures in order to make the 
-archive appropriate for LLVM. There are first departure is that B only
+archive appropriate for LLVM. The first departure is that B only
 uses BSD4.4 style long path names (stored immediately after the header) and
 never contains a string table for long names. The second departure is that the
 symbol table is formated for efficient construction of an in-memory data
@@ -63,7 +63,7 @@
 B can compress the members of an archive to save space. The 
 compression used depends on what's available on the platform and what choices
 the LLVM Compressor utility makes. It generally favors bzip2 but will select
-between "no compression", bzip2 or zlib depending on what makes sense for the
+between "no compression" or bzip2 depending on what makes sense for the
 file's content.
 
 =item I
@@ -229,9 +229,9 @@
 =item [z] 
 
 When inserting or replacing any file in the archive, compress the file first.
-The compression will attempt to use the zlib compression algorithm. This
+This
 modifier is safe to use when (previously) compressed bytecode files are added to
-the archive; the compress bytecode files will not be doubly compressed.
+the archive; the compressed bytecode files will not be doubly compressed.
 
 =back
 
@@ -342,9 +342,8 @@
 string. If the size field is negative (starts with a minus sign, 0x02D), then
 the archive member is stored in compressed form. The first byte of the archive
 member's data indicates the compression type used. A value of 0 (0x30) indicates
-that no compression was used. A value of 1 (0x31) indicates that zlib
-compression was used. A value of 2 (0x32) indicates that bzip2 compression was
-used.
+that no compression was used. A value of 2 (0x32) indicates that bzip2
+compression was used.
 
 =item fmag - char[2]
 





From lattner at cs.uiuc.edu  Wed Dec  8 22:52:05 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed, 8 Dec 2004 22:52:05 -0600
Subject: [llvm-commits] CVS: llvm/lib/Bytecode/Reader/Reader.cpp 
Message-ID: <200412090452.iB94q5XR014900@apoc.cs.uiuc.edu>



Changes in directory llvm/lib/Bytecode/Reader:

Reader.cpp updated: 1.146 -> 1.147
---
Log message:

Eliminate this ugly hack.  This was put back in when replaceAllUsesOf used
a different algorithm that was extremely inefficient for instructions with
many operands.

This reduces the time of this code snippet from .23s for 176.gcc to 0.03s
in a debug build, which speeds up total llvm-dis time just barely.

It's more of a code cleanup than a speedup.


---
Diffs of the changes:  (+6 -30)

Index: llvm/lib/Bytecode/Reader/Reader.cpp
diff -u llvm/lib/Bytecode/Reader/Reader.cpp:1.146 llvm/lib/Bytecode/Reader/Reader.cpp:1.147
--- llvm/lib/Bytecode/Reader/Reader.cpp:1.146	Sat Dec  4 16:19:53 2004
+++ llvm/lib/Bytecode/Reader/Reader.cpp	Wed Dec  8 22:51:50 2004
@@ -30,6 +30,8 @@
 #include 
 using namespace llvm;
 
+#include "llvm/Support/Timer.h"
+
 namespace {
 
 /// @brief A class for maintaining the slot number definition
@@ -1690,39 +1692,13 @@
 
   // Resolve forward references.  Replace any uses of a forward reference value
   // with the real value.
-
-  // replaceAllUsesWith is very inefficient for instructions which have a LARGE
-  // number of operands.  PHI nodes often have forward references, and can also
-  // often have a very large number of operands.
-  //
-  // FIXME: REEVALUATE.  replaceAllUsesWith is _much_ faster now, and this code
-  // should be simplified back to using it!
-  //
-  std::map ForwardRefMapping;
-  for (std::map, Value*>::iterator 
-         I = ForwardReferences.begin(), E = ForwardReferences.end();
-       I != E; ++I)
-    ForwardRefMapping[I->second] = getValue(I->first.first, I->first.second,
-                                            false);
-
-  for (Function::iterator BB = F->begin(), E = F->end(); BB != E; ++BB)
-    for (BasicBlock::iterator I = BB->begin(), E = BB->end(); I != E; ++I)
-      for (unsigned i = 0, e = I->getNumOperands(); i != e; ++i)
-        if (Value* V = I->getOperand(i))
-          if (Argument *A = dyn_cast(V)) {
-            std::map::iterator It = ForwardRefMapping.find(A);
-            if (It != ForwardRefMapping.end()) I->setOperand(i, It->second);
-          }
-
   while (!ForwardReferences.empty()) {
-    std::map, Value*>::iterator I =
-      ForwardReferences.begin();
+    std::map, Value*>::iterator
+      I = ForwardReferences.begin();
+    Value *V = getValue(I->first.first, I->first.second, false);
     Value *PlaceHolder = I->second;
+    PlaceHolder->replaceAllUsesWith(V);
     ForwardReferences.erase(I);
-
-    // Now that all the uses are gone, delete the placeholder...
-    // If we couldn't find a def (error case), then leak a little
-    // memory, because otherwise we can't remove all uses!
     delete PlaceHolder;
   }
 





From lattner at cs.uiuc.edu  Wed Dec  8 22:53:30 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed, 8 Dec 2004 22:53:30 -0600
Subject: [llvm-commits] CVS: llvm/lib/Bytecode/Reader/Reader.cpp 
Message-ID: <200412090453.iB94rUeH014967@apoc.cs.uiuc.edu>



Changes in directory llvm/lib/Bytecode/Reader:

Reader.cpp updated: 1.147 -> 1.148
---
Log message:

Remove #include inadvertently added


---
Diffs of the changes:  (+0 -2)

Index: llvm/lib/Bytecode/Reader/Reader.cpp
diff -u llvm/lib/Bytecode/Reader/Reader.cpp:1.147 llvm/lib/Bytecode/Reader/Reader.cpp:1.148
--- llvm/lib/Bytecode/Reader/Reader.cpp:1.147	Wed Dec  8 22:51:50 2004
+++ llvm/lib/Bytecode/Reader/Reader.cpp	Wed Dec  8 22:53:17 2004
@@ -30,8 +30,6 @@
 #include 
 using namespace llvm;
 
-#include "llvm/Support/Timer.h"
-
 namespace {
 
 /// @brief A class for maintaining the slot number definition





From foo at cs.uiuc.edu  Wed Dec  8 23:46:59 2004
From: foo at cs.uiuc.edu (foo at cs.uiuc.edu)
Date: Wed, 8 Dec 2004 23:46:59 -0600
Subject: [llvm-commits] CVS: llvm/utils/vim/README 
Message-ID: <200412090546.XAA05878@zion.cs.uiuc.edu>



Changes in directory llvm/utils/vim:

README updated: 1.4 -> 1.5
---
Log message:

Test commit


---
Diffs of the changes:  (+1 -0)

Index: llvm/utils/vim/README
diff -u llvm/utils/vim/README:1.4 llvm/utils/vim/README:1.5
--- llvm/utils/vim/README:1.4	Wed May 19 16:20:40 2004
+++ llvm/utils/vim/README	Wed Dec  8 23:46:48 2004
@@ -41,3 +41,4 @@
   augroup filetype
     au! BufRead,BufNewFile *Makefile*     set filetype=make
   augroup END
+





From jeffc at jolt-lang.org  Wed Dec  8 23:51:22 2004
From: jeffc at jolt-lang.org (Jeff Cohen)
Date: Wed, 8 Dec 2004 23:51:22 -0600
Subject: [llvm-commits] CVS: llvm/win32/Transforms/Transforms.vcproj 
Message-ID: <200412090551.XAA05959@zion.cs.uiuc.edu>



Changes in directory llvm/win32/Transforms:

Transforms.vcproj updated: 1.4 -> 1.5
---
Log message:

Fix residual Visual Studio build problems

---
Diffs of the changes:  (+0 -3)

Index: llvm/win32/Transforms/Transforms.vcproj
diff -u llvm/win32/Transforms/Transforms.vcproj:1.4 llvm/win32/Transforms/Transforms.vcproj:1.5
--- llvm/win32/Transforms/Transforms.vcproj:1.4	Sat Dec  4 13:14:38 2004
+++ llvm/win32/Transforms/Transforms.vcproj	Wed Dec  8 23:51:11 2004
@@ -311,9 +311,6 @@
 					RelativePath="..\..\lib\Transforms\Scalar\SimplifyCFG.cpp">
 				
 				
-				
-				
 				
 				



Changes in directory llvm/lib/System/Win32:

DynamicLibrary.cpp updated: 1.3 -> 1.4
---
Log message:

Fix residual Visual Studio build problems

---
Diffs of the changes:  (+7 -11)

Index: llvm/lib/System/Win32/DynamicLibrary.cpp
diff -u llvm/lib/System/Win32/DynamicLibrary.cpp:1.3 llvm/lib/System/Win32/DynamicLibrary.cpp:1.4
--- llvm/lib/System/Win32/DynamicLibrary.cpp:1.3	Mon Nov 29 04:39:46 2004
+++ llvm/lib/System/Win32/DynamicLibrary.cpp	Wed Dec  8 23:51:11 2004
@@ -12,7 +12,6 @@
 //===----------------------------------------------------------------------===//
 
 #include "Win32.h"
-#include 
 
 namespace llvm {
 using namespace sys;
@@ -23,33 +22,30 @@
 //===----------------------------------------------------------------------===//
 
 DynamicLibrary::DynamicLibrary() : handle(0) {
-  handle = new HMODULE;
-  *((HMODULE*)handle) = GetModuleHandle(NULL);
+  handle = (void*) GetModuleHandle(NULL);
   
-  if (*((HMODULE*)handle) == 0) {
+  if (handle == 0) {
     ThrowError("Can't GetModuleHandle: ");
   }
 }
 
 DynamicLibrary::DynamicLibrary(const char*filename) : handle(0) {
-  handle = new HMODULE;
-  *((HMODULE*)handle) = LoadLibrary(filename);
+  handle = LoadLibrary(filename);
 
-  if (*((HMODULE*)handle) == 0) {
+  if (handle == 0) {
     ThrowError("Can't LoadLibrary: ");
   }
 }
 
 DynamicLibrary::~DynamicLibrary() {
   assert(handle !=0 && "Invalid DynamicLibrary handle");
-  if (*((HMODULE*)handle))
-    FreeLibrary(*((HMODULE*)handle));
-  delete (HMODULE*)handle;
+  if (handle)
+    FreeLibrary((HMODULE*)handle);
 }
 
 void *DynamicLibrary::GetAddressOfSymbol(const char *symbolName) {
   assert(handle !=0 && "Invalid DynamicLibrary handle");
-  return (void*) GetProcAddress(*((HMODULE*)handle), symbolName);
+  return (void*) GetProcAddress((HMODULE*)handle, symbolName);
 }
 
 }





From jeffc at jolt-lang.org  Wed Dec  8 23:51:22 2004
From: jeffc at jolt-lang.org (Jeff Cohen)
Date: Wed, 8 Dec 2004 23:51:22 -0600
Subject: [llvm-commits] CVS: llvm/include/llvm/Support/DataTypes.h.in 
Message-ID: <200412090551.XAA05962@zion.cs.uiuc.edu>



Changes in directory llvm/include/llvm/Support:

DataTypes.h.in updated: 1.16 -> 1.17
---
Log message:

Fix residual Visual Studio build problems

---
Diffs of the changes:  (+1 -0)

Index: llvm/include/llvm/Support/DataTypes.h.in
diff -u llvm/include/llvm/Support/DataTypes.h.in:1.16 llvm/include/llvm/Support/DataTypes.h.in:1.17
--- llvm/include/llvm/Support/DataTypes.h.in:1.16	Wed Nov  3 11:15:45 2004
+++ llvm/include/llvm/Support/DataTypes.h.in	Wed Dec  8 23:51:11 2004
@@ -66,6 +66,7 @@
 #else /* _MSC_VER */
 // Visual C++ doesn't provide standard integer headers, but it does provide
 // built-in data types.
+#include 
 typedef __int64 int64_t;
 typedef unsigned __int64 uint64_t;
 typedef signed   int int32_t;





From alkis at cs.uiuc.edu  Thu Dec  9 00:14:35 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Thu, 9 Dec 2004 00:14:35 -0600
Subject: [llvm-commits] 
	CVS: llvm-java/test/Programs/SingleSource/UnitTests/Abstract.java
	Makefile 
Message-ID: <200412090614.AAA06326@zion.cs.uiuc.edu>



Changes in directory llvm-java/test/Programs/SingleSource/UnitTests:

Abstract.java added (r1.1)
Makefile updated: 1.19 -> 1.20
---
Log message:

Add test case that causes us to fail in the JIT.


---
Diffs of the changes:  (+18 -1)

Index: llvm-java/test/Programs/SingleSource/UnitTests/Abstract.java
diff -c /dev/null llvm-java/test/Programs/SingleSource/UnitTests/Abstract.java:1.1
*** /dev/null	Thu Dec  9 00:14:35 2004
--- llvm-java/test/Programs/SingleSource/UnitTests/Abstract.java	Thu Dec  9 00:14:25 2004
***************
*** 0 ****
--- 1,16 ----
+ abstract class AbstractAbstract {
+     abstract int abstractMethod();
+ 
+     int concreteMethod() { return abstractMethod(); }
+ }
+ 
+ class AbstractConcrete extends AbstractAbstract {
+     int abstractMethod() { return 5; }
+ }
+ 
+ public class Abstract
+ {
+     public static void main(String[] args) {
+         Test.print_int_ln(new AbstractConcrete().concreteMethod());
+     }
+ }


Index: llvm-java/test/Programs/SingleSource/UnitTests/Makefile
diff -u llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.19 llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.20
--- llvm-java/test/Programs/SingleSource/UnitTests/Makefile:1.19	Wed Dec  8 00:55:56 2004
+++ llvm-java/test/Programs/SingleSource/UnitTests/Makefile	Thu Dec  9 00:14:25 2004
@@ -8,7 +8,8 @@
 ##===----------------------------------------------------------------------===##
 LEVEL := ../../../..
 
-JAVA_TESTS := Arithm \
+JAVA_TESTS := Abstract \
+	Arithm \
 	Array \
 	BigConstants \
 	FieldAccess \





From alkis at cs.uiuc.edu  Thu Dec  9 00:14:58 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Thu, 9 Dec 2004 00:14:58 -0600
Subject: [llvm-commits] CVS: llvm-java/lib/Compiler/Compiler.cpp 
Message-ID: <200412090614.AAA06359@zion.cs.uiuc.edu>



Changes in directory llvm-java/lib/Compiler:

Compiler.cpp updated: 1.172 -> 1.173
---
Log message:

Fix Abstract testcase.


---
Diffs of the changes:  (+2 -3)

Index: llvm-java/lib/Compiler/Compiler.cpp
diff -u llvm-java/lib/Compiler/Compiler.cpp:1.172 llvm-java/lib/Compiler/Compiler.cpp:1.173
--- llvm-java/lib/Compiler/Compiler.cpp:1.172	Tue Dec  7 21:45:19 2004
+++ llvm-java/lib/Compiler/Compiler.cpp	Thu Dec  9 00:14:47 2004
@@ -791,10 +791,9 @@
             getType(method->getDescriptor(), ClassInfo::ObjectBaseTy));
           llvm::Constant* vfun =
             llvm::Constant::getNullValue(PointerType::get(funcTy));
-          if (!cf->isInterface()) {
+          if (!cf->isInterface() && !method->isAbstract()) {
             vfun = module_.getOrInsertFunction(funcName, funcTy);
-            if (!method->isAbstract())
-              scheduleFunction(cast(vfun));
+            scheduleFunction(cast(vfun));
           }
 
           unsigned& index = vi.m2iMap[methodDescr];





From lattner at cs.uiuc.edu  Thu Dec  9 00:19:59 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu, 9 Dec 2004 00:19:59 -0600
Subject: [llvm-commits] CVS: llvm/lib/Bytecode/Reader/Reader.cpp Reader.h 
Message-ID: <200412090619.iB96JxMB018167@apoc.cs.uiuc.edu>



Changes in directory llvm/lib/Bytecode/Reader:

Reader.cpp updated: 1.148 -> 1.149
Reader.h updated: 1.19 -> 1.20
---
Log message:

Remove a dead field, make the map go to integer type ID to hash better and
avoid a getType.


---
Diffs of the changes:  (+12 -17)

Index: llvm/lib/Bytecode/Reader/Reader.cpp
diff -u llvm/lib/Bytecode/Reader/Reader.cpp:1.148 llvm/lib/Bytecode/Reader/Reader.cpp:1.149
--- llvm/lib/Bytecode/Reader/Reader.cpp:1.148	Wed Dec  8 22:53:17 2004
+++ llvm/lib/Bytecode/Reader/Reader.cpp	Thu Dec  9 00:19:44 2004
@@ -35,14 +35,11 @@
 /// @brief A class for maintaining the slot number definition
 /// as a placeholder for the actual definition for forward constants defs.
 class ConstantPlaceHolder : public ConstantExpr {
-  unsigned ID;
   ConstantPlaceHolder();                       // DO NOT IMPLEMENT
   void operator=(const ConstantPlaceHolder &); // DO NOT IMPLEMENT
 public:
-  ConstantPlaceHolder(const Type *Ty, unsigned id) 
-    : ConstantExpr(Instruction::UserOp1, Constant::getNullValue(Ty), Ty),
-    ID(id) {}
-  unsigned getID() { return ID; }
+  ConstantPlaceHolder(const Type *Ty) 
+    : ConstantExpr(Instruction::UserOp1, Constant::getNullValue(Ty), Ty) {}
 };
 
 }
@@ -494,8 +491,7 @@
       error("Value for slot " + utostr(Slot) + 
             " is expected to be a constant!");
 
-  const Type *Ty = getType(TypeSlot);
-  std::pair Key(Ty, Slot);
+  std::pair Key(TypeSlot, Slot);
   ConstantRefsType::iterator I = ConstantFwdRefs.lower_bound(Key);
 
   if (I != ConstantFwdRefs.end() && I->first == Key) {
@@ -503,7 +499,7 @@
   } else {
     // Create a placeholder for the constant reference and
     // keep track of the fact that we have a forward ref to recycle it
-    Constant *C = new ConstantPlaceHolder(Ty, Slot);
+    Constant *C = new ConstantPlaceHolder(getType(TypeSlot));
     
     // Keep track of the fact that we have a forward ref to recycle it
     ConstantFwdRefs.insert(I, std::make_pair(Key, C));
@@ -1477,9 +1473,10 @@
 /// referenced constants in the ConstantFwdRefs map. It uses the 
 /// replaceAllUsesWith method of Value class to substitute the placeholder
 /// instance with the actual instance.
-void BytecodeReader::ResolveReferencesToConstant(Constant *NewV, unsigned Slot){
+void BytecodeReader::ResolveReferencesToConstant(Constant *NewV, unsigned Typ,
+                                                 unsigned Slot) {
   ConstantRefsType::iterator I =
-    ConstantFwdRefs.find(std::make_pair(NewV->getType(), Slot));
+    ConstantFwdRefs.find(std::make_pair(Typ, Slot));
   if (I == ConstantFwdRefs.end()) return;   // Never forward referenced?
 
   Value *PH = I->second;   // Get the placeholder...
@@ -1518,7 +1515,7 @@
     // Create the constant, inserting it as needed.
     Constant *C = ConstantArray::get(ATy, Elements);
     unsigned Slot = insertValue(C, Typ, Tab);
-    ResolveReferencesToConstant(C, Slot);
+    ResolveReferencesToConstant(C, Typ, Slot);
     if (Handler) Handler->handleConstantString(cast(C));
   }
 }
@@ -1564,7 +1561,7 @@
         if (&Tab != &ModuleValues && Typ < ModuleValues.size() &&
             ModuleValues[Typ])
           Slot += ModuleValues[Typ]->size();
-        ResolveReferencesToConstant(C, Slot);
+        ResolveReferencesToConstant(C, Typ, Slot);
       }
     }
   }
@@ -1572,14 +1569,12 @@
   // After we have finished parsing the constant pool, we had better not have
   // any dangling references left.
   if (!ConstantFwdRefs.empty()) {
-  typedef std::map, Constant*> ConstantRefsType;
     ConstantRefsType::const_iterator I = ConstantFwdRefs.begin();
-    const Type* missingType = I->first.first;
     Constant* missingConst = I->second;
     error(utostr(ConstantFwdRefs.size()) + 
           " unresolved constant reference exist. First one is '" + 
           missingConst->getName() + "' of type '" + 
-          missingType->getDescription() + "'.");
+          missingConst->getType()->getDescription() + "'.");
   }
 
   checkPastBlockEnd("Constant Pool");


Index: llvm/lib/Bytecode/Reader/Reader.h
diff -u llvm/lib/Bytecode/Reader/Reader.h:1.19 llvm/lib/Bytecode/Reader/Reader.h:1.20
--- llvm/lib/Bytecode/Reader/Reader.h:1.19	Mon Nov 15 15:55:06 2004
+++ llvm/lib/Bytecode/Reader/Reader.h	Thu Dec  9 00:19:44 2004
@@ -102,7 +102,7 @@
   /// This map is needed so that forward references to constants can be looked 
   /// up by Type and slot number when resolving those references.
   /// @brief A mapping of a Type/slot pair to a Constant*.
-  typedef std::map, Constant*> ConstantRefsType;
+  typedef std::map, Constant*> ConstantRefsType;
 
   /// For lazy read-in of functions, we need to save the location in the
   /// data stream where the function is located. This structure provides that
@@ -453,7 +453,7 @@
 
   /// @brief Resolve all references to the placeholder (if any) for the 
   /// given constant.
-  void ResolveReferencesToConstant(Constant *C, unsigned Slot);
+  void ResolveReferencesToConstant(Constant *C, unsigned Typ, unsigned Slot);
 
   /// @brief Release our memory.
   void freeState() {





From gaeke at cs.uiuc.edu  Thu Dec  9 00:37:30 2004
From: gaeke at cs.uiuc.edu (Brian Gaeke)
Date: Thu, 9 Dec 2004 00:37:30 -0600
Subject: [llvm-commits] CVS: reopt/configure 
Message-ID: <200412090637.AAA07771@zion.cs.uiuc.edu>



Changes in directory reopt:

configure updated: 1.10 -> 1.11
---
Log message:

Make reopt/configure forget about bininterface


---
Diffs of the changes:  (+0 -6)

Index: reopt/configure
diff -u reopt/configure:1.10 reopt/configure:1.11
--- reopt/configure:1.10	Tue Oct 26 12:13:03 2004
+++ reopt/configure	Thu Dec  9 00:37:20 2004
@@ -1237,9 +1237,6 @@
           ac_config_commands="$ac_config_commands lib/Makefile"
 
 
-          ac_config_commands="$ac_config_commands lib/BinInterface/Makefile"
-
-
           ac_config_commands="$ac_config_commands lib/Inst/Makefile"
 
 
@@ -1859,7 +1856,6 @@
 
 ${srcdir}/autoconf/mkinstalldirs `dirname Makefile`
 ${srcdir}/autoconf/mkinstalldirs `dirname lib/Makefile`
-${srcdir}/autoconf/mkinstalldirs `dirname lib/BinInterface/Makefile`
 ${srcdir}/autoconf/mkinstalldirs `dirname lib/Inst/Makefile`
 ${srcdir}/autoconf/mkinstalldirs `dirname lib/Inst/lib/Makefile`
 ${srcdir}/autoconf/mkinstalldirs `dirname lib/Inst/lib/Phase1/Makefile`
@@ -1886,7 +1882,6 @@
   "Makefile.config" ) CONFIG_FILES="$CONFIG_FILES Makefile.config" ;;
   "Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS Makefile" ;;
   "lib/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS lib/Makefile" ;;
-  "lib/BinInterface/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS lib/BinInterface/Makefile" ;;
   "lib/Inst/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS lib/Inst/Makefile" ;;
   "lib/Inst/lib/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS lib/Inst/lib/Makefile" ;;
   "lib/Inst/lib/Phase1/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS lib/Inst/lib/Phase1/Makefile" ;;
@@ -2246,7 +2241,6 @@
   case $ac_dest in
     Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/Makefile Makefile ;;
     lib/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/lib/Makefile lib/Makefile ;;
-    lib/BinInterface/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/lib/BinInterface/Makefile lib/BinInterface/Makefile ;;
     lib/Inst/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/lib/Inst/Makefile lib/Inst/Makefile ;;
     lib/Inst/lib/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/lib/Inst/lib/Makefile lib/Inst/lib/Makefile ;;
     lib/Inst/lib/Phase1/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/lib/Inst/lib/Phase1/Makefile lib/Inst/lib/Phase1/Makefile ;;





From gaeke at cs.uiuc.edu  Thu Dec  9 00:37:32 2004
From: gaeke at cs.uiuc.edu (Brian Gaeke)
Date: Thu, 9 Dec 2004 00:37:32 -0600
Subject: [llvm-commits] CVS: reopt/autoconf/configure.ac 
Message-ID: <200412090637.AAA07777@zion.cs.uiuc.edu>



Changes in directory reopt/autoconf:

configure.ac updated: 1.9 -> 1.10
---
Log message:

Make reopt/configure forget about bininterface


---
Diffs of the changes:  (+0 -1)

Index: reopt/autoconf/configure.ac
diff -u reopt/autoconf/configure.ac:1.9 reopt/autoconf/configure.ac:1.10
--- reopt/autoconf/configure.ac:1.9	Tue Oct 26 12:13:02 2004
+++ reopt/autoconf/configure.ac	Thu Dec  9 00:37:22 2004
@@ -9,7 +9,6 @@
 dnl Configure Makefiles
 AC_CONFIG_MAKEFILE(Makefile)
 AC_CONFIG_MAKEFILE(lib/Makefile)
-AC_CONFIG_MAKEFILE(lib/BinInterface/Makefile)
 AC_CONFIG_MAKEFILE(lib/Inst/Makefile)
 AC_CONFIG_MAKEFILE(lib/Inst/lib/Makefile)
 AC_CONFIG_MAKEFILE(lib/Inst/lib/Phase1/Makefile)





From gaeke at cs.uiuc.edu  Thu Dec  9 00:53:58 2004
From: gaeke at cs.uiuc.edu (Brian Gaeke)
Date: Thu, 9 Dec 2004 00:53:58 -0600 (CST)
Subject: [llvm-commits] CVS: reopt/tools/mkexcl/Makefile 
Message-ID: <200412090653.AAA18008@kain.cs.uiuc.edu>



Changes in directory reopt/tools/mkexcl:

Makefile updated: 1.3 -> 1.4
---
Log message:

Trim USEDLIBS for mkexcl.


---
Diffs of the changes:  (+1 -1)

Index: reopt/tools/mkexcl/Makefile
diff -u reopt/tools/mkexcl/Makefile:1.3 reopt/tools/mkexcl/Makefile:1.4
--- reopt/tools/mkexcl/Makefile:1.3	Thu Aug 21 16:08:08 2003
+++ reopt/tools/mkexcl/Makefile	Thu Dec  9 00:53:46 2004
@@ -1,6 +1,6 @@
 LEVEL = ../..
 TOOLNAME = mkexcl
-USEDLIBS = perfinst.a tracecache.a bininterface.a
+USEDLIBS = perfinst.a
 TOOLLINKOPTS = -lelf
 
 include $(LEVEL)/Makefile.common





From lattner at cs.uiuc.edu  Thu Dec  9 01:14:51 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu, 9 Dec 2004 01:14:51 -0600
Subject: [llvm-commits] 
	CVS: llvm/lib/Transforms/Scalar/InstructionCombining.cpp
Message-ID: <200412090714.iB97Eom7021728@apoc.cs.uiuc.edu>



Changes in directory llvm/lib/Transforms/Scalar:

InstructionCombining.cpp updated: 1.291 -> 1.292
---
Log message:

Implement trivial sinking for load instructions.  This causes us to sink 567 loads in spec


---
Diffs of the changes:  (+11 -1)

Index: llvm/lib/Transforms/Scalar/InstructionCombining.cpp
diff -u llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.291 llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.292
--- llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.291	Wed Dec  8 17:43:58 2004
+++ llvm/lib/Transforms/Scalar/InstructionCombining.cpp	Thu Dec  9 01:14:34 2004
@@ -4206,7 +4206,17 @@
   if (isa(I) && I->getParent() == &DestBlock->getParent()->front())
     return false;
 
-  if (isa(I)) return false;
+  // We can only sink load instructions if there is nothing between the load and
+  // the end of block that could change the value.
+  if (LoadInst *LI = dyn_cast(I)) {
+    if (LI->isVolatile()) return false;  // Don't sink volatile loads.
+
+    for (BasicBlock::iterator Scan = LI, E = LI->getParent()->end();
+         Scan != E; ++Scan)
+      if (Scan->mayWriteToMemory())
+        return false;
+    std::cerr << "SUNK LOAD: " << *LI;
+  }
 
   BasicBlock::iterator InsertPos = DestBlock->begin();
   while (isa(InsertPos)) ++InsertPos;





From lattner at cs.uiuc.edu  Thu Dec  9 01:16:05 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu, 9 Dec 2004 01:16:05 -0600
Subject: [llvm-commits] 
	CVS: llvm/lib/Transforms/Scalar/InstructionCombining.cpp
Message-ID: <200412090716.iB97G5Ib021744@apoc.cs.uiuc.edu>



Changes in directory llvm/lib/Transforms/Scalar:

InstructionCombining.cpp updated: 1.292 -> 1.293
---
Log message:

note to self: Do not check in debugging code!


---
Diffs of the changes:  (+0 -1)

Index: llvm/lib/Transforms/Scalar/InstructionCombining.cpp
diff -u llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.292 llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.293
--- llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.292	Thu Dec  9 01:14:34 2004
+++ llvm/lib/Transforms/Scalar/InstructionCombining.cpp	Thu Dec  9 01:15:52 2004
@@ -4215,7 +4215,6 @@
          Scan != E; ++Scan)
       if (Scan->mayWriteToMemory())
         return false;
-    std::cerr << "SUNK LOAD: " << *LI;
   }
 
   BasicBlock::iterator InsertPos = DestBlock->begin();





From reid at x10sys.com  Thu Dec  9 01:43:16 2004
From: reid at x10sys.com (Reid Spencer)
Date: Thu, 9 Dec 2004 01:43:16 -0600
Subject: [llvm-commits] CVS: llvm/configure 
Message-ID: <200412090743.BAA17036@zion.cs.uiuc.edu>



Changes in directory llvm:

configure updated: 1.148 -> 1.149
---
Log message:

More QMTest cruft gone!


---
Diffs of the changes:  (+0 -12)

Index: llvm/configure
diff -u llvm/configure:1.148 llvm/configure:1.149
--- llvm/configure:1.148	Wed Dec  8 17:07:27 2004
+++ llvm/configure	Thu Dec  9 01:43:05 2004
@@ -29480,12 +29480,6 @@
           ac_config_commands="$ac_config_commands test/Makefile.tests"
 
 
-          ac_config_commands="$ac_config_commands test/QMTest/llvm.py"
-
-
-          ac_config_commands="$ac_config_commands test/QMTest/llvmdb.py"
-
-
           ac_config_commands="$ac_config_commands tools/Makefile"
 
 
@@ -30044,8 +30038,6 @@
 ${srcdir}/autoconf/mkinstalldirs `dirname runtime/Makefile`
 ${srcdir}/autoconf/mkinstalldirs `dirname test/Makefile`
 ${srcdir}/autoconf/mkinstalldirs `dirname test/Makefile.tests`
-${srcdir}/autoconf/mkinstalldirs `dirname test/QMTest/llvm.py`
-${srcdir}/autoconf/mkinstalldirs `dirname test/QMTest/llvmdb.py`
 ${srcdir}/autoconf/mkinstalldirs `dirname tools/Makefile`
 ${srcdir}/autoconf/mkinstalldirs `dirname utils/Makefile`
 ${srcdir}/autoconf/mkinstalldirs `dirname projects/Makefile`
@@ -30073,8 +30065,6 @@
   "runtime/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS runtime/Makefile" ;;
   "test/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/Makefile" ;;
   "test/Makefile.tests" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/Makefile.tests" ;;
-  "test/QMTest/llvm.py" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/QMTest/llvm.py" ;;
-  "test/QMTest/llvmdb.py" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/QMTest/llvmdb.py" ;;
   "tools/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS tools/Makefile" ;;
   "utils/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS utils/Makefile" ;;
   "projects/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS projects/Makefile" ;;
@@ -30990,8 +30980,6 @@
     runtime/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/runtime/Makefile runtime/Makefile ;;
     test/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/Makefile test/Makefile ;;
     test/Makefile.tests ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/Makefile.tests test/Makefile.tests ;;
-    test/QMTest/llvm.py ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/QMTest/llvm.py test/QMTest/llvm.py ;;
-    test/QMTest/llvmdb.py ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/QMTest/llvmdb.py test/QMTest/llvmdb.py ;;
     tools/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/tools/Makefile tools/Makefile ;;
     utils/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/utils/Makefile utils/Makefile ;;
     projects/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/projects/Makefile projects/Makefile ;;





From reid at x10sys.com  Thu Dec  9 01:43:17 2004
From: reid at x10sys.com (Reid Spencer)
Date: Thu, 9 Dec 2004 01:43:17 -0600
Subject: [llvm-commits] CVS: llvm/autoconf/configure.ac 
Message-ID: <200412090743.BAA17039@zion.cs.uiuc.edu>



Changes in directory llvm/autoconf:

configure.ac updated: 1.139 -> 1.140
---
Log message:

More QMTest cruft gone!


---
Diffs of the changes:  (+0 -2)

Index: llvm/autoconf/configure.ac
diff -u llvm/autoconf/configure.ac:1.139 llvm/autoconf/configure.ac:1.140
--- llvm/autoconf/configure.ac:1.139	Wed Dec  8 17:07:27 2004
+++ llvm/autoconf/configure.ac	Thu Dec  9 01:43:06 2004
@@ -559,8 +559,6 @@
 AC_CONFIG_MAKEFILE(runtime/Makefile)
 AC_CONFIG_MAKEFILE(test/Makefile)
 AC_CONFIG_MAKEFILE(test/Makefile.tests)
-AC_CONFIG_MAKEFILE(test/QMTest/llvm.py)
-AC_CONFIG_MAKEFILE(test/QMTest/llvmdb.py)
 AC_CONFIG_MAKEFILE(tools/Makefile)
 AC_CONFIG_MAKEFILE(utils/Makefile)
 AC_CONFIG_MAKEFILE(projects/Makefile)





From gaeke at cs.uiuc.edu  Thu Dec  9 01:47:03 2004
From: gaeke at cs.uiuc.edu (Brian Gaeke)
Date: Thu, 9 Dec 2004 01:47:03 -0600
Subject: [llvm-commits] CVS: llvm-www/demo/index.cgi 
Message-ID: <200412090747.BAA17094@zion.cs.uiuc.edu>



Changes in directory llvm-www/demo:

index.cgi updated: 1.31 -> 1.32
---
Log message:

Change to new path for llvm tools.
Fix typo (DisableLoad->DisableForm).


---
Diffs of the changes:  (+3 -3)

Index: llvm-www/demo/index.cgi
diff -u llvm-www/demo/index.cgi:1.31 llvm-www/demo/index.cgi:1.32
--- llvm-www/demo/index.cgi:1.31	Sat Oct 16 13:29:18 2004
+++ llvm-www/demo/index.cgi	Thu Dec  9 01:46:53 2004
@@ -5,7 +5,7 @@
 # doing remote web JO99C compilations.  (It could still be used for that
 # purpose, though the two scripts have diverged somewhat.)
 #
-# Last modified $Date: 2004/10/16 18:29:18 $
+# Last modified $Date: 2004/12/09 07:46:53 $
 #
 
 use CGI;
@@ -24,7 +24,7 @@
 $CONTACT_ADDRESS = 'gaeke -at- uiuc.edu';
 $LOGO_IMAGE_URL  = 'cathead.png';
 @PREPENDPATHDIRS =
-  ( '/home/vadve/gaeke/llvm/tools/Debug', '/home/vadve/gaeke/bin' );
+  ( '/home/vadve/gaeke/llvm/Release/bin', '/home/vadve/gaeke/bin' );
 $ENV{'LLVM_LIB_SEARCH_PATH'} =
   '/home/vadve/lattner/local/x86/llvm-gcc/bytecode-libs';
 $ENV{'LD_LIBRARY_PATH'} = '/home/vadve/shared/localtools/fc1/lib/';
@@ -211,7 +211,7 @@
     my $sanitycheckfail = '';
 
     barf("The demo page is currently down due to high load, please try again later!")
-      if ($DisableLoad);
+      if ($DisableForm);
 
     # insert tool-specific sanity checks here
     $sanitycheckfail .= ' gccas' if `gccas --help 2>&1` !~ /assembler for GCC/;





From criswell at cs.uiuc.edu  Thu Dec  9 10:03:10 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 10:03:10 -0600
Subject: [llvm-commits] CVS: llvm-www/releases/1.4/
Message-ID: <200412091603.KAA03378@choi.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.4:

---
Log message:

Directory /home/vadve/shared/InternalCVS/llvm-www/releases/1.4 added to the repository


---
Diffs of the changes:  (+0 -0)




From criswell at cs.uiuc.edu  Thu Dec  9 10:05:29 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 10:05:29 -0600
Subject: [llvm-commits] CVS: llvm-www/releases/1.4/announcement.txt
	index.html LICENSE.TXT 
Message-ID: <200412091605.KAA03465@choi.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.4:

announcement.txt added (r1.1)
index.html added (r1.1)
LICENSE.TXT added (r1.1)
---
Log message:

Initial commit of LLVM 1.4 release.


---
Diffs of the changes:  (+162 -0)

Index: llvm-www/releases/1.4/announcement.txt
diff -c /dev/null llvm-www/releases/1.4/announcement.txt:1.1
*** /dev/null	Thu Dec  9 10:05:28 2004
--- llvm-www/releases/1.4/announcement.txt	Thu Dec  9 10:05:18 2004
***************
*** 0 ****
--- 1,83 ----
+               LLVM Compiler Infrastructure -- Release 1.4
+                         http://llvm.cs.uiuc.edu
+ 
+ We are pleased to announce the release of version 1.4 of the LLVM Compiler
+ Infrastructure.  If you are new to LLVM, please see "WHAT IS LLVM?" below.
+ If you are already familiar with LLVM, skip to "WHAT IS NEW IN LLVM 1.4?"
+ 
+ 
+ WHAT IS LLVM?
+ 
+   LLVM is a set of libraries and tools that make it easy to build compilers,
+   optimizers, Just-In-Time code generators, and many other compiler-related
+   programs.  As examples, LLVM includes C, C++, and Stacker compilers that use
+   the components to build aggressively optimizing compilers.  LLVM can compile
+   code to X86, SparcV9, PowerPC (beta support), or C code.  Alternatively, LLVM
+   can JIT compiler code for X86 and SparcV9.
+ 
+   The strengths of LLVM are its extremely simple design (which makes it easy to
+   understand and use), source-language independence, powerful mid-level
+   optimizer, extensibility, and its stability and reliability.
+ 
+   The LLVM infrastructure is publicly available under a non-restrictive open
+   source license.  More information about LLVM and the contents of the
+   publicly released software is available at the LLVM Web site above.
+ 
+ 
+ WHAT IS NEW IN LLVM 1.4?
+ 
+   This release takes less time to produce faster compiled code and is portable
+   to new targets (including Cygwin).  It also includes several new features,
+   such as man pages for all LLVM tools, accurate garbage collection, some new
+   loop transformations, and includes beta support for powerpc code generation.
+   LLVM 1.4 also includes the following major improvements:
+ 
+   Core improvements:
+     * A new "select" instruction provides efficient conditional move support.
+     * Accurate garbage collection is fully supported by all code generators.
+     * LLVM now supports structures with more than 256 elements in them.
+     * The bytecode file format is now documented.
+     * Man pages are available for all LLVM tools.
+     * LLVM now supports unordered floating point comparisons.
+ 
+   Optimization improvements:
+     * The induction variable analysis routines are much more aggressive.
+     * The -indvars pass implements linear function test replacement and exit
+       value substitution.
+     * LLVM now includes a context-senstitive alias analysis for global
+       variables.
+     * LLVM includes an implementation of Andersen's alias analysis.
+     * LLVM includes new loop unrolling and loop unswitching passes.
+     * LLVM includes a simple dead store elimination pass.
+ 
+   Code generator improvements:
+     * The native code generators now default to a global register allocator.
+     * LLVM includes a new "skeleton" code generator.
+     * LLC and LLI can load code generators from .so files with the -load option.
+     * More code generator components are autogenerated from the abstract target
+       description.
+     * The X86 backend now generates substantially better code in many cases.
+ 
+   Other improvements:
+     * Bugpoint can now debug arbitrary modes of the LLC and LLI tools.
+     * Bugpoint can now narrow down code generation miscompilations to the basic
+       block being miscompiled (in many cases).
+     * Bugpoint can now debug infinite-loop inducing miscompilations.
+ 
+   Finally, LLVM 1.4 includes the usual collection of bug fixes and other minor
+   improvements.
+ 
+   A full list of new features and bug-fixes are listed in the Release Notes:
+     http://llvm.cs.uiuc.edu/releases/1.4/docs/ReleaseNotes.html#whatsnew
+ 
+   For an easier to read (and more detailed) list of changes, please see the
+   status updates:
+    http://mail.cs.uiuc.edu/pipermail/llvm-announce/2004-May/000008.html
+    http://mail.cs.uiuc.edu/pipermail/llvm-announce/2004-June/000009.html
+    http://mail.cs.uiuc.edu/pipermail/llvm-announce/2004-July/000010.html
+ 
+ 
+ HOW DO I GET IT?
+ 
+   Please see: http://llvm.cs.uiuc.edu/releases
+ 


Index: llvm-www/releases/1.4/index.html
diff -c /dev/null llvm-www/releases/1.4/index.html:1.1
*** /dev/null	Thu Dec  9 10:05:29 2004
--- llvm-www/releases/1.4/index.html	Thu Dec  9 10:05:18 2004
***************
*** 0 ****
--- 1,7 ----
+ 
+ 
+   
+ 
+ 
+ 
+ 


Index: llvm-www/releases/1.4/LICENSE.TXT
diff -c /dev/null llvm-www/releases/1.4/LICENSE.TXT:1.1
*** /dev/null	Thu Dec  9 10:05:29 2004
--- llvm-www/releases/1.4/LICENSE.TXT	Thu Dec  9 10:05:18 2004
***************
*** 0 ****
--- 1,72 ----
+ ==============================================================================
+ LLVM Release License
+ ==============================================================================
+ University of Illinois/NCSA
+ Open Source License
+ 
+ Copyright (c) 2003, 2004 University of Illinois at Urbana-Champaign.
+ All rights reserved.
+ 
+ Developed by:
+ 
+     LLVM Team
+ 
+     University of Illinois at Urbana-Champaign
+ 
+     http://llvm.cs.uiuc.edu
+ 
+ Permission is hereby granted, free of charge, to any person obtaining a copy of
+ this software and associated documentation files (the "Software"), to deal with
+ the Software without restriction, including without limitation the rights to
+ use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
+ of the Software, and to permit persons to whom the Software is furnished to do
+ so, subject to the following conditions:
+ 
+     * Redistributions of source code must retain the above copyright notice,
+       this list of conditions and the following disclaimers.
+ 
+     * Redistributions in binary form must reproduce the above copyright notice,
+       this list of conditions and the following disclaimers in the
+       documentation and/or other materials provided with the distribution.
+ 
+     * Neither the names of the LLVM Team, University of Illinois at
+       Urbana-Champaign, nor the names of its contributors may be used to
+       endorse or promote products derived from this Software without specific
+       prior written permission.
+ 
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
+ FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
+ CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE
+ SOFTWARE.
+ 
+ ==============================================================================
+ Copyrights and Licenses for Third Party Software Distributed with LLVM:
+ ==============================================================================
+ The LLVM software contains code written by third parties.  Such software will
+ have its own individual LICENSE.TXT file in the directory in which it appears.
+ This file will describe the copyrights, license, and restrictions which apply
+ to that code.
+ 
+ The disclaimer of warranty in the University of Illinois Open Source License
+ applies to all code in the LLVM Distribution, and nothing in any of the
+ other licenses gives permission to use the names of the LLVM Team or the
+ University of Illinois to endorse or promote products derived from this
+ Software.
+ 
+ The following pieces of software have additional or alternate copyrights,
+ licenses, and/or restrictions:
+ 
+ Program             Directory
+ -------             ---------
+ System Library      llvm/lib/System
+ Compiler Driver     llvm/tools/llvmc
+ PowerPC Backend     llvm/lib/Target/PowerPC
+ bzip2:              llvm/lib/Support/bzip2/LICENSE 
+ Autoconf:           llvm/autoconf
+                     llvm/projects/ModuleMaker/autoconf
+                     llvm/projects/sample/autoconf
+ Burg:               llvm/utils/Burg
+ GNU Libc:           llvm/runtime/GCCLibraries/libc





From lattner at cs.uiuc.edu  Thu Dec  9 10:11:54 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu, 9 Dec 2004 10:11:54 -0600
Subject: [llvm-commits] CVS: llvm/docs/LangRef.html 
Message-ID: <200412091611.iB9GBsea022795@apoc.cs.uiuc.edu>



Changes in directory llvm/docs:

LangRef.html updated: 1.77 -> 1.78
---
Log message:

Move the "High Level Structure" to before "Type System"


---
Diffs of the changes:  (+174 -156)

Index: llvm/docs/LangRef.html
diff -u llvm/docs/LangRef.html:1.77 llvm/docs/LangRef.html:1.78
--- llvm/docs/LangRef.html:1.77	Mon Nov  1 02:19:36 2004
+++ llvm/docs/LangRef.html	Thu Dec  9 10:11:40 2004
@@ -17,6 +17,13 @@
   
  • Abstract
    • 
   
  • Introduction
    • 
   
  • Identifiers
    • 
+  
  • High Level Structure
+    
      
+      
    1. Module Structure
      2. 
+      
    2. Global Variables
      3. 
+      
    3. Function Structure
      4. 
+    
    
+  
    • 
   
  • Type System
     
      
       
    1. Primitive Types 	
@@ -35,12 +42,7 @@
       
      2. 
     
    
   
    • 
-  
  • High Level Structure
-    
      
-      
    1. Module Structure
      2. 
-      
    2. Global Variables
      3. 
-      
    3. Function Structure
      4. 
-    
    
+  
  • Constants
   
    • 
   
  • Instruction Reference
     
      
@@ -279,10 +281,172 @@
 represented in their IEEE hexadecimal format so that assembly and
 disassembly do not cause any bits to change in the constants.
      
 
    • 
+
+
+
     High Level Structure 
    
+
+
+
+
     Module Structure
+
    
+
+
    
+
+
    LLVM programs are composed of "Module"s, each of which is a
+translation unit of the input programs.  Each module consists of
+functions, global variables, and symbol table entries.  Modules may be
+combined together with the LLVM linker, which merges function (and
+global variable) definitions, resolves forward declarations, and merges
+symbol table entries. Here is an example of the "hello world" module:
    
+
+
    ; Declare the string constant as a global constant...
+%.LC0 = internal constant [13 x sbyte] c"hello world\0A\00"          ; [13 x sbyte]*
+
+; External declaration of the puts function
+declare int %puts(sbyte*)                                            ; int(sbyte*)* 
+
+; Definition of main function
+int %main() {                                                        ; int()* 
+        ; Convert [13x sbyte]* to sbyte *...
+        %cast210 = getelementptr [13 x sbyte]* %.LC0, long 0, long 0 ; sbyte*
+
+        ; Call puts function to write out the string to stdout...
+        call int %puts(sbyte* %cast210)                              ; int
+        ret int 0
    }
    
+
+
    This example is made up of a global variable
+named ".LC0", an external declaration of the "puts"
+function, and a function definition
+for "main".
    
+
+ In general, a module is made up of a list of global
+values, where both functions and global variables are global values. 
+Global values are represented by a pointer to a memory location (in
+this case, a pointer to an array of char, and a pointer to a function),
+and have one of the following linkage types:
+
+
     
    
+
+
    
+  
    internal 
    
+  
    Global values with internal linkage are only directly accessible
+by objects in the current module.  In particular, linking code into a
+module with an internal global value may cause the internal to be
+renamed as necessary to avoid collisions.  Because the symbol is
+internal to the module, all references can be updated.  This
+corresponds to the notion of the 'static' keyword in C, or the
+idea of "anonymous namespaces" in C++.
+    
     
    
+  
    
+  
    linkonce: 
    
+  
    "linkonce" linkage is similar to internal
+linkage, with the twist that linking together two modules defining the
+same linkonce globals will cause one of the globals to be
+discarded.  This is typically used to implement inline functions. 
+Unreferenced linkonce globals are allowed to be discarded.
+    
     
    
+  
    
+  
    weak: 
    
+  
    "weak" linkage is exactly the same as linkonce
+linkage, except that unreferenced weak globals may not be
+discarded.  This is used to implement constructs in C such as "int
+X;" at global scope.
+    
     
    
+  
    
+  
    appending: 
    
+  
    "appending" linkage may only be applied to global
+variables of pointer to array type.  When two global variables with
+appending linkage are linked together, the two global arrays are
+appended together.  This is the LLVM, typesafe, equivalent of having
+the system linker append together "sections" with identical names when
+.o files are linked.
+    
     
    
+  
    
+  
    externally visible:
    
+  
    If none of the above identifiers are used, the global is
+externally visible, meaning that it participates in linkage and can be
+used to resolve external symbol references.
+    
     
    
+  
    
+
    
+
+
     
    
+
+
    For example, since the ".LC0"
+variable is defined to be internal, if another module defined a ".LC0"
+variable and was linked with this one, one of the two would be renamed,
+preventing a collision.  Since "main" and "puts" are
+external (i.e., lacking any linkage declarations), they are accessible
+outside of the current module.  It is illegal for a function declaration
+to have any linkage type other than "externally visible".
    
+
    
+
+
+
    
+  Global Variables
+
    
+
+
    
+
+
    Global variables define regions of memory allocated at compilation
+time instead of run-time.  Global variables may optionally be
+initialized.  A variable may be defined as a global "constant", which
+indicates that the contents of the variable will never be modified
+(enabling better optimization, allowing the global data to be placed in the
+read-only section of an executable, etc).
    
+
+
    As SSA values, global variables define pointer values that are in
+scope (i.e. they dominate) all basic blocks in the program.  Global
+variables always define a pointer to their "content" type because they
+describe a region of memory, and all memory objects in LLVM are
+accessed through pointers.
    
+
+
    
+
+
+
+
    
+  Functions
+
    
+
+
    
+
+
    LLVM function definitions are composed of a (possibly empty) argument list,
+an opening curly brace, a list of basic blocks, and a closing curly brace.  LLVM
+function declarations are defined with the "declare" keyword, a
+function name, and a function signature.
    
+
+
    A function definition contains a list of basic blocks, forming the CFG for
+the function.  Each basic block may optionally start with a label (giving the
+basic block a symbol table entry), contains a list of instructions, and ends
+with a terminator instruction (such as a branch or
+function return).
    
+
+
    The first basic block in program is special in two ways: it is immediately
+executed on entrance to the function, and it is not allowed to have predecessor
+basic blocks (i.e. there can not be any branches to the entry block of a
+function).  Because the block can have no predecessors, it also cannot have any
+PHI nodes.
    
+
+
    LLVM functions are identified by their name and type signature.  Hence, two
+functions with the same name but different parameter lists or return values are
+considered different functions, and LLVM will resolves references to each
+appropriately.
    
+
+
    
+
+
+
 
 
     Type System 
    
 
+
 
    
+
 
    The LLVM type system is one of the most important features of the
 intermediate representation.  Being typed enables a number of
 optimizations to be performed on the IR directly, without having to do
@@ -290,9 +454,9 @@
 system makes it easier to read the generated code and enables novel
 analyses and transformations that are not feasible to perform on normal
 three address code representations.
    
- 
    
+
+
    
+
 
 
     Primitive Types 
    
 
    
@@ -557,152 +721,6 @@
 
 
    
 
-
-
     High Level Structure 
    
-
-
-
     Module Structure
-
    
-
    
-
    LLVM programs are composed of "Module"s, each of which is a
-translation unit of the input programs.  Each module consists of
-functions, global variables, and symbol table entries.  Modules may be
-combined together with the LLVM linker, which merges function (and
-global variable) definitions, resolves forward declarations, and merges
-symbol table entries. Here is an example of the "hello world" module:
    
-
    ; Declare the string constant as a global constant...
-%.LC0 = internal constant [13 x sbyte] c"hello world\0A\00"          ; [13 x sbyte]*
-
-; External declaration of the puts function
-declare int %puts(sbyte*)                                            ; int(sbyte*)* 
-
-; Definition of main function
-int %main() {                                                        ; int()* 
-        ; Convert [13x sbyte]* to sbyte *...
-        %cast210 = getelementptr [13 x sbyte]* %.LC0, long 0, long 0 ; sbyte*
-
-        ; Call puts function to write out the string to stdout...
-        call int %puts(sbyte* %cast210)                              ; int
-        ret int 0
    }
    
-
    This example is made up of a global variable
-named ".LC0", an external declaration of the "puts"
-function, and a function definition
-for "main".
    
- In general, a module is made up of a list of global
-values, where both functions and global variables are global values. 
-Global values are represented by a pointer to a memory location (in
-this case, a pointer to an array of char, and a pointer to a function),
-and have one of the following linkage types:
-
     
    
-
    
-  
    internal 
    
-  
    Global values with internal linkage are only directly accessible
-by objects in the current module.  In particular, linking code into a
-module with an internal global value may cause the internal to be
-renamed as necessary to avoid collisions.  Because the symbol is
-internal to the module, all references can be updated.  This
-corresponds to the notion of the 'static' keyword in C, or the
-idea of "anonymous namespaces" in C++.
-    
     
    
-  
    
-  
    linkonce: 
    
-  
    "linkonce" linkage is similar to internal
-linkage, with the twist that linking together two modules defining the
-same linkonce globals will cause one of the globals to be
-discarded.  This is typically used to implement inline functions. 
-Unreferenced linkonce globals are allowed to be discarded.
-    
     
    
-  
    
-  
    weak: 
    
-  
    "weak" linkage is exactly the same as linkonce
-linkage, except that unreferenced weak globals may not be
-discarded.  This is used to implement constructs in C such as "int
-X;" at global scope.
-    
     
    
-  
    
-  
    appending: 
    
-  
    "appending" linkage may only be applied to global
-variables of pointer to array type.  When two global variables with
-appending linkage are linked together, the two global arrays are
-appended together.  This is the LLVM, typesafe, equivalent of having
-the system linker append together "sections" with identical names when
-.o files are linked.
-    
     
    
-  
    
-  
    externally visible:
    
-  
    If none of the above identifiers are used, the global is
-externally visible, meaning that it participates in linkage and can be
-used to resolve external symbol references.
-    
     
    
-  
    
-
    
-
     
    
-
    For example, since the ".LC0"
-variable is defined to be internal, if another module defined a ".LC0"
-variable and was linked with this one, one of the two would be renamed,
-preventing a collision.  Since "main" and "puts" are
-external (i.e., lacking any linkage declarations), they are accessible
-outside of the current module.  It is illegal for a function declaration
-to have any linkage type other than "externally visible".
    
-
    
-
-
-
    
-  Global Variables
-
    
-
-
    
-
-
    Global variables define regions of memory allocated at compilation
-time instead of run-time.  Global variables may optionally be
-initialized.  A variable may be defined as a global "constant", which
-indicates that the contents of the variable will never be modified
-(opening options for optimization).
    
-
-
    As SSA values, global variables define pointer values that are in
-scope (i.e. they dominate) for all basic blocks in the program.  Global
-variables always define a pointer to their "content" type because they
-describe a region of memory, and all memory objects in LLVM are
-accessed through pointers.
    
-
-
    
-
-
-
-
    
-  Functions
-
    
-
-
    
-
-
    LLVM function definitions are composed of a (possibly empty) argument list,
-an opening curly brace, a list of basic blocks, and a closing curly brace.  LLVM
-function declarations are defined with the "declare" keyword, a
-function name, and a function signature.
    
-
-
    A function definition contains a list of basic blocks, forming the CFG for
-the function.  Each basic block may optionally start with a label (giving the
-basic block a symbol table entry), contains a list of instructions, and ends
-with a terminator instruction (such as a branch or
-function return).
    
-
-
    The first basic block in program is special in two ways: it is immediately
-executed on entrance to the function, and it is not allowed to have predecessor
-basic blocks (i.e. there can not be any branches to the entry block of a
-function).  Because the block can have no predecessors, it also cannot have any
-PHI nodes.
    
-
-
    LLVM functions are identified by their name and type signature.  Hence, two
-functions with the same name but different parameter lists or return values are
-considered different functions, and LLVM will resolves references to each
-appropriately.
    
-
-
    
-
 
 
 
     Instruction Reference 
    
@@ -2670,7 +2688,7 @@
 
   Chris Lattner
    
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/11/01 08:19:36 $
+  Last modified: $Date: 2004/12/09 16:11:40 $
 
 
 





From criswell at cs.uiuc.edu  Thu Dec  9 10:20:25 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 10:20:25 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/GettingStarted.html 
Message-ID: <200412091620.KAA03536@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

GettingStarted.html updated: 1.91 -> 1.91.2.1
---
Log message:

Running fixheaders is now done for all GCC frontends.


---
Diffs of the changes:  (+3 -5)

Index: llvm/docs/GettingStarted.html
diff -u llvm/docs/GettingStarted.html:1.91 llvm/docs/GettingStarted.html:1.91.2.1
--- llvm/docs/GettingStarted.html:1.91	Wed Dec  8 12:04:14 2004
+++ llvm/docs/GettingStarted.html	Thu Dec  9 10:20:11 2004
@@ -115,8 +115,7 @@
     
      
       
    1. cd where-you-want-the-C-front-end-to-live
       
    2. gunzip --stdout cfrontend.platform.tar.gz | tar -xvf -
-      
    3. Sparc and MacOS X Only:
      
-      cd cfrontend/platform
      
+      
    4. cd cfrontend/platform
      
           ./fixheaders      
     
    
 
@@ -672,8 +671,7 @@
       -
 
 
-
    If you are using Solaris/Sparc or MacOS X/PPC, you will need to fix the
-header files:
    
+
    Next, you will need to fix your system header files:
    
 
 
    cd cfrontend/platform
    
    ./fixheaders
    
@@ -1478,7 +1476,7 @@
   Chris Lattner
    
   Reid Spencer
    
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/12/08 18:04:14 $
+  Last modified: $Date: 2004/12/09 16:20:11 $
 
 
 





From criswell at cs.uiuc.edu  Thu Dec  9 10:26:23 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 10:26:23 -0600
Subject: [llvm-commits] CVS: llvm-www/releases/1.4/announcement.txt 
Message-ID: <200412091626.KAA05733@choi.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.4:

announcement.txt (r1.1) removed
---
Log message:

We don't seem to use this anymore.


---
Diffs of the changes:  (+0 -0)




From lattner at cs.uiuc.edu  Thu Dec  9 10:36:55 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu, 9 Dec 2004 10:36:55 -0600
Subject: [llvm-commits] CVS: llvm/docs/LangRef.html 
Message-ID: <200412091636.iB9GatV5023173@apoc.cs.uiuc.edu>



Changes in directory llvm/docs:

LangRef.html updated: 1.78 -> 1.79
---
Log message:

Reflow and clean up some of the HTML in the initial section, split linkage
types into its own section.


---
Diffs of the changes:  (+122 -87)

Index: llvm/docs/LangRef.html
diff -u llvm/docs/LangRef.html:1.78 llvm/docs/LangRef.html:1.79
--- llvm/docs/LangRef.html:1.78	Thu Dec  9 10:11:40 2004
+++ llvm/docs/LangRef.html	Thu Dec  9 10:36:40 2004
@@ -20,6 +20,7 @@
   
  • High Level Structure
     
      
       
    1. Module Structure
      2. 
+      
    2. Linkage Types
      3. 
       
    3. Global Variables
      4. 
       
    4. Function Structure
      5. 
     
    
@@ -220,66 +221,88 @@
 purposes:
    
 
 
      
-  
    1. Numeric constants are represented as you would expect: 12, -3
-123.421,   etc.  Floating point constants have an optional hexadecimal
-notation.
      2. 
-  
    2. Named values are represented as a string of characters with a '%'
-prefix.   For example, %foo, %DivisionByZero,
-%a.really.long.identifier.  The actual   regular expression used is '%[a-zA-Z$._][a-zA-Z$._0-9]*'.
-Identifiers which require other characters in their names can be
-surrounded   with quotes.  In this way, anything except a "
-character can be used   in a name.
      3. 
-  
    3. Unnamed values are represented as an unsigned numeric value with
-a '%'   prefix.  For example, %12, %2, %44.
      4. 
+  
    4. Numeric constants are represented as you would expect: 12, -3 123.421,
+  etc.  Floating point constants have an optional hexadecimal notation.
      5. 
+
+  
    5. Named values are represented as a string of characters with a '%' prefix.
+  For example, %foo, %DivisionByZero, %a.really.long.identifier.  The actual
+  regular expression used is '%[a-zA-Z$._][a-zA-Z$._0-9]*'.
+  Identifiers which require other characters in their names can be surrounded
+  with quotes.  In this way, anything except a " character can be used
+  in a name.
      6. 
+
+  
    6. Unnamed values are represented as an unsigned numeric value with a '%'
+  prefix.  For example, %12, %2, %44.
      7. 
+
 
    
-
    LLVM requires that values start with a '%' sign for two reasons:
-Compilers don't need to worry about name clashes with reserved words,
-and the set of reserved words may be expanded in the future without
-penalty.  Additionally, unnamed identifiers allow a compiler to quickly
-come up with a temporary variable without having to avoid symbol table
-conflicts.
    
+
+
    LLVM requires that values start with a '%' sign for two reasons: Compilers
+don't need to worry about name clashes with reserved words, and the set of
+reserved words may be expanded in the future without penalty.  Additionally,
+unnamed identifiers allow a compiler to quickly come up with a temporary
+variable without having to avoid symbol table conflicts.
    
+
 
    Reserved words in LLVM are very similar to reserved words in other
 languages. There are keywords for different opcodes ('add', 'cast', 'ret', etc...), for primitive type names ('void', 'uint',
-etc...), and others.  These reserved words cannot conflict with
-variable names, because none of them start with a '%' character.
    
-
    Here is an example of LLVM code to multiply the integer variable '%X'
-by 8:
    
+href="#i_add">add    ', 'cast', 'ret', etc...), for primitive type names ('void', 'uint', etc...),
+and others.  These reserved words cannot conflict with variable names, because
+none of them start with a '%' character.
    
+
+
    Here is an example of LLVM code to multiply the integer variable
+'%X' by 8:
    
+
 
    The easy way:
    
-
      %result = mul uint %X, 8
    
+
+
    +  %result = mul uint %X, 8
+
    
+
 
    After strength reduction:
    
-
      %result = shl uint %X, ubyte 3
    
+
+
    +  %result = shl uint %X, ubyte 3
+
    
+
 
    And the hard way:
    
-
      add uint %X, %X           ; yields {uint}:%0
-  add uint %0, %0           ; yields {uint}:%1
-  %result = add uint %1, %1
    
+
+
    +  add uint %X, %X           ; yields {uint}:%0
+  add uint %0, %0           ; yields {uint}:%1
+  %result = add uint %1, %1
+
    
+
 
    This last way of multiplying %X by 8 illustrates several
 important lexical features of LLVM:
    
+
 
      
-  
    1. Comments are delimited with a ';' and go until the end
-of   line.
      2. 
-  
    2. Unnamed temporaries are created when the result of a computation
-is not   assigned to a named value.
      3. 
+
+  
    3. Comments are delimited with a ';' and go until the end of
+  line.
      4. 
+
+  
    4. Unnamed temporaries are created when the result of a computation is not
+  assigned to a named value.
      5. 
+
   
    5. Unnamed temporaries are numbered sequentially
      6. 
+
 
    
-
    ...and it also show a convention that we follow in this document. 
-When demonstrating instructions, we will follow an instruction with a
-comment that defines the type and name of value produced.  Comments are
-shown in italic text.
    
-
    The one non-intuitive notation for constants is the optional
-hexidecimal form of floating point constants.  For example, the form 'double
+
+
    ...and it also show a convention that we follow in this document.  When
+demonstrating instructions, we will follow an instruction with a comment that
+defines the type and name of value produced.  Comments are shown in italic
+text.
    
+
+
    The one non-intuitive notation for constants is the optional hexidecimal form
+of floating point constants.  For example, the form 'double
 0x432ff973cafa8000' is equivalent to (but harder to read than) 'double
-4.5e+15' which is also supported by the parser.  The only time
-hexadecimal floating point constants are useful (and the only time that
-they are generated by the disassembler) is when an FP constant has to
-be emitted that is not representable as a decimal floating point number
-exactly.  For example, NaN's, infinities, and other special cases are
-represented in their IEEE hexadecimal format so that assembly and
-disassembly do not cause any bits to change in the constants.
    
+4.5e+15    ' which is also supported by the parser.  The only time hexadecimal
+floating point constants are useful (and the only time that they are generated
+by the disassembler) is when an FP constant has to be emitted that is not
+representable as a decimal floating point number exactly.  For example, NaN's,
+infinities, and other special cases are represented in their IEEE hexadecimal
+format so that assembly and disassembly do not cause any bits to change in the
+constants.
    
 
 
 
@@ -323,59 +346,70 @@
 function, and a function definition
 for "main".
    
 
- In general, a module is made up of a list of global
-values, where both functions and global variables are global values. 
-Global values are represented by a pointer to a memory location (in
-this case, a pointer to an array of char, and a pointer to a function),
-and have one of the following linkage types:
+
    In general, a module is made up of a list of global values,
+where both functions and global variables are global values.  Global values are
+represented by a pointer to a memory location (in this case, a pointer to an
+array of char, and a pointer to a function), and have one of the following linkage types.
    
 
-
     
    
+
+
+
+
    
+  Linkage Types
+
    
+
+
    
+
+
    
+All Global Variables and Functions have one of the following types of linkage:
+
    
 
 
    
+
   
    internal 
    
-  
    Global values with internal linkage are only directly accessible
-by objects in the current module.  In particular, linking code into a
-module with an internal global value may cause the internal to be
-renamed as necessary to avoid collisions.  Because the symbol is
-internal to the module, all references can be updated.  This
-corresponds to the notion of the 'static' keyword in C, or the
-idea of "anonymous namespaces" in C++.
-    
     
    
+
+  
    Global values with internal linkage are only directly accessible by
+  objects in the current module.  In particular, linking code into a module with
+  an internal global value may cause the internal to be renamed as necessary to
+  avoid collisions.  Because the symbol is internal to the module, all
+  references can be updated.  This corresponds to the notion of the
+  'static' keyword in C, or the idea of "anonymous namespaces" in C++.
   
    
+
   
    linkonce: 
    
-  
    "linkonce" linkage is similar to internal
-linkage, with the twist that linking together two modules defining the
-same linkonce globals will cause one of the globals to be
-discarded.  This is typically used to implement inline functions. 
-Unreferenced linkonce globals are allowed to be discarded.
-    
     
    
+
+  
    "linkonce" linkage is similar to internal linkage, with
+  the twist that linking together two modules defining the same
+  linkonce globals will cause one of the globals to be discarded.  This
+  is typically used to implement inline functions.  Unreferenced
+  linkonce globals are allowed to be discarded.
   
    
+
   
    weak: 
    
-  
    "weak" linkage is exactly the same as linkonce
-linkage, except that unreferenced weak globals may not be
-discarded.  This is used to implement constructs in C such as "int
-X;" at global scope.
-    
     
    
+
+  
    "weak" linkage is exactly the same as linkonce linkage,
+  except that unreferenced weak globals may not be discarded.  This is
+  used to implement constructs in C such as "int X;" at global scope.
   
    
+
   
    appending: 
    
-  
    "appending" linkage may only be applied to global
-variables of pointer to array type.  When two global variables with
-appending linkage are linked together, the two global arrays are
-appended together.  This is the LLVM, typesafe, equivalent of having
-the system linker append together "sections" with identical names when
-.o files are linked.
-    
     
    
+
+  
    "appending" linkage may only be applied to global variables of
+  pointer to array type.  When two global variables with appending linkage are
+  linked together, the two global arrays are appended together.  This is the
+  LLVM, typesafe, equivalent of having the system linker append together
+  "sections" with identical names when .o files are linked.
   
    
+
   
    externally visible:
    
-  
    If none of the above identifiers are used, the global is
-externally visible, meaning that it participates in linkage and can be
-used to resolve external symbol references.
-    
     
    
+
+  
    If none of the above identifiers are used, the global is externally
+  visible, meaning that it participates in linkage and can be used to resolve
+  external symbol references.
   
    
 
    
 
-
     
    
-
 
    For example, since the ".LC0"
 variable is defined to be internal, if another module defined a ".LC0"
 variable and was linked with this one, one of the two would be renamed,
@@ -383,6 +417,7 @@
 external (i.e., lacking any linkage declarations), they are accessible
 outside of the current module.  It is illegal for a function declaration
 to have any linkage type other than "externally visible".
    
+
 
    
 
 
@@ -2688,7 +2723,7 @@
 
   Chris Lattner
    
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/12/09 16:11:40 $
+  Last modified: $Date: 2004/12/09 16:36:40 $
 
 
 





From criswell at cs.uiuc.edu  Thu Dec  9 10:42:25 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 10:42:25 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/GettingStarted.html 
Message-ID: <200412091642.KAA10409@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

GettingStarted.html updated: 1.91.2.1 -> 1.91.2.2
---
Log message:

Attempt to clarify that there is an additional test suite package.


---
Diffs of the changes:  (+4 -3)

Index: llvm/docs/GettingStarted.html
diff -u llvm/docs/GettingStarted.html:1.91.2.1 llvm/docs/GettingStarted.html:1.91.2.2
--- llvm/docs/GettingStarted.html:1.91.2.1	Thu Dec  9 10:20:11 2004
+++ llvm/docs/GettingStarted.html	Thu Dec  9 10:42:10 2004
@@ -547,8 +547,9 @@
 
    
 If you have the LLVM distribution, you will need to unpack it before you
 can begin to compile it.  LLVM is distributed as a set of two files: the LLVM
-suite and the LLVM GCC front end compiled for your platform.  Each
-file is a TAR archive that is compressed with the gzip program.
+suite and the LLVM GCC front end compiled for your platform.  There is an
+additional test suite that is optional.  Each file is a TAR archive that is
+compressed with the gzip program.
 
    
 
 
     The files are as follows:
@@ -1476,7 +1477,7 @@
   Chris Lattner
    
   Reid Spencer
    
   The LLVM Compiler Infrastructure
    
-  Last modified: $Date: 2004/12/09 16:20:11 $
+  Last modified: $Date: 2004/12/09 16:42:10 $
 
 
 





From criswell at cs.uiuc.edu  Thu Dec  9 11:02:36 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 11:02:36 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/GettingStarted.html 
Message-ID: <200412091702.LAA31969@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

GettingStarted.html updated: 1.91.2.2 -> 1.91.2.3
---
Log message:

Added the extraction of the test suite in the Getting Started Quickly
section.


---
Diffs of the changes:  (+29 -3)

Index: llvm/docs/GettingStarted.html
diff -u llvm/docs/GettingStarted.html:1.91.2.2 llvm/docs/GettingStarted.html:1.91.2.3
--- llvm/docs/GettingStarted.html:1.91.2.2	Thu Dec  9 10:42:10 2004
+++ llvm/docs/GettingStarted.html	Thu Dec  9 11:02:22 2004
@@ -125,7 +125,7 @@
     
      
       
    1. cd where-you-want-llvm-to-live
       
    2. gunzip --stdout llvm-version.tar.gz | tar -xvf -
-      
    3. cd llvm
+      
    4. cd llvm
      5. 
     
    • 
 
     
  • With anonymous CVS access (or use a mirror):
@@ -141,6 +141,32 @@
     
    • 
   
 
+  
  • Get the Test Suite Source Code (optional)
+  
      
+    
    • With the distributed files:
+    
        
+      
      1. cd where-you-want-llvm-to-live
+      
      2. cd llvm/projects
+      
      3. gunzip --stdout llvm-test-version.tar.gz | tar -xvf -
+      
      4. cd ..
        5. 
+    
      • 
+
+    
    • With anonymous CVS access (or use a mirror):
+    
        
+      
      1. cd where-you-want-llvm-to-live
        2. 
+      
      2. cd llvm/projects
+      
      3. cvs -d
+          :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm login
        4. 
+      
      4. Hit the return key when prompted for the password.
+      
      5. cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm 
+          co llvm-test
        6. 
+      
      6. cd llvm-test
        7. 
+      
      7. cvs up -P -d
        8. 
+      
      8. cd ..
        9. 
+    
      • 
+  
    • 
+
+
   
  • Configure the LLVM Build Environment
   
      
     
    1. Change directory to where you want to store the LLVM object
@@ -573,7 +599,7 @@
   
      cfrontend-1.4.i386-unknown-freebsd5.1.tar.gz
      
   
      This is the binary release of the GCC front end for FreeBSD/x86.
      
 
-  
      cfrontend-1.4.powerpc-apple-darwin7.0.0.tar.gz
      
+  
      cfrontend-1.4.powerpc-apple-darwin7.6.0.tar.gz
      
   
      This is the binary release of the GCC front end for MacOS X/PPC.
      
 
 
@@ -1477,7 +1503,7 @@
   Chris Lattner
      
   Reid Spencer
      
   The LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2004/12/09 16:42:10 $
+  Last modified: $Date: 2004/12/09 17:02:22 $
 
 
 





From gaeke at cs.uiuc.edu  Thu Dec  9 11:03:04 2004
From: gaeke at cs.uiuc.edu (Brian Gaeke)
Date: Thu, 9 Dec 2004 11:03:04 -0600 (CST)
Subject: [llvm-commits] CVS: reopt/lib/LightWtProfiling/SecondTrigger.cpp 
Message-ID: <200412091703.LAA19562@kain.cs.uiuc.edu>



Changes in directory reopt/lib/LightWtProfiling:

SecondTrigger.cpp updated: 1.39 -> 1.40
---
Log message:

Add comment to llvm_time_end.


---
Diffs of the changes:  (+3 -0)

Index: reopt/lib/LightWtProfiling/SecondTrigger.cpp
diff -u reopt/lib/LightWtProfiling/SecondTrigger.cpp:1.39 reopt/lib/LightWtProfiling/SecondTrigger.cpp:1.40
--- reopt/lib/LightWtProfiling/SecondTrigger.cpp:1.39	Mon Dec  6 01:54:40 2004
+++ reopt/lib/LightWtProfiling/SecondTrigger.cpp	Thu Dec  9 11:02:54 2004
@@ -73,6 +73,9 @@
   exitCounter[reverseAddr] = 0;
 }
 
+/// llvm_time_end - Called at exits from SLI traces just before returning
+/// to untraced code.
+///
 extern "C" void llvm_time_end(){
   uint64_t i_reg_save[6];
   uint32_t f_reg_save[32];





From gaeke at cs.uiuc.edu  Thu Dec  9 11:07:31 2004
From: gaeke at cs.uiuc.edu (Brian Gaeke)
Date: Thu, 9 Dec 2004 11:07:31 -0600 (CST)
Subject: [llvm-commits] CVS: reopt/test/TEST.reopt.Makefile 
Message-ID: <200412091707.LAA21012@kain.cs.uiuc.edu>



Changes in directory reopt/test:

TEST.reopt.Makefile updated: 1.30 -> 1.31
---
Log message:

-disable-strip is gone; don't use it in REOPTLLC_DEBUG_FLAGS.
Ignore failure exit codes from reopt-llc, g++ and diff; print PASS/FAIL
notations instead of stopping make.


---
Diffs of the changes:  (+12 -6)

Index: reopt/test/TEST.reopt.Makefile
diff -u reopt/test/TEST.reopt.Makefile:1.30 reopt/test/TEST.reopt.Makefile:1.31
--- reopt/test/TEST.reopt.Makefile:1.30	Mon Nov 22 22:40:05 2004
+++ reopt/test/TEST.reopt.Makefile	Thu Dec  9 11:07:20 2004
@@ -42,8 +42,7 @@
 ifdef ENABLE_OPTIMIZED
 REOPTLLC_DEBUG_FLAGS=
 else
-REOPTLLC_DEBUG_FLAGS=-disable-sched -disable-strip -dregalloc=y \
- -print-machineinstrs
+REOPTLLC_DEBUG_FLAGS=-disable-sched -dregalloc=y -print-machineinstrs
 endif
 
 # 1. Run the necessary instrumentation passes over the bytecode,
@@ -52,14 +51,17 @@
 $(PROGRAMS_TO_TEST:%=Output/%.reopt-llc.s): \
 Output/%.reopt-llc.s: Output/%.llvm.bc $(LOPT) $(LLC)
 	@echo "===== Building Reoptimizer version of $(TESTNAME) ====="
-	$(REOPTLLC) -enable-correct-eh-support $(REOPTLLC_DEBUG_FLAGS) \
-	-f -o=$@ $< 2>$@.log
+	-$(REOPTLLC) -enable-correct-eh-support $(REOPTLLC_DEBUG_FLAGS) -f -o=$@ $< 2>$@.log
+	@if test -f $@ -a -f $@.log; then echo "PASS: reopt-llc $(TESTNAME)"; \
+	else echo "FAIL: reopt-llc $(TESTNAME)"; fi
 
 # 2. Link the instrumented binary with the necessary parts of the
 # compiler.
 $(PROGRAMS_TO_TEST:%=Output/%.reopt-llc): \
 Output/%.reopt-llc: Output/%.reopt-llc.s $(REOPTIMIZER_LIB)
-	$(CXX) $(CFLAGS) $(PROFILE) $< -o $@ $(REOPTIMIZER_LIB) $(REOPTIMIZER_SOLARISLIBS)
+	-$(CXX) $(CFLAGS) $(PROFILE) $< -o $@ $(REOPTIMIZER_LIB) $(REOPTIMIZER_SOLARISLIBS)
+	@if test -x $@; then echo "PASS: reopt-link $(TESTNAME)"; \
+	else echo "FAIL: reopt-link $(TESTNAME)"; fi
 
 # 3. Run the reoptimized version.
 ifdef SPECTEST
@@ -82,4 +84,8 @@
 # 4. Diff it against the plain old llc version
 $(PROGRAMS_TO_TEST:%=Output/%.diff-reopt-llc): \
 Output/%.diff-reopt-llc: Output/%.out-llc Output/%.out-reopt-llc
-	-$(DIFFPROG) reopt-llc $* llc $(HIDEDIFF)
+	@if $(DIFFPROG) reopt-llc $* llc $(HIDEDIFF); then \
+	echo "PASS: reopt $(TESTNAME)"; \
+	else \
+	echo "FAIL: reopt $(TESTNAME)"; fi
+





From criswell at cs.uiuc.edu  Thu Dec  9 11:11:32 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 11:11:32 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/configure 
Message-ID: <200412091711.LAA00790@choi.cs.uiuc.edu>



Changes in directory llvm:

configure updated: 1.147 -> 1.147.2.1
---
Log message:

I really didn't want to do this, but I don't want users seeing errors
in the configure script either.
Remove the copying of old qmtest files as they no longer exist in the
source tree.


---
Diffs of the changes:  (+0 -12)

Index: llvm/configure
diff -u llvm/configure:1.147 llvm/configure:1.147.2.1
--- llvm/configure:1.147	Thu Dec  2 01:31:22 2004
+++ llvm/configure	Thu Dec  9 11:11:15 2004
@@ -29575,12 +29575,6 @@
           ac_config_commands="$ac_config_commands test/Makefile.tests"
 
 
-          ac_config_commands="$ac_config_commands test/QMTest/llvm.py"
-
-
-          ac_config_commands="$ac_config_commands test/QMTest/llvmdb.py"
-
-
           ac_config_commands="$ac_config_commands tools/Makefile"
 
 
@@ -30139,8 +30133,6 @@
 ${srcdir}/autoconf/mkinstalldirs `dirname runtime/Makefile`
 ${srcdir}/autoconf/mkinstalldirs `dirname test/Makefile`
 ${srcdir}/autoconf/mkinstalldirs `dirname test/Makefile.tests`
-${srcdir}/autoconf/mkinstalldirs `dirname test/QMTest/llvm.py`
-${srcdir}/autoconf/mkinstalldirs `dirname test/QMTest/llvmdb.py`
 ${srcdir}/autoconf/mkinstalldirs `dirname tools/Makefile`
 ${srcdir}/autoconf/mkinstalldirs `dirname utils/Makefile`
 ${srcdir}/autoconf/mkinstalldirs `dirname projects/Makefile`
@@ -30168,8 +30160,6 @@
   "runtime/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS runtime/Makefile" ;;
   "test/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/Makefile" ;;
   "test/Makefile.tests" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/Makefile.tests" ;;
-  "test/QMTest/llvm.py" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/QMTest/llvm.py" ;;
-  "test/QMTest/llvmdb.py" ) CONFIG_COMMANDS="$CONFIG_COMMANDS test/QMTest/llvmdb.py" ;;
   "tools/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS tools/Makefile" ;;
   "utils/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS utils/Makefile" ;;
   "projects/Makefile" ) CONFIG_COMMANDS="$CONFIG_COMMANDS projects/Makefile" ;;
@@ -31087,8 +31077,6 @@
     runtime/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/runtime/Makefile runtime/Makefile ;;
     test/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/Makefile test/Makefile ;;
     test/Makefile.tests ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/Makefile.tests test/Makefile.tests ;;
-    test/QMTest/llvm.py ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/QMTest/llvm.py test/QMTest/llvm.py ;;
-    test/QMTest/llvmdb.py ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/test/QMTest/llvmdb.py test/QMTest/llvmdb.py ;;
     tools/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/tools/Makefile tools/Makefile ;;
     utils/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/utils/Makefile utils/Makefile ;;
     projects/Makefile ) ${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/projects/Makefile projects/Makefile ;;





From criswell at cs.uiuc.edu  Thu Dec  9 11:11:35 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 11:11:35 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/autoconf/configure.ac 
Message-ID: <200412091711.LAA00794@choi.cs.uiuc.edu>



Changes in directory llvm/autoconf:

configure.ac updated: 1.138 -> 1.138.2.1
---
Log message:

I really didn't want to do this, but I don't want users seeing errors
in the configure script either.
Remove the copying of old qmtest files as they no longer exist in the
source tree.



---
Diffs of the changes:  (+0 -2)

Index: llvm/autoconf/configure.ac
diff -u llvm/autoconf/configure.ac:1.138 llvm/autoconf/configure.ac:1.138.2.1
--- llvm/autoconf/configure.ac:1.138	Tue Nov 30 02:11:54 2004
+++ llvm/autoconf/configure.ac	Thu Dec  9 11:11:20 2004
@@ -567,8 +567,6 @@
 AC_CONFIG_MAKEFILE(runtime/Makefile)
 AC_CONFIG_MAKEFILE(test/Makefile)
 AC_CONFIG_MAKEFILE(test/Makefile.tests)
-AC_CONFIG_MAKEFILE(test/QMTest/llvm.py)
-AC_CONFIG_MAKEFILE(test/QMTest/llvmdb.py)
 AC_CONFIG_MAKEFILE(tools/Makefile)
 AC_CONFIG_MAKEFILE(utils/Makefile)
 AC_CONFIG_MAKEFILE(projects/Makefile)





From lattner at cs.uiuc.edu  Thu Dec  9 11:30:38 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu, 9 Dec 2004 11:30:38 -0600
Subject: [llvm-commits] CVS: llvm/docs/LangRef.html 
Message-ID: <200412091730.iB9HUcvh023315@apoc.cs.uiuc.edu>



Changes in directory llvm/docs:

LangRef.html updated: 1.79 -> 1.80
---
Log message:

Fully document the LLVM constants.  This should go into LLVM 1.4


---
Diffs of the changes:  (+214 -16)

Index: llvm/docs/LangRef.html
diff -u llvm/docs/LangRef.html:1.79 llvm/docs/LangRef.html:1.80
--- llvm/docs/LangRef.html:1.79	Thu Dec  9 10:36:40 2004
+++ llvm/docs/LangRef.html	Thu Dec  9 11:30:23 2004
@@ -44,6 +44,13 @@
     
    
   
    • 
   
  • Constants
+    
      
+      
    1. Simple Constants
+      
    2. Aggregate Constants
+      
    3. Global Variable and Function Addresses
+      
    4. Undefined Values
+      
    5. Constant Expressions
+    
    
   
    • 
   
  • Instruction Reference
     
      
@@ -221,9 +228,6 @@
 purposes:
      
 
 
        
-  
      1. Numeric constants are represented as you would expect: 12, -3 123.421,
-  etc.  Floating point constants have an optional hexadecimal notation.
        2. 
-
   
      2. Named values are represented as a string of characters with a '%' prefix.
   For example, %foo, %DivisionByZero, %a.really.long.identifier.  The actual
   regular expression used is '%[a-zA-Z$._][a-zA-Z$._0-9]*'.
@@ -234,6 +238,8 @@
   
      3. Unnamed values are represented as an unsigned numeric value with a '%'
   prefix.  For example, %12, %2, %44.
        4. 
 
+  
      4. Constants, which are described in section about
+  constants
        5. 
 
      
 
 
      LLVM requires that values start with a '%' sign for two reasons: Compilers
@@ -293,16 +299,6 @@
 defines the type and name of value produced.  Comments are shown in italic
 text.
      
 
-
      The one non-intuitive notation for constants is the optional hexidecimal form
-of floating point constants.  For example, the form 'double
-0x432ff973cafa8000' is equivalent to (but harder to read than) 'double
-4.5e+15' which is also supported by the parser.  The only time hexadecimal
-floating point constants are useful (and the only time that they are generated
-by the disassembler) is when an FP constant has to be emitted that is not
-representable as a decimal floating point number exactly.  For example, NaN's,
-infinities, and other special cases are represented in their IEEE hexadecimal
-format so that assembly and disassembly do not cause any bits to change in the
-constants.
      
 
 
 
@@ -577,25 +573,39 @@
 instructions.  This means that all structures and arrays must be
 manipulated either by pointer or by component.
      
 
+
 
 
       Derived Types 
      
+
 
      
+
 
      The real power in LLVM comes from the derived types in the system. 
 This is what allows a programmer to represent arrays, functions,
 pointers, and other useful types.  Note that these derived types may be
 recursive: For example, it is possible to have a two dimensional array.
      
+
 
      
+
 
 
       Array Type 
      
+
 
      
+
 
      Overview:
      
+
 
      The array type is a very simple derived type that arranges elements
 sequentially in memory.  The array type requires a size (number of
 elements) and an underlying data type.
      
+
 
      Syntax:
      
-
        [<# elements> x <elementtype>]
      
+
+
      +  [<# elements> x <elementtype>]
+
      
+
 
      The number of elements is a constant integer value, elementtype may
 be any type with a size.
      
+
 
      Examples:
      
 
@@ -756,34 +766,220 @@
 
      
   
      
 
      
 
+
+
       Constants 
      
+
+
+
      
+
+
      LLVM has several different basic types of constants.  This section describes
+them all and their syntax.
      
+
+
      
+
+
+
       Simple Constants
+
      
+
+
      
+
+
      
+  
      Boolean constants
      
+
+  
      The two strings 'true' and 'false' are both valid
+  constants of the bool type.
+  
      
+
+  
      Integer constants
      
+
+  
      Standard integers (such as '4') are constants of integer type.  Negative numbers may be used with signed
+  integer types.
+  
      
+
+  
      Floating point constants
      
+
+  
      Floating point constants use standard decimal notation (e.g. 123.421),
+  exponential notation (e.g. 1.23421e+2), or a more precise hexadecimal
+  notation.  etc.  Floating point constants have an optional hexadecimal
+  notation (see below).  Floating point constants must have a floating point type. 
      
+
+  
      Null pointer constants
      
+
+  
      The identifier 'null' is recognized as a null pointer constant,
+  and must be of pointer type.
      
+
+
      
+
+
      The one non-intuitive notation for constants is the optional hexidecimal form
+of floating point constants.  For example, the form 'double
+0x432ff973cafa8000' is equivalent to (but harder to read than) 'double
+4.5e+15'.  The only time hexadecimal floating point constants are required
+(and the only time that they are generated by the disassembler) is when an FP
+constant has to be emitted that is not representable as a decimal floating point
+number exactly.  For example, NaN's, infinities, and other special cases are
+represented in their IEEE hexadecimal format so that assembly and disassembly do
+not cause any bits to change in the constants.
      
+
+
      
+
+
+
      Aggregate Constants
+
      
+
+
      
+
+
      
+  
      Structure constants
      
+
+  
      Structure constants are represented with notation similar to structure
+  type definitions (a comma separated list of elements, surrounded by braces
+  ({}).  For example: "{ int 4, float 17.0 }".  Structure
+  constants must have structure type, and the number and
+  types of elements must match those specified by the type.
+  
      
+
+  
      Array constants
      
+
+  
      Array constants are represented with notation similar to array type
+  definitions (a comma separated list of elements, surrounded by square brackets
+  ([]).  For example: "[ int 42, int 11, int 74 ]".  Array
+  constants must have array type, and the number and
+  types of elements must match those specified by the type.
+  
      
+
+  
      Packed constants
      
+
+  
      Packed constants are represented with notation similar to packed type
+  definitions (a comma separated list of elements, surrounded by
+  less-than/greater-than's (<>).  For example: "< int 42,
+  int 11, int 74, int 100 >".  Packed constants must have packed type, and the number and types of elements must
+  match those specified by the type.
+  
      
+
+  
      Zero initialization
      
+
+  
      The string 'zeroinitializer' can be used to zero initialize a
+  value to zero of any type, including scalar and aggregate types.
+  This is often used to avoid having to print large zero initializers (e.g. for
+  large arrays), and is always exactly equivalent to using explicit zero
+  initializers.
+  
      
+
      
+
+
      
+
+
+
      
+  Global Variable and Function Addresses
+
      
+
+
      
+
+
      The addresses of global variables and functions are always implicitly valid (link-time)
+constants.  These constants explicitly referenced when the identifier for the global is used, and always have pointer type. For example, the following is a legal LLVM
+file:
      
+
+
      +  %X = global int 17
+  %Y = global int 42
+  %Z = global [2 x int*] [ int* %X, int* %Y ]
+
      
+
+
      
+
+
+
      Undefined Values
+
      
+
+
      
+
+
      The string 'undef' is recognized as a filler that has no specified
+value.  Undefined values may be of any type, and be used anywhere a constant
+is.
      
+
+
      Undefined values are used to indicate the compiler that the program is well
+defined no matter what value is used, giving it more freedom.
      
+
+
      
+
+
+
      Constant Expressions
+
      
+
+
      
+
+
      Constant expressions are used to allow expressions involving other constants
+to be used as constants.  Constant expressions may be of any first class type, and may involve any LLVM operation
+that does not have side effects (e.g. load and call are not supported).  The
+following is the syntax for constant expressions:
      
+
+
      
+  
      cast ( CST to TYPE )
      
+
+  
      Cast a constant to another type.
      
+
+  
      getelementptr ( CSTPTR, IDX0, IDX1, ... )
      
+
+  
      Perform the getelementptr operation on
+  constants.  As with the getelementptr
+  instruction, the index list may have zero or more indexes, which are required
+  to make sense for the type of "CSTPTR".
      
+
+  
      OPCODE ( LHS, RHS )
      
+
+  
      Perform the specied operation of the LHS and RHS constants.  OPCODE may be
+  any of the binary or bitwise
+  binary operations.  The constraints on operands are the same as those for
+  the corresponding instruction (e.g. no bitwise operations on floating point
+  are allowed).
      
+
+
      
+
+
      
 
 
 
       Instruction Reference 
      
 
+
 
      
+
 
      The LLVM instruction set consists of several different
 classifications of instructions: terminator
 instructions, binary instructions, memory instructions, and other
 instructions.
      
+
 
      
+
 
 
       Terminator
 Instructions 
      
+
 
      
+
 
      As mentioned previously, every
 basic block in a program ends with a "Terminator" instruction, which
 indicates which block should be executed after the current block is
 finished. These terminator instructions typically yield a 'void'
 value: they produce control flow, not values (the one exception being
 the 'invoke' instruction).
      
+
 
      There are five different terminator instructions: the 'ret' instruction, the 'br'
 instruction, the 'switch' instruction,
 the 'invoke' instruction, the 'unwind' instruction, and the 'unreachable' instruction.
      
+
 
      
+
 
 
       'ret'
 Instruction 
      
@@ -2361,7 +2557,9 @@
 
 
      Syntax:
      
 
      -  call void (<integer type>, <integer type>)* %llvm.writeport (<integer type> <value>, <integer type> <address>)
+  call void (<integer type>, <integer type>)*
+            %llvm.writeport (<integer type> <value>,
+                             <integer type> <address>)
 
      
 
 
      Overview:
      
@@ -2723,7 +2921,7 @@
 
   Chris Lattner
      
   The LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2004/12/09 16:36:40 $
+  Last modified: $Date: 2004/12/09 17:30:23 $
 
 
 





From criswell at cs.uiuc.edu  Thu Dec  9 11:32:49 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 11:32:49 -0600
Subject: [llvm-commits] 
	CVS: llvm-www/releases/1.4/cfrontend-1.4.i686-redhat-linux-gnu.tar.gz
	cfrontend-1.4.powerpc-apple-darwin7.6.0.tar.gz
	cfrontend-1.4.source.tar.gz
	cfrontend-1.4.sparc-sun-solaris2.8.tar.gz 
Message-ID: <200412091732.LAA02367@choi.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.4:

cfrontend-1.4.i686-redhat-linux-gnu.tar.gz added (r1.1)
cfrontend-1.4.powerpc-apple-darwin7.6.0.tar.gz added (r1.1)
cfrontend-1.4.source.tar.gz added (r1.1)
cfrontend-1.4.sparc-sun-solaris2.8.tar.gz added (r1.1)
---
Log message:

Initial commit of CFE.  I don't expect these will change now.


---
Diffs of the changes:  (+0 -0)

Index: llvm-www/releases/1.4/cfrontend-1.4.i686-redhat-linux-gnu.tar.gz


Index: llvm-www/releases/1.4/cfrontend-1.4.powerpc-apple-darwin7.6.0.tar.gz


Index: llvm-www/releases/1.4/cfrontend-1.4.source.tar.gz


Index: llvm-www/releases/1.4/cfrontend-1.4.sparc-sun-solaris2.8.tar.gz





From criswell at cs.uiuc.edu  Thu Dec  9 11:33:20 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 11:33:20 -0600
Subject: [llvm-commits] CVS: llvm-www/releases/1.4/llvm-test-1.4.tar.gz 
Message-ID: <200412091733.LAA02677@choi.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.4:

llvm-test-1.4.tar.gz added (r1.1)
---
Log message:

Initial commit of LLVM Test Suite 1.4.  I don't think this will be
changing either.


---
Diffs of the changes:  (+0 -0)

Index: llvm-www/releases/1.4/llvm-test-1.4.tar.gz





From criswell at cs.uiuc.edu  Thu Dec  9 11:46:41 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 11:46:41 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/LangRef.html 
Message-ID: <200412091746.LAA12624@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

LangRef.html updated: 1.77.2.1 -> 1.77.2.2
---
Log message:

Merge in Chris's updates which add a discussion of constansts, re-organizes
some of the content, and describes the new undef keyword.


---
Diffs of the changes:  (+418 -168)

Index: llvm/docs/LangRef.html
diff -u llvm/docs/LangRef.html:1.77.2.1 llvm/docs/LangRef.html:1.77.2.2
--- llvm/docs/LangRef.html:1.77.2.1	Wed Dec  8 22:26:53 2004
+++ llvm/docs/LangRef.html	Thu Dec  9 11:46:26 2004
@@ -17,6 +17,14 @@
   
    1. Abstract
      2. 
   
    2. Introduction
      3. 
   
    3. Identifiers
      4. 
+  
    4. High Level Structure
+    
        
+      
      1. Module Structure
        2. 
+      
      2. Linkage Types
        3. 
+      
      3. Global Variables
        4. 
+      
      4. Function Structure
        5. 
+    
      
+  
      5. 
   
    5. Type System
     
        
       
      1. Primitive Types 	
@@ -35,11 +43,13 @@
       
        2. 
     
      
   
      6. 
-  
    6. High Level Structure
+  
    7. Constants
     
        
-      
      1. Module Structure
        2. 
-      
      2. Global Variables
        3. 
-      
      3. Function Structure
        4. 
+      
      4. Simple Constants
+      
      5. Aggregate Constants
+      
      6. Global Variable and Function Addresses
+      
      7. Undefined Values
+      
      8. Constant Expressions
     
      
   
      8. 
   
    8. Instruction Reference
@@ -218,71 +228,256 @@
 purposes:
      
 
 
        
-  
      1. Numeric constants are represented as you would expect: 12, -3
-123.421,   etc.  Floating point constants have an optional hexadecimal
-notation.
        2. 
-  
      2. Named values are represented as a string of characters with a '%'
-prefix.   For example, %foo, %DivisionByZero,
-%a.really.long.identifier.  The actual   regular expression used is '%[a-zA-Z$._][a-zA-Z$._0-9]*'.
-Identifiers which require other characters in their names can be
-surrounded   with quotes.  In this way, anything except a "
-character can be used   in a name.
        3. 
-  
      3. Unnamed values are represented as an unsigned numeric value with
-a '%'   prefix.  For example, %12, %2, %44.
        4. 
+  
      4. Named values are represented as a string of characters with a '%' prefix.
+  For example, %foo, %DivisionByZero, %a.really.long.identifier.  The actual
+  regular expression used is '%[a-zA-Z$._][a-zA-Z$._0-9]*'.
+  Identifiers which require other characters in their names can be surrounded
+  with quotes.  In this way, anything except a " character can be used
+  in a name.
        5. 
+
+  
      5. Unnamed values are represented as an unsigned numeric value with a '%'
+  prefix.  For example, %12, %2, %44.
        6. 
+
+  
      6. Constants, which are described in section about
+  constants
        7. 
 
      
-
      LLVM requires that values start with a '%' sign for two reasons:
-Compilers don't need to worry about name clashes with reserved words,
-and the set of reserved words may be expanded in the future without
-penalty.  Additionally, unnamed identifiers allow a compiler to quickly
-come up with a temporary variable without having to avoid symbol table
-conflicts.
      
+
+
      LLVM requires that values start with a '%' sign for two reasons: Compilers
+don't need to worry about name clashes with reserved words, and the set of
+reserved words may be expanded in the future without penalty.  Additionally,
+unnamed identifiers allow a compiler to quickly come up with a temporary
+variable without having to avoid symbol table conflicts.
      
+
 
      Reserved words in LLVM are very similar to reserved words in other
 languages. There are keywords for different opcodes ('add', 'cast', 'ret', etc...), for primitive type names ('void', 'uint',
-etc...), and others.  These reserved words cannot conflict with
-variable names, because none of them start with a '%' character.
      
-
      Here is an example of LLVM code to multiply the integer variable '%X'
-by 8:
      
+href="#i_add">add', 'cast', 'ret', etc...), for primitive type names ('void', 'uint', etc...),
+and others.  These reserved words cannot conflict with variable names, because
+none of them start with a '%' character.
      
+
+
      Here is an example of LLVM code to multiply the integer variable
+'%X' by 8:
      
+
 
      The easy way:
      
-
        %result = mul uint %X, 8
      
+
+
      +  %result = mul uint %X, 8
+
      
+
 
      After strength reduction:
      
-
        %result = shl uint %X, ubyte 3
      
+
+
      +  %result = shl uint %X, ubyte 3
+
      
+
 
      And the hard way:
      
-
        add uint %X, %X           ; yields {uint}:%0
-  add uint %0, %0           ; yields {uint}:%1
-  %result = add uint %1, %1
      
+
+
      +  add uint %X, %X           ; yields {uint}:%0
+  add uint %0, %0           ; yields {uint}:%1
+  %result = add uint %1, %1
+
      
+
 
      This last way of multiplying %X by 8 illustrates several
 important lexical features of LLVM:
      
+
 
        
-  
      1. Comments are delimited with a ';' and go until the end
-of   line.
        2. 
-  
      2. Unnamed temporaries are created when the result of a computation
-is not   assigned to a named value.
        3. 
+
+  
      3. Comments are delimited with a ';' and go until the end of
+  line.
        4. 
+
+  
      4. Unnamed temporaries are created when the result of a computation is not
+  assigned to a named value.
        5. 
+
   
      5. Unnamed temporaries are numbered sequentially
        6. 
+
 
      
-
      ...and it also show a convention that we follow in this document. 
-When demonstrating instructions, we will follow an instruction with a
-comment that defines the type and name of value produced.  Comments are
-shown in italic text.
      
-
      The one non-intuitive notation for constants is the optional
-hexidecimal form of floating point constants.  For example, the form 'double
-0x432ff973cafa8000' is equivalent to (but harder to read than) 'double
-4.5e+15' which is also supported by the parser.  The only time
-hexadecimal floating point constants are useful (and the only time that
-they are generated by the disassembler) is when an FP constant has to
-be emitted that is not representable as a decimal floating point number
-exactly.  For example, NaN's, infinities, and other special cases are
-represented in their IEEE hexadecimal format so that assembly and
-disassembly do not cause any bits to change in the constants.
      
+
+
      ...and it also show a convention that we follow in this document.  When
+demonstrating instructions, we will follow an instruction with a comment that
+defines the type and name of value produced.  Comments are shown in italic
+text.
      
+
+
+
+
+
       High Level Structure 
      
+
+
+
+
       Module Structure
+
      
+
+
      
+
+
      LLVM programs are composed of "Module"s, each of which is a
+translation unit of the input programs.  Each module consists of
+functions, global variables, and symbol table entries.  Modules may be
+combined together with the LLVM linker, which merges function (and
+global variable) definitions, resolves forward declarations, and merges
+symbol table entries. Here is an example of the "hello world" module:
      
+
+
      ; Declare the string constant as a global constant...
+%.LC0 = internal constant [13 x sbyte] c"hello world\0A\00"          ; [13 x sbyte]*
+
+; External declaration of the puts function
+declare int %puts(sbyte*)                                            ; int(sbyte*)* 
+
+; Definition of main function
+int %main() {                                                        ; int()* 
+        ; Convert [13x sbyte]* to sbyte *...
+        %cast210 = getelementptr [13 x sbyte]* %.LC0, long 0, long 0 ; sbyte*
+
+        ; Call puts function to write out the string to stdout...
+        call int %puts(sbyte* %cast210)                              ; int
+        ret int 0
      }
      
+
+
      This example is made up of a global variable
+named ".LC0", an external declaration of the "puts"
+function, and a function definition
+for "main".
      
+
+
      In general, a module is made up of a list of global values,
+where both functions and global variables are global values.  Global values are
+represented by a pointer to a memory location (in this case, a pointer to an
+array of char, and a pointer to a function), and have one of the following linkage types.
      
+
+
      
+
+
+
      
+  Linkage Types
+
      
+
+
      
+
+
      
+All Global Variables and Functions have one of the following types of linkage:
+
      
+
+
      
+
+  
      internal 
      
+
+  
      Global values with internal linkage are only directly accessible by
+  objects in the current module.  In particular, linking code into a module with
+  an internal global value may cause the internal to be renamed as necessary to
+  avoid collisions.  Because the symbol is internal to the module, all
+  references can be updated.  This corresponds to the notion of the
+  'static' keyword in C, or the idea of "anonymous namespaces" in C++.
+  
      
+
+  
      linkonce: 
      
+
+  
      "linkonce" linkage is similar to internal linkage, with
+  the twist that linking together two modules defining the same
+  linkonce globals will cause one of the globals to be discarded.  This
+  is typically used to implement inline functions.  Unreferenced
+  linkonce globals are allowed to be discarded.
+  
      
+
+  
      weak: 
      
+
+  
      "weak" linkage is exactly the same as linkonce linkage,
+  except that unreferenced weak globals may not be discarded.  This is
+  used to implement constructs in C such as "int X;" at global scope.
+  
      
+
+  
      appending: 
      
+
+  
      "appending" linkage may only be applied to global variables of
+  pointer to array type.  When two global variables with appending linkage are
+  linked together, the two global arrays are appended together.  This is the
+  LLVM, typesafe, equivalent of having the system linker append together
+  "sections" with identical names when .o files are linked.
+  
      
+
+  
      externally visible:
      
+
+  
      If none of the above identifiers are used, the global is externally
+  visible, meaning that it participates in linkage and can be used to resolve
+  external symbol references.
+  
      
+
      
+
+
      For example, since the ".LC0"
+variable is defined to be internal, if another module defined a ".LC0"
+variable and was linked with this one, one of the two would be renamed,
+preventing a collision.  Since "main" and "puts" are
+external (i.e., lacking any linkage declarations), they are accessible
+outside of the current module.  It is illegal for a function declaration
+to have any linkage type other than "externally visible".
      
+
+
      
+
+
+
      
+  Global Variables
+
      
+
+
      
+
+
      Global variables define regions of memory allocated at compilation
+time instead of run-time.  Global variables may optionally be
+initialized.  A variable may be defined as a global "constant", which
+indicates that the contents of the variable will never be modified
+(enabling better optimization, allowing the global data to be placed in the
+read-only section of an executable, etc).
      
+
+
      As SSA values, global variables define pointer values that are in
+scope (i.e. they dominate) all basic blocks in the program.  Global
+variables always define a pointer to their "content" type because they
+describe a region of memory, and all memory objects in LLVM are
+accessed through pointers.
      
+
+
      
+
+
+
+
      
+  Functions
+
      
+
+
      
+
+
      LLVM function definitions are composed of a (possibly empty) argument list,
+an opening curly brace, a list of basic blocks, and a closing curly brace.  LLVM
+function declarations are defined with the "declare" keyword, a
+function name, and a function signature.
      
+
+
      A function definition contains a list of basic blocks, forming the CFG for
+the function.  Each basic block may optionally start with a label (giving the
+basic block a symbol table entry), contains a list of instructions, and ends
+with a terminator instruction (such as a branch or
+function return).
      
+
+
      The first basic block in program is special in two ways: it is immediately
+executed on entrance to the function, and it is not allowed to have predecessor
+basic blocks (i.e. there can not be any branches to the entry block of a
+function).  Because the block can have no predecessors, it also cannot have any
+PHI nodes.
      
+
+
      LLVM functions are identified by their name and type signature.  Hence, two
+functions with the same name but different parameter lists or return values are
+considered different functions, and LLVM will resolves references to each
+appropriately.
      
+
 
      
+
+
+
 
 
       Type System 
      
 
+
 
      
+
 
      The LLVM type system is one of the most important features of the
 intermediate representation.  Being typed enables a number of
 optimizations to be performed on the IR directly, without having to do
@@ -290,9 +485,9 @@
 system makes it easier to read the generated code and enables novel
 analyses and transformations that are not feasible to perform on normal
 three address code representations.
      
- 
      
+
+
+
 
 
       Primitive Types 
      
 
      
@@ -378,25 +573,39 @@
 instructions.  This means that all structures and arrays must be
 manipulated either by pointer or by component.
      
 
      
+
 
 
       Derived Types 
      
+
 
      
+
 
      The real power in LLVM comes from the derived types in the system. 
 This is what allows a programmer to represent arrays, functions,
 pointers, and other useful types.  Note that these derived types may be
 recursive: For example, it is possible to have a two dimensional array.
      
+
 
      
+
 
 
       Array Type 
      
+
 
      
+
 
      Overview:
      
+
 
      The array type is a very simple derived type that arranges elements
 sequentially in memory.  The array type requires a size (number of
 elements) and an underlying data type.
      
+
 
      Syntax:
      
-
        [<# elements> x <elementtype>]
      
+
+
      +  [<# elements> x <elementtype>]
+
      
+
 
      The number of elements is a constant integer value, elementtype may
 be any type with a size.
      
+
 
      Examples:
      
 
@@ -558,166 +767,203 @@
 
-
       High Level Structure 
      
+
       Constants 
      
+
+
      
+
+
      LLVM has several different basic types of constants.  This section describes
+them all and their syntax.
      
+
+
      
+
 
-
       Module Structure
+
       Simple Constants
 
      
+
 
      
-
      LLVM programs are composed of "Module"s, each of which is a
-translation unit of the input programs.  Each module consists of
-functions, global variables, and symbol table entries.  Modules may be
-combined together with the LLVM linker, which merges function (and
-global variable) definitions, resolves forward declarations, and merges
-symbol table entries. Here is an example of the "hello world" module:
      
-
      ; Declare the string constant as a global constant...
-%.LC0 = internal constant [13 x sbyte] c"hello world\0A\00"          ; [13 x sbyte]*
 
-; External declaration of the puts function
-declare int %puts(sbyte*)                                            ; int(sbyte*)* 
+
      
+  
      Boolean constants
      
 
-; Definition of main function
-int %main() {                                                        ; int()* 
-        ; Convert [13x sbyte]* to sbyte *...
-        %cast210 = getelementptr [13 x sbyte]* %.LC0, long 0, long 0 ; sbyte*
+  
      The two strings 'true' and 'false' are both valid
+  constants of the bool type.
+  
      
 
-        ; Call puts function to write out the string to stdout...
-        call int %puts(sbyte* %cast210)                              ; int
-        ret int 0
      }
      
-
      This example is made up of a global variable
-named ".LC0", an external declaration of the "puts"
-function, and a function definition
-for "main".
      
- In general, a module is made up of a list of global
-values, where both functions and global variables are global values. 
-Global values are represented by a pointer to a memory location (in
-this case, a pointer to an array of char, and a pointer to a function),
-and have one of the following linkage types:
-
       
      
-
      
-  
      internal 
      
-  
      Global values with internal linkage are only directly accessible
-by objects in the current module.  In particular, linking code into a
-module with an internal global value may cause the internal to be
-renamed as necessary to avoid collisions.  Because the symbol is
-internal to the module, all references can be updated.  This
-corresponds to the notion of the 'static' keyword in C, or the
-idea of "anonymous namespaces" in C++.
-    
       
      
+  
      Integer constants
      
+
+  
      Standard integers (such as '4') are constants of integer type.  Negative numbers may be used with signed
+  integer types.
   
      
-  
      linkonce: 
      
-  
      "linkonce" linkage is similar to internal
-linkage, with the twist that linking together two modules defining the
-same linkonce globals will cause one of the globals to be
-discarded.  This is typically used to implement inline functions. 
-Unreferenced linkonce globals are allowed to be discarded.
-    
       
      
+
+  
      Floating point constants
      
+
+  
      Floating point constants use standard decimal notation (e.g. 123.421),
+  exponential notation (e.g. 1.23421e+2), or a more precise hexadecimal
+  notation.  etc.  Floating point constants have an optional hexadecimal
+  notation (see below).  Floating point constants must have a floating point type. 
      
+
+  
      Null pointer constants
      
+
+  
      The identifier 'null' is recognized as a null pointer constant,
+  and must be of pointer type.
      
+
+
      
+
+
      The one non-intuitive notation for constants is the optional hexidecimal form
+of floating point constants.  For example, the form 'double
+0x432ff973cafa8000' is equivalent to (but harder to read than) 'double
+4.5e+15'.  The only time hexadecimal floating point constants are required
+(and the only time that they are generated by the disassembler) is when an FP
+constant has to be emitted that is not representable as a decimal floating point
+number exactly.  For example, NaN's, infinities, and other special cases are
+represented in their IEEE hexadecimal format so that assembly and disassembly do
+not cause any bits to change in the constants.
      
+
+
      
+
+
+
      Aggregate Constants
+
      
+
+
      
+
+
      
+  
      Structure constants
      
+
+  
      Structure constants are represented with notation similar to structure
+  type definitions (a comma separated list of elements, surrounded by braces
+  ({}).  For example: "{ int 4, float 17.0 }".  Structure
+  constants must have structure type, and the number and
+  types of elements must match those specified by the type.
   
      
-  
      weak: 
      
-  
      "weak" linkage is exactly the same as linkonce
-linkage, except that unreferenced weak globals may not be
-discarded.  This is used to implement constructs in C such as "int
-X;" at global scope.
-    
       
      
+
+  
      Array constants
      
+
+  
      Array constants are represented with notation similar to array type
+  definitions (a comma separated list of elements, surrounded by square brackets
+  ([]).  For example: "[ int 42, int 11, int 74 ]".  Array
+  constants must have array type, and the number and
+  types of elements must match those specified by the type.
   
      
-  
      appending: 
      
-  
      "appending" linkage may only be applied to global
-variables of pointer to array type.  When two global variables with
-appending linkage are linked together, the two global arrays are
-appended together.  This is the LLVM, typesafe, equivalent of having
-the system linker append together "sections" with identical names when
-.o files are linked.
-    
       
      
+
+  
      Packed constants
      
+
+  
      Packed constants are represented with notation similar to packed type
+  definitions (a comma separated list of elements, surrounded by
+  less-than/greater-than's (<>).  For example: "< int 42,
+  int 11, int 74, int 100 >".  Packed constants must have packed type, and the number and types of elements must
+  match those specified by the type.
   
      
-  
      externally visible:
      
-  
      If none of the above identifiers are used, the global is
-externally visible, meaning that it participates in linkage and can be
-used to resolve external symbol references.
-    
       
      
+
+  
      Zero initialization
      
+
+  
      The string 'zeroinitializer' can be used to zero initialize a
+  value to zero of any type, including scalar and aggregate types.
+  This is often used to avoid having to print large zero initializers (e.g. for
+  large arrays), and is always exactly equivalent to using explicit zero
+  initializers.
   
      
 
      
-
       
      
-
      For example, since the ".LC0"
-variable is defined to be internal, if another module defined a ".LC0"
-variable and was linked with this one, one of the two would be renamed,
-preventing a collision.  Since "main" and "puts" are
-external (i.e., lacking any linkage declarations), they are accessible
-outside of the current module.  It is illegal for a function declaration
-to have any linkage type other than "externally visible".
      
+
 
      
 
 
 
      
-  Global Variables
+  Global Variable and Function Addresses
 
      
 
 
      
 
-
      Global variables define regions of memory allocated at compilation
-time instead of run-time.  Global variables may optionally be
-initialized.  A variable may be defined as a global "constant", which
-indicates that the contents of the variable will never be modified
-(opening options for optimization).
      
+
      The addresses of global variables and functions are always implicitly valid (link-time)
+constants.  These constants explicitly referenced when the identifier for the global is used, and always have pointer type. For example, the following is a legal LLVM
+file:
      
 
-
      As SSA values, global variables define pointer values that are in
-scope (i.e. they dominate) for all basic blocks in the program.  Global
-variables always define a pointer to their "content" type because they
-describe a region of memory, and all memory objects in LLVM are
-accessed through pointers.
      
+
      +  %X = global int 17
+  %Y = global int 42
+  %Z = global [2 x int*] [ int* %X, int* %Y ]
+
      
+
+
      
 
+
+
      Undefined Values
 
      
 
+
      
+
+
      The string 'undef' is recognized as a filler that has no specified
+value.  Undefined values may be of any type, and be used anywhere a constant
+is.
      
+
+
      Undefined values are used to indicate the compiler that the program is well
+defined no matter what value is used, giving it more freedom.
      
+
+
      
 
 
-
      
-  Functions
+
      Constant Expressions
 
      
 
 
      
 
-
      LLVM function definitions are composed of a (possibly empty) argument list,
-an opening curly brace, a list of basic blocks, and a closing curly brace.  LLVM
-function declarations are defined with the "declare" keyword, a
-function name, and a function signature.
      
+
      Constant expressions are used to allow expressions involving other constants
+to be used as constants.  Constant expressions may be of any first class type, and may involve any LLVM operation
+that does not have side effects (e.g. load and call are not supported).  The
+following is the syntax for constant expressions:
      
 
-
      A function definition contains a list of basic blocks, forming the CFG for
-the function.  Each basic block may optionally start with a label (giving the
-basic block a symbol table entry), contains a list of instructions, and ends
-with a terminator instruction (such as a branch or
-function return).
      
+
      
+  
      cast ( CST to TYPE )
      
 
-
      The first basic block in program is special in two ways: it is immediately
-executed on entrance to the function, and it is not allowed to have predecessor
-basic blocks (i.e. there can not be any branches to the entry block of a
-function).  Because the block can have no predecessors, it also cannot have any
-PHI nodes.
      
+  
      Cast a constant to another type.
      
 
-
      LLVM functions are identified by their name and type signature.  Hence, two
-functions with the same name but different parameter lists or return values are
-considered different functions, and LLVM will resolves references to each
-appropriately.
      
+  
      getelementptr ( CSTPTR, IDX0, IDX1, ... )
      
 
-
      
+  
      Perform the getelementptr operation on
+  constants.  As with the getelementptr
+  instruction, the index list may have zero or more indexes, which are required
+  to make sense for the type of "CSTPTR".
      
+
+  
      OPCODE ( LHS, RHS )
      
+
+  
      Perform the specied operation of the LHS and RHS constants.  OPCODE may be
+  any of the binary or bitwise
+  binary operations.  The constraints on operands are the same as those for
+  the corresponding instruction (e.g. no bitwise operations on floating point
+  are allowed).
      
+
+
 
+
      
 
 
 
       Instruction Reference 
      
 
+
 
      
+
 
      The LLVM instruction set consists of several different
 classifications of instructions: terminator
 instructions, binary instructions, memory instructions, and other
 instructions.
      
+
 
      
+
 
 
       Terminator
 Instructions 
      
+
 
      
+
 
      As mentioned previously, every
 basic block in a program ends with a "Terminator" instruction, which
 indicates which block should be executed after the current block is
@@ -730,7 +976,9 @@
 the 'invoke' instruction, the 'unwind' instruction, and the 'unreachable' instruction.
      
+
 
      
+
 
 
       'ret'
 Instruction 
      
@@ -2308,7 +2556,9 @@
 
 
      Syntax:
      
 
      -  call void (<integer type>, <integer type>)* %llvm.writeport (<integer type> <value>, <integer type> <address>)
+  call void (<integer type>, <integer type>)*
+            %llvm.writeport (<integer type> <value>,
+                             <integer type> <address>)
 
      
 
 
      Overview:
      
@@ -2670,7 +2920,7 @@
 
   Chris Lattner
      
   The LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2004/12/09 04:26:53 $
+  Last modified: $Date: 2004/12/09 17:46:26 $
 
 
 





From reid at x10sys.com  Thu Dec  9 11:55:49 2004
From: reid at x10sys.com (Reid Spencer)
Date: Thu, 9 Dec 2004 11:55:49 -0600
Subject: [llvm-commits] CVS: llvm/docs/GettingStarted.html 
Message-ID: <200412091755.LAA17206@zion.cs.uiuc.edu>



Changes in directory llvm/docs:

GettingStarted.html updated: 1.91 -> 1.92
---
Log message:

Correct the version numbers for automake, Perl, and CVS.


---
Diffs of the changes:  (+6 -6)

Index: llvm/docs/GettingStarted.html
diff -u llvm/docs/GettingStarted.html:1.91 llvm/docs/GettingStarted.html:1.92
--- llvm/docs/GettingStarted.html:1.91	Wed Dec  8 12:04:14 2004
+++ llvm/docs/GettingStarted.html	Thu Dec  9 11:55:37 2004
@@ -351,13 +351,13 @@
 
     
      
-      
+      
-      
+      
 
@@ -369,7 +369,7 @@
 
     
-      
+      
 
@@ -379,8 +379,8 @@
   
        
     
      1. If you want to make changes to the configure scripts, 
       you will need GNU autoconf (2.59), and consequently, GNU M4 (version 1.4 
-      or higher). You will also need automake. We only use aclocal from that 
-      package.
        2. 
+      or higher). You will also need automake (1.9.2). We only use aclocal 
+      from that package.
     
      2. Only needed if you want to run the automated test 
       suite in the test directory.
        3. 
     
@@ -1478,7 +1478,7 @@
   Chris Lattner
        
   Reid Spencer
        
   The LLVM Compiler Infrastructure
        
-  Last modified: $Date: 2004/12/08 18:04:14 $
+  Last modified: $Date: 2004/12/09 17:55:37 $
 
 
 





From criswell at cs.uiuc.edu  Thu Dec  9 12:02:54 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 12:02:54 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/LangRef.html 
Message-ID: <200412091802.MAA18826@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

LangRef.html updated: 1.77.2.2 -> 1.77.2.3
---
Log message:

Minor typo corrections.


---
Diffs of the changes:  (+12 -12)

Index: llvm/docs/LangRef.html
diff -u llvm/docs/LangRef.html:1.77.2.2 llvm/docs/LangRef.html:1.77.2.3
--- llvm/docs/LangRef.html:1.77.2.2	Thu Dec  9 11:46:26 2004
+++ llvm/docs/LangRef.html	Thu Dec  9 12:02:39 2004
@@ -801,18 +801,18 @@
 
   
        Floating point constants use standard decimal notation (e.g. 123.421),
   exponential notation (e.g. 1.23421e+2), or a more precise hexadecimal
-  notation.  etc.  Floating point constants have an optional hexadecimal
+  notation.  Floating point constants have an optional hexadecimal
   notation (see below).  Floating point constants must have a floating point type. 
        
 
   
        Null pointer constants
        
 
-  
        The identifier 'null' is recognized as a null pointer constant,
+  
        The identifier 'null' is recognized as a null pointer constant
   and must be of pointer type.
        
 
 
 
-
        The one non-intuitive notation for constants is the optional hexidecimal form
+
        The one non-intuitive notation for constants is the optional hexadecimal form
 of floating point constants.  For example, the form 'double
 0x432ff973cafa8000' is equivalent to (but harder to read than) 'double
 4.5e+15'.  The only time hexadecimal floating point constants are required
@@ -835,7 +835,7 @@
 
   
        Structure constants are represented with notation similar to structure
   type definitions (a comma separated list of elements, surrounded by braces
-  ({}).  For example: "{ int 4, float 17.0 }".  Structure
+  ({})).  For example: "{ int 4, float 17.0 }".  Structure
   constants must have structure type, and the number and
   types of elements must match those specified by the type.
   
        
@@ -844,7 +844,7 @@
 
   
        Array constants are represented with notation similar to array type
   definitions (a comma separated list of elements, surrounded by square brackets
-  ([]).  For example: "[ int 42, int 11, int 74 ]".  Array
+  ([])).  For example: "[ int 42, int 11, int 74 ]".  Array
   constants must have array type, and the number and
   types of elements must match those specified by the type.
   
        
@@ -853,7 +853,7 @@
 
   
        Packed constants are represented with notation similar to packed type
   definitions (a comma separated list of elements, surrounded by
-  less-than/greater-than's (<>).  For example: "< int 42,
+  less-than/greater-than's (<>)).  For example: "< int 42,
   int 11, int 74, int 100 >".  Packed constants must have packed type, and the number and types of elements must
   match those specified by the type.
@@ -880,8 +880,8 @@
 
 
        The addresses of global variables and functions are always implicitly valid (link-time)
-constants.  These constants explicitly referenced when the identifier for the global is used, and always have identifier for the global is used and always have pointer type. For example, the following is a legal LLVM
 file:
        
 
@@ -903,8 +903,8 @@
 value.  Undefined values may be of any type, and be used anywhere a constant
 is.
        
 
-
        Undefined values are used to indicate the compiler that the program is well
-defined no matter what value is used, giving it more freedom.
        
+
        Undefined values are used to indicate to the compiler that the program is
+well defined no matter what value is used, giving it more freedom.
        
 
 
 
@@ -2309,7 +2309,7 @@
 
 
        Overview:
        
 
-
        The 'llvm.gcroot' intrinsic declares the existance of a GC root to
+
        The 'llvm.gcroot' intrinsic declares the existence of a GC root to
 the code generator, and allows some metadata to be associated with it.
        
 
 
        Arguments:
        
@@ -2920,7 +2920,7 @@
 
   Chris Lattner
        
   The LLVM Compiler Infrastructure
        
-  Last modified: $Date: 2004/12/09 17:46:26 $
+  Last modified: $Date: 2004/12/09 18:02:39 $
 
 
 





From reid at x10sys.com  Thu Dec  9 12:03:04 2004
From: reid at x10sys.com (Reid Spencer)
Date: Thu, 9 Dec 2004 12:03:04 -0600
Subject: [llvm-commits] CVS: llvm/docs/LangRef.html 
Message-ID: <200412091803.MAA17390@zion.cs.uiuc.edu>



Changes in directory llvm/docs:

LangRef.html updated: 1.80 -> 1.81
---
Log message:

Clean up some grammaro's.


---
Diffs of the changes:  (+11 -12)

Index: llvm/docs/LangRef.html
diff -u llvm/docs/LangRef.html:1.80 llvm/docs/LangRef.html:1.81
--- llvm/docs/LangRef.html:1.80	Thu Dec  9 11:30:23 2004
+++ llvm/docs/LangRef.html	Thu Dec  9 12:02:53 2004
@@ -238,8 +238,8 @@
   
      3. Unnamed values are represented as an unsigned numeric value with a '%'
   prefix.  For example, %12, %2, %44.
        4. 
 
-  
      4. Constants, which are described in section about
-  constants
        5. 
+  
      5. Constants, which are described in a section about
+  constants, below.
        6. 
 
      LLVM requires that values start with a '%' sign for two reasons: Compilers
@@ -778,8 +778,7 @@
 
 
 
-
       Simple Constants
-
      
+
      Simple Constants
      
 
 
      
 
@@ -792,7 +791,7 @@
 
   
      Integer constants
      
 
-  
      Standard integers (such as '4') are constants of Standard integers (such as '4') are constants of the integer type.  Negative numbers may be used with signed
   integer types.
   
      
@@ -801,7 +800,7 @@
 
   
      Floating point constants use standard decimal notation (e.g. 123.421),
   exponential notation (e.g. 1.23421e+2), or a more precise hexadecimal
-  notation.  etc.  Floating point constants have an optional hexadecimal
+  notation.  Floating point constants have an optional hexadecimal
   notation (see below).  Floating point constants must have a floating point type. 
      
 
@@ -816,11 +815,11 @@
 of floating point constants.  For example, the form 'double
 0x432ff973cafa8000' is equivalent to (but harder to read than) 'double
 4.5e+15'.  The only time hexadecimal floating point constants are required
-(and the only time that they are generated by the disassembler) is when an FP
-constant has to be emitted that is not representable as a decimal floating point
-number exactly.  For example, NaN's, infinities, and other special cases are
-represented in their IEEE hexadecimal format so that assembly and disassembly do
-not cause any bits to change in the constants.
      
+(and the only time that they are generated by the disassembler) is when a 
+floating point constant must be emitted but it cannot be represented as a 
+decimal floating point number.  For example, NaN's, infinities, and other 
+special values are represented in their IEEE hexadecimal format so that 
+assembly and disassembly do not cause any bits to change in the constants.
      
 
 
      
 
@@ -2921,7 +2920,7 @@
 
   Chris Lattner
      
   The LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2004/12/09 17:30:23 $
+  Last modified: $Date: 2004/12/09 18:02:53 $
 
 
 





From criswell at cs.uiuc.edu  Thu Dec  9 12:04:22 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 12:04:22 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/GettingStarted.html 
Message-ID: <200412091804.MAA18855@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

GettingStarted.html updated: 1.91.2.3 -> 1.91.2.4
---
Log message:

Merged the changes from 1.91->1.92.  This fixes the required version
numbers of required software packages.


---
Diffs of the changes:  (+6 -6)

Index: llvm/docs/GettingStarted.html
diff -u llvm/docs/GettingStarted.html:1.91.2.3 llvm/docs/GettingStarted.html:1.91.2.4
--- llvm/docs/GettingStarted.html:1.91.2.3	Thu Dec  9 11:02:22 2004
+++ llvm/docs/GettingStarted.html	Thu Dec  9 12:04:07 2004
@@ -376,13 +376,13 @@
 
           
-      
+      
-      
+      
 
@@ -394,7 +394,7 @@
 
     
-      
+      
 
@@ -404,8 +404,8 @@
   
        
     
      1. If you want to make changes to the configure scripts, 
       you will need GNU autoconf (2.59), and consequently, GNU M4 (version 1.4 
-      or higher). You will also need automake. We only use aclocal from that 
-      package.
        2. 
+      or higher). You will also need automake (1.9.2). We only use aclocal 
+      from that package.
     
      2. Only needed if you want to run the automated test 
       suite in the test directory.
        3. 
     
@@ -1503,7 +1503,7 @@
   Chris Lattner
        
   Reid Spencer
        
   The LLVM Compiler Infrastructure
        
-  Last modified: $Date: 2004/12/09 17:02:22 $
+  Last modified: $Date: 2004/12/09 18:04:07 $
 
 
 





From criswell at cs.uiuc.edu  Thu Dec  9 12:07:43 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 12:07:43 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/LangRef.html 
Message-ID: <200412091807.MAA18919@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

LangRef.html updated: 1.77.2.3 -> 1.77.2.4
---
Log message:

Merged in Reid's typo fixes.


---
Diffs of the changes:  (+10 -11)

Index: llvm/docs/LangRef.html
diff -u llvm/docs/LangRef.html:1.77.2.3 llvm/docs/LangRef.html:1.77.2.4
--- llvm/docs/LangRef.html:1.77.2.3	Thu Dec  9 12:02:39 2004
+++ llvm/docs/LangRef.html	Thu Dec  9 12:07:29 2004
@@ -238,8 +238,8 @@
   
      3. Unnamed values are represented as an unsigned numeric value with a '%'
   prefix.  For example, %12, %2, %44.
        4. 
 
-  
      4. Constants, which are described in section about
-  constants
        5. 
+  
      5. Constants, which are described in a section about
+  constants, below.
        6. 
 
      
 
 
      LLVM requires that values start with a '%' sign for two reasons: Compilers
@@ -778,8 +778,7 @@
 
 
 
-
       Simple Constants
-
      
+
      Simple Constants
      
 
 
      
 
@@ -792,7 +791,7 @@
 
   
      Integer constants
      
 
-  
      Standard integers (such as '4') are constants of Standard integers (such as '4') are constants of the integer type.  Negative numbers may be used with signed
   integer types.
   
      
@@ -816,11 +815,11 @@
 of floating point constants.  For example, the form 'double
 0x432ff973cafa8000' is equivalent to (but harder to read than) 'double
 4.5e+15'.  The only time hexadecimal floating point constants are required
-(and the only time that they are generated by the disassembler) is when an FP
-constant has to be emitted that is not representable as a decimal floating point
-number exactly.  For example, NaN's, infinities, and other special cases are
-represented in their IEEE hexadecimal format so that assembly and disassembly do
-not cause any bits to change in the constants.
      
+(and the only time that they are generated by the disassembler) is when a 
+floating point constant must be emitted but it cannot be represented as a 
+decimal floating point number.  For example, NaN's, infinities, and other 
+special values are represented in their IEEE hexadecimal format so that 
+assembly and disassembly do not cause any bits to change in the constants.
      
 
 
      
 
@@ -2920,7 +2919,7 @@
 
   Chris Lattner
      
   The LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2004/12/09 18:02:39 $
+  Last modified: $Date: 2004/12/09 18:07:29 $
 
 
 





From reid at x10sys.com  Thu Dec  9 12:13:23 2004
From: reid at x10sys.com (Reid Spencer)
Date: Thu, 9 Dec 2004 12:13:23 -0600
Subject: [llvm-commits] CVS: llvm/docs/LangRef.html 
Message-ID: <200412091813.MAA17510@zion.cs.uiuc.edu>



Changes in directory llvm/docs:

LangRef.html updated: 1.81 -> 1.82
---
Log message:

More grammaro's fixed.


---
Diffs of the changes:  (+11 -16)

Index: llvm/docs/LangRef.html
diff -u llvm/docs/LangRef.html:1.81 llvm/docs/LangRef.html:1.82
--- llvm/docs/LangRef.html:1.81	Thu Dec  9 12:02:53 2004
+++ llvm/docs/LangRef.html	Thu Dec  9 12:13:12 2004
@@ -893,18 +893,15 @@
 
 
 
-
      Undefined Values
-
      
-
+
      Undefined Values
      
 
      
-
-
      The string 'undef' is recognized as a filler that has no specified
-value.  Undefined values may be of any type, and be used anywhere a constant
-is.
      
-
-
      Undefined values are used to indicate the compiler that the program is well
-defined no matter what value is used, giving it more freedom.
      
-
+  
      The string 'undef' is recognized as a type-less constant that has 
+  no specific value.  Undefined values may be of any type, and be used anywhere 
+  a constant is permitted.
      
+
+  
      Undefined values indicate to the compiler that the program is well defined
+  no matter what value is used, giving the compiler more freedom to optimize.
+  
      
 
      
 
 
@@ -933,14 +930,12 @@
 
   
      OPCODE ( LHS, RHS )
      
 
-  
      Perform the specied operation of the LHS and RHS constants.  OPCODE may be
-  any of the binary or bitwise
+  
      Perform the specified operation of the LHS and RHS constants. OPCODE may 
+  be any of the binary or bitwise
   binary operations.  The constraints on operands are the same as those for
   the corresponding instruction (e.g. no bitwise operations on floating point
   are allowed).
      
-
 
-
 
 
 
@@ -2920,7 +2915,7 @@
 
   Chris Lattner
      
   The LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2004/12/09 18:02:53 $
+  Last modified: $Date: 2004/12/09 18:13:12 $
 
 
 





From criswell at cs.uiuc.edu  Thu Dec  9 12:16:16 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 12:16:16 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/LangRef.html 
Message-ID: <200412091816.MAA01985@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

LangRef.html updated: 1.77.2.4 -> 1.77.2.5
---
Log message:

More fixes from Reid.


---
Diffs of the changes:  (+14 -8)

Index: llvm/docs/LangRef.html
diff -u llvm/docs/LangRef.html:1.77.2.4 llvm/docs/LangRef.html:1.77.2.5
--- llvm/docs/LangRef.html:1.77.2.4	Thu Dec  9 12:07:29 2004
+++ llvm/docs/LangRef.html	Thu Dec  9 12:16:01 2004
@@ -893,10 +893,9 @@
 
 
 
-
      Undefined Values
-
      
-
+
      Undefined Values
      
 
      
+<<<<<<< LangRef.html
 
 
      The string 'undef' is recognized as a filler that has no specified
 value.  Undefined values may be of any type, and be used anywhere a constant
@@ -905,6 +904,15 @@
 
      Undefined values are used to indicate to the compiler that the program is
 well defined no matter what value is used, giving it more freedom.
      
 
+=======
+  
      The string 'undef' is recognized as a type-less constant that has 
+  no specific value.  Undefined values may be of any type, and be used anywhere 
+  a constant is permitted.
      
+
+  
      Undefined values indicate to the compiler that the program is well defined
+  no matter what value is used, giving the compiler more freedom to optimize.
+  
      
+>>>>>>> 1.82
 
      
 
 
@@ -933,14 +941,12 @@
 
   
      OPCODE ( LHS, RHS )
      
 
-  
      Perform the specied operation of the LHS and RHS constants.  OPCODE may be
-  any of the binary or bitwise
+  
      Perform the specified operation of the LHS and RHS constants. OPCODE may 
+  be any of the binary or bitwise
   binary operations.  The constraints on operands are the same as those for
   the corresponding instruction (e.g. no bitwise operations on floating point
   are allowed).
      
-
 
-
 
 
 
@@ -2919,7 +2925,7 @@
 
   Chris Lattner
      
   The LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2004/12/09 18:07:29 $
+  Last modified: $Date: 2004/12/09 18:16:01 $
 
 
 





From criswell at cs.uiuc.edu  Thu Dec  9 12:32:49 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 12:32:49 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/Projects.html 
Message-ID: <200412091832.MAA14454@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

Projects.html updated: 1.12 -> 1.12.2.1
---
Log message:

Update information on llvm-test package.


---
Diffs of the changes:  (+6 -6)

Index: llvm/docs/Projects.html
diff -u llvm/docs/Projects.html:1.12 llvm/docs/Projects.html:1.12.2.1
--- llvm/docs/Projects.html:1.12	Wed Dec  8 11:25:46 2004
+++ llvm/docs/Projects.html	Thu Dec  9 12:32:34 2004
@@ -201,14 +201,14 @@
     
      
 
     
    9. 
-    The LLVM source tree provides benchmarks and programs which are
-    known to compile with the LLVM GCC front ends.  You can use these
+    LLVM contains an optional package called llvm-test
+    which provides benchmarks and programs that are known to compile with the
+    LLVM GCC front ends.  You can use these
     programs to test your code, gather statistics information, and
-    compare it to the current LLVM performance statistics.  These
-    programs are found in the llvm/test/Programs directory.
+    compare it to the current LLVM performance statistics.
     
      
     Currently, there is no way to hook your tests directly into the
-    llvm/test/Programs testing harness.  You will simply
+    llvm/test testing harness.  You will simply
     need to find a way to use the source provided within that directory
     on your own.
   
@@ -443,7 +443,7 @@
   John Criswell
      
   The LLVM Compiler Infrastructure
   
      
-  Last modified: $Date: 2004/12/08 17:25:46 $
+  Last modified: $Date: 2004/12/09 18:32:34 $
 
 
 





From criswell at cs.uiuc.edu  Thu Dec  9 12:38:47 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 12:38:47 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/index.html 
Message-ID: <200412091838.MAA18858@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

index.html updated: 1.37 -> 1.37.2.1
---
Log message:

Added missing link to llvm-ranlib.


---
Diffs of the changes:  (+2 -1)

Index: llvm/docs/index.html
diff -u llvm/docs/index.html:1.37 llvm/docs/index.html:1.37.2.1
--- llvm/docs/index.html:1.37	Fri Dec  3 17:26:23 2004
+++ llvm/docs/index.html	Thu Dec  9 12:38:32 2004
@@ -55,6 +55,7 @@
 manual for the LLVM command line utilities ("man" pages for LLVM tools).
      
 Current tools:
  llvm-ar,
+ llvm-ranlib,
  llvm-as,
  llvm-dis,
  opt,
@@ -229,6 +230,6 @@
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!">
 
   LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2004/12/03 23:26:23 $
+  Last modified: $Date: 2004/12/09 18:38:32 $
 
 





From alkis at cs.uiuc.edu  Thu Dec  9 13:21:34 2004
From: alkis at cs.uiuc.edu (Alkis Evlogimenos)
Date: Thu, 9 Dec 2004 13:21:34 -0600
Subject: [llvm-commits] CVS: llvm-java/test/Makefile.test 
Message-ID: <200412091921.NAA18194@zion.cs.uiuc.edu>



Changes in directory llvm-java/test:

Makefile.test updated: 1.26 -> 1.27
---
Log message:

Print out of a test passes or not.


---
Diffs of the changes:  (+3 -1)

Index: llvm-java/test/Makefile.test
diff -u llvm-java/test/Makefile.test:1.26 llvm-java/test/Makefile.test:1.27
--- llvm-java/test/Makefile.test:1.26	Wed Dec  8 18:00:49 2004
+++ llvm-java/test/Makefile.test	Thu Dec  9 13:21:23 2004
@@ -71,4 +71,6 @@
 
 # rule to diff test output
 %.diff: %.out-nat %.out-jit
-	$(Verb)diff $*.out-nat $*.out-jit > $@ || echo "FAIL: $(notdir $*)"
+	$(Verb)diff $*.out-nat $*.out-jit > $@ \
+	&& echo "PASS: $(notdir $*)" \
+	|| echo "FAIL: $(notdir $*)"





From criswell at cs.uiuc.edu  Thu Dec  9 13:34:57 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 13:34:57 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/LangRef.html 
Message-ID: <200412091934.NAA26095@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

LangRef.html updated: 1.77.2.5 -> 1.77.2.6
---
Log message:

Fix conflict that I missed in the list commit.


---
Diffs of the changes:  (+1 -12)

Index: llvm/docs/LangRef.html
diff -u llvm/docs/LangRef.html:1.77.2.5 llvm/docs/LangRef.html:1.77.2.6
--- llvm/docs/LangRef.html:1.77.2.5	Thu Dec  9 12:16:01 2004
+++ llvm/docs/LangRef.html	Thu Dec  9 13:34:42 2004
@@ -895,16 +895,6 @@
 
 
      Undefined Values
      
 
      
-<<<<<<< LangRef.html
-
-
      The string 'undef' is recognized as a filler that has no specified
-value.  Undefined values may be of any type, and be used anywhere a constant
-is.
      
-
-
      Undefined values are used to indicate to the compiler that the program is
-well defined no matter what value is used, giving it more freedom.
      
-
-=======
   
      The string 'undef' is recognized as a type-less constant that has 
   no specific value.  Undefined values may be of any type, and be used anywhere 
   a constant is permitted.
      
@@ -912,7 +902,6 @@
   
      Undefined values indicate to the compiler that the program is well defined
   no matter what value is used, giving the compiler more freedom to optimize.
   
      
->>>>>>> 1.82
 
      
 
 
@@ -2925,7 +2914,7 @@
 
   Chris Lattner
      
   The LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2004/12/09 18:16:01 $
+  Last modified: $Date: 2004/12/09 19:34:42 $
 
 
 





From criswell at cs.uiuc.edu  Thu Dec  9 13:44:04 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 13:44:04 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/ReleaseNotes.html 
Message-ID: <200412091944.NAA26132@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

ReleaseNotes.html updated: 1.280 -> 1.280.2.1
---
Log message:

Add notes about spurious warnings to the release notes.


---
Diffs of the changes:  (+15 -1)

Index: llvm/docs/ReleaseNotes.html
diff -u llvm/docs/ReleaseNotes.html:1.280 llvm/docs/ReleaseNotes.html:1.280.2.1
--- llvm/docs/ReleaseNotes.html:1.280	Wed Dec  8 14:35:47 2004
+++ llvm/docs/ReleaseNotes.html	Thu Dec  9 13:43:52 2004
@@ -370,6 +370,20 @@
 
 
 
      
+  Known problems with the LLVM Build
+
      
+
+
      
+
+
        
+  
      • 
+  On some platforms, flex and bison may generate warnings.  Usually, these can
+  be safely ignored.
+  
        • 
+
      
+
+
+
      
   Known problems with the LLVM Core
 
      
 
@@ -717,7 +731,7 @@
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" />
 
   The LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2004/12/08 20:35:47 $
+  Last modified: $Date: 2004/12/09 19:43:52 $
 
 
 





From criswell at cs.uiuc.edu  Thu Dec  9 13:54:47 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 13:54:47 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/LLVMVsTheWorld.html 
Message-ID: <200412091954.NAA01703@choi.cs.uiuc.edu>



Changes in directory llvm/docs:

LLVMVsTheWorld.html (r1.8) removed
---
Log message:

Removed as we no longer need it.


---
Diffs of the changes:  (+0 -0)




From brukman at cs.uiuc.edu  Thu Dec  9 14:26:31 2004
From: brukman at cs.uiuc.edu (Misha Brukman)
Date: Thu, 9 Dec 2004 14:26:31 -0600
Subject: [llvm-commits] CVS: llvm/docs/Bugpoint.html 
Message-ID: <200412092026.OAA19171@zion.cs.uiuc.edu>



Changes in directory llvm/docs:

Bugpoint.html updated: 1.4 -> 1.5
---
Log message:

Convert from being a copy of the man page to a full-fledged document.
This doc keeps all the descriptive info from the man page, but not the options.


---
Diffs of the changes:  (+168 -183)

Index: llvm/docs/Bugpoint.html
diff -u llvm/docs/Bugpoint.html:1.4 llvm/docs/Bugpoint.html:1.5
--- llvm/docs/Bugpoint.html:1.4	Mon Nov  1 15:55:46 2004
+++ llvm/docs/Bugpoint.html	Thu Dec  9 14:26:20 2004
@@ -1,41 +1,63 @@
-
+
 
 
-  
-  LLVM: bugpoint tool
+  LLVM bugpoint tool: design and usage
   
-  
-  
 
-
 
-
-
      LLVM: bugpoint tool
      
-
      
-
-
      NAME
      
-bugpoint
-
-
      SYNOPSIS
      
-bugpoint [options] [input LLVM ll/bc files] [LLVM passes] --args <program arguments>...
-
-
-
      DESCRIPTION
      
-
-The bugpoint tool narrows down the source of
-problems in LLVM tools and passes.  It can be used to debug three types of
-failures: optimizer crashes, miscompilations by optimizers, or bad native
-code generation (including problems in the static and JIT compilers).  It aims 
-to reduce large test cases to small, useful ones.  For example,
-if gccas crashes while optimizing a file, it
-will identify the optimization (or combination of optimizations) that causes the
-crash, and reduce the file down to a small example which triggers the crash.
      
+
      
+  LLVM bugpoint tool: design and usage
+
      
+
+
 
-
-
      Design Philosophy
      
+
      
+
      Written by Chris Lattner
      
+
      
+
+
+
      
+Description
+
      
+
+
+
      
+
+
      bugpoint narrows down the source of problems in LLVM tools and
+passes.  It can be used to debug three types of failures: optimizer crashes,
+miscompilations by optimizers, or bad native code generation (including problems
+in the static and JIT compilers).  It aims to reduce large test cases to small,
+useful ones.  For example, if gccas crashes while optimizing a
+file, it will identify the optimization (or combination of optimizations) that
+causes the crash, and reduce the file down to a small example which triggers the
+crash.
      
+
+
      For detailed case scenarios, such as debugging gccas,
+gccld, or one of the LLVM code generators, see How To Submit a Bug Report document.
      
+
+
      
+
+
+
      
+Design Philosophy
+
      
+
 
-bugpoint is designed to be a useful tool without requiring any
+
      
+
+
      bugpoint is designed to be a useful tool without requiring any
 hooks into the LLVM infrastructure at all.  It works with any and all LLVM
 passes and code generators, and does not need to "know" how they work.  Because
 of this, it may appear to do stupid things or miss obvious
@@ -44,47 +66,57 @@
 take a long period of (unattended) time to reduce a test case, but we feel it
 is still worth it. Note that bugpoint is generally very quick unless
 debugging a miscompilation where each test of the program (which requires 
-executing it) takes a long time.
      
+executing it) takes a long time.
      
 
-
-
      Automatic Debugger Selection
      
+
      
 
-bugpoint reads each .bc or .ll file
-specified on the command line and links them together into a single module,
-called the test program.  If any LLVM passes are
-specified on the command line, it runs these passes on the test program.  If
-any of the passes crash, or if they produce malformed output (which causes the 
-verifier to abort),
-bugpoint starts the crash debugger.
      
-
-Otherwise, if the -output option was not
-specified, bugpoint runs the test program with the C backend (which is
-assumed to generate good code) to generate a reference output.  Once
-bugpoint has a reference output for the test program, it tries
-executing it with the selected code generator.  If the
-selected code generator crashes, bugpoint starts the crash debugger on the code generator.  Otherwise, if the
-resulting output differs from the reference output, it assumes the difference
-resulted from a code generator failure, and starts the code generator debugger.
      
+
+
      
+  Automatic Debugger Selection
+
      
+
+
      
+
+
      bugpoint reads each .bc or .ll file specified on
+the command line and links them together into a single module, called the test
+program.  If any LLVM passes are specified on the command line, it runs these
+passes on the test program.  If any of the passes crash, or if they produce
+malformed output (which causes the verifier to abort), bugpoint starts
+the crash debugger.
      
+
+
      Otherwise, if the -output option was not specified,
+bugpoint runs the test program with the C backend (which is assumed to
+generate good code) to generate a reference output.  Once bugpoint has
+a reference output for the test program, it tries executing it with the
+selected code generator.  If the selected code generator crashes,
+bugpoint starts the crash debugger on the
+code generator.  Otherwise, if the resulting output differs from the reference
+output, it assumes the difference resulted from a code generator failure, and
+starts the code generator debugger.
      
 
-Finally, if the output of the selected code generator matches the reference
+
      Finally, if the output of the selected code generator matches the reference
 output, bugpoint runs the test program after all of the LLVM passes
 have been applied to it.  If its output differs from the reference output, it
 assumes the difference resulted from a failure in one of the LLVM passes, and
-enters the miscompilation
-debugger. Otherwise, there is no problem bugpoint can debug.
      
+enters the miscompilation debugger.
+Otherwise, there is no problem bugpoint can debug.
      
+
+
      
+
+
+
      
+  Crash debugger
+
      
 
-
-
      Crash debugger
      
+
      
 
-If an optimizer or code generator crashes, bugpoint will try as hard as
-it can to reduce the list of passes (for optimizer crashes) and the size of the
-test program.  First, bugpoint figures out which combination of
+
      If an optimizer or code generator crashes, bugpoint will try as hard
+as it can to reduce the list of passes (for optimizer crashes) and the size of
+the test program.  First, bugpoint figures out which combination of
 optimizer passes triggers the bug. This is useful when debugging a problem
-exposed by gccas, for example, because it runs over 38 passes.
      
+exposed by gccas, for example, because it runs over 38 passes.
      
 
-Next, bugpoint tries removing functions from the test program, to
+
      Next, bugpoint tries removing functions from the test program, to
 reduce its size.  Usually it is able to reduce a test program to a single
 function, when debugging intraprocedural optimizations.  Once the number of
 functions has been reduced, it attempts to delete various edges in the control
@@ -92,38 +124,55 @@
 bugpoint deletes any individual LLVM instructions whose absence does
 not eliminate the failure.  At the end, bugpoint should tell you what
 passes crash, give you a bytecode file, and give you instructions on how to
-reproduce the failure with opt, analyze, or llc.
      
+reproduce the failure with opt, analyze, or llc.
      
 
-
-
      Code generator debugger
      
+
      
+
+
+
      
+  Code generator debugger
+
      
+
+
      
 
 
      The code generator debugger attempts to narrow down the amount of code that
-is being miscompiled by the selected code generator.  To
-do this, it takes the test program and partitions it into two pieces: one piece
-which it compiles with the C backend (into a shared object), and one piece which
-it runs with either the JIT or the static LLC compiler.  It uses several
-techniques to reduce the amount of code pushed through the LLVM code generator,
-to reduce the potential scope of the problem.  After it is finished, it emits
-two bytecode files (called "test" [to be compiled with the code generator] and
-"safe" [to be compiled with the C backend], respectively), and instructions for
-reproducing the problem.  The code generator debugger assumes that the C backend
-produces good code.
      
-
-
-
      Miscompilation debugger
      
-
-The miscompilation debugger works similarly to the code generator
-debugger.  It works by splitting the test program into two pieces, running the
-optimizations specified on one piece, linking the two pieces back together,
-and then executing the result.
-It attempts to narrow down the list of passes to the one (or few) which are
-causing the miscompilation, then reduce the portion of the test program which is
-being miscompiled.  The miscompilation debugger assumes that the selected
-code generator is working properly.
      
+is being miscompiled by the selected code generator.  To do this, it takes the
+test program and partitions it into two pieces: one piece which it compiles
+with the C backend (into a shared object), and one piece which it runs with
+either the JIT or the static LLC compiler.  It uses several techniques to
+reduce the amount of code pushed through the LLVM code generator, to reduce the
+potential scope of the problem.  After it is finished, it emits two bytecode
+files (called "test" [to be compiled with the code generator] and "safe" [to be
+compiled with the C backend], respectively), and instructions for reproducing
+the problem.  The code generator debugger assumes that the C backend produces
+good code.
      
+
+
      
+
+
+
      
+  Miscompilation debugger
+
      
+
+
      
+
+
      The miscompilation debugger works similarly to the code generator debugger.
+It works by splitting the test program into two pieces, running the
+optimizations specified on one piece, linking the two pieces back together, and
+then executing the result.  It attempts to narrow down the list of passes to
+the one (or few) which are causing the miscompilation, then reduce the portion
+of the test program which is being miscompiled.  The miscompilation debugger
+assumes that the selected code generator is working properly.
      
+
+
      
+
+
+
      
+  Advice for using bugpoint
+
      
+
 
-
-
      Advice for using bugpoint
      
+
      
 
 bugpoint can be a remarkably useful tool, but it sometimes works in
 non-obvious ways.  Here are some hints and tips:
      
@@ -131,10 +180,10 @@
 
        
 
      1. In the code generator and miscompilation debuggers, bugpoint only
     works with programs that have deterministic output.  Thus, if the program
-    outputs argv[0], the date, time, or any other "random" data, bugpoint may
-    misinterpret differences in these data, when output, as the result of a
-    miscompilation.  Programs should be temporarily modified to disable
-    outputs that are likely to vary from run to run.
+    outputs argv[0], the date, time, or any other "random" data,
+    bugpoint may misinterpret differences in these data, when output,
+    as the result of a miscompilation.  Programs should be temporarily modified
+    to disable outputs that are likely to vary from run to run.
 
 
      2. In the code generator and miscompilation debuggers, debugging will go
     faster if you manually modify the program or its inputs to reduce the
@@ -143,15 +192,19 @@
 
      3. bugpoint is extremely useful when working on a new optimization:
     it helps track down regressions quickly.  To avoid having to relink
     bugpoint every time you change your optimization however, have
-    bugpoint dynamically load your optimization with the -load option.
+    bugpoint dynamically load your optimization with the
+    -load option.
+
+
      4. bugpoint can generate a lot of output and run for a long period
+    of time.  It is often useful to capture the output of the program to file.
+    For example, in the C shell, you can run:
        
+
+
        
+
        bugpoint  ... |& tee bugpoint.log
        
+
        
 
-
      5. bugpoint can generate a lot of output and run for a long period of
-    time.  It is often useful to capture the output of the program to file.  For
-    example, in the C shell, you can type:
        
-    bugpoint  ..... |& tee bugpoint.log
-    
        to get a copy of bugpoint's output in the file
-    bugpoint.log, as well as on your terminal.
+    
        to get a copy of bugpoint's output in the file
+    bugpoint.log, as well as on your terminal.
        
 
 
      6. bugpoint cannot debug problems with the LLVM linker. If
     bugpoint crashes before you see its "All input ok" message,
@@ -165,89 +218,21 @@
     
 
      
 
-
      OPTIONS
      
-
-
+
      
 
-
      EXIT STATUS
      
+
 
-If bugpoint succeeds in finding a problem, it will exit with 0.
-Otherwise, if an error occurs, it will exit with a non-zero value.
+
      
+
      
+  Valid CSS!
+  Valid HTML 4.01!
+
+  Chris Lattner
      
+  LLVM Compiler Infrastructure
      
+  Last modified: $Date: 2004/12/09 20:26:20 $
+
      
 
-
      
-Maintained by the LLVM Team.
 
 





From brukman at cs.uiuc.edu  Thu Dec  9 14:27:04 2004
From: brukman at cs.uiuc.edu (Misha Brukman)
Date: Thu, 9 Dec 2004 14:27:04 -0600
Subject: [llvm-commits] CVS: llvm/docs/index.html 
Message-ID: <200412092027.OAA19327@zion.cs.uiuc.edu>



Changes in directory llvm/docs:

index.html updated: 1.37 -> 1.38
---
Log message:

We now have a real Bugpoint doc, not just a huge man page.


---
Diffs of the changes:  (+3 -3)

Index: llvm/docs/index.html
diff -u llvm/docs/index.html:1.37 llvm/docs/index.html:1.38
--- llvm/docs/index.html:1.37	Fri Dec  3 17:26:23 2004
+++ llvm/docs/index.html	Thu Dec  9 14:26:53 2004
@@ -183,8 +183,8 @@
 LLVM - This document describes the design and philosophy behind the LLVM
 source-level debugger.
      10. 
 
-
    10. bugpoint - automatic bug 
-finder and test-case reducer description and usage information.
      11. 
+
    11. bugpoint - automatic bug finder and test-case
+reducer description and usage information.
      12. 
 
 
    12. Compiler Driver (llvmc) - This document
 describes the design and configuration of the LLVM compiler driver tool,
@@ -229,6 +229,6 @@
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!">
 
   LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2004/12/03 23:26:23 $
+  Last modified: $Date: 2004/12/09 20:26:53 $
 
 





From brukman at cs.uiuc.edu  Thu Dec  9 14:27:47 2004
From: brukman at cs.uiuc.edu (Misha Brukman)
Date: Thu, 9 Dec 2004 14:27:47 -0600
Subject: [llvm-commits] CVS: llvm/docs/SourceLevelDebugging.html 
Message-ID: <200412092027.OAA19483@zion.cs.uiuc.edu>



Changes in directory llvm/docs:

SourceLevelDebugging.html updated: 1.10 -> 1.11
---
Log message:

* Straighten a comment to a single line
* Block off the section correctly with 


---
Diffs of the changes:  (+4 -3)

Index: llvm/docs/SourceLevelDebugging.html
diff -u llvm/docs/SourceLevelDebugging.html:1.10 llvm/docs/SourceLevelDebugging.html:1.11
--- llvm/docs/SourceLevelDebugging.html:1.10	Fri Dec  3 18:33:34 2004
+++ llvm/docs/SourceLevelDebugging.html	Thu Dec  9 14:27:37 2004
@@ -72,8 +72,8 @@
 
 
 
-
      Introduction
       
+
      Introduction
       
+
 
 
      
 
@@ -1028,6 +1028,7 @@
 
      
   C/C++ front-end specific debug information
 
      
+
 
 
      
 
@@ -1109,7 +1110,7 @@
 
   Chris Lattner
      
   LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2004/12/04 00:33:34 $
+  Last modified: $Date: 2004/12/09 20:27:37 $
 
 
 





From brukman at cs.uiuc.edu  Thu Dec  9 14:28:53 2004
From: brukman at cs.uiuc.edu (Misha Brukman)
Date: Thu, 9 Dec 2004 14:28:53 -0600
Subject: [llvm-commits] CVS: llvm/docs/CommandGuide/bugpoint.pod 
Message-ID: <200412092028.OAA19669@zion.cs.uiuc.edu>



Changes in directory llvm/docs/CommandGuide:

bugpoint.pod updated: 1.4 -> 1.5
---
Log message:

The textual description is gone from this manpage, only the options and a quick
summary remain.  The manpage references Bugpoint.html as the repository for more
detailed info.


---
Diffs of the changes:  (+3 -134)

Index: llvm/docs/CommandGuide/bugpoint.pod
diff -u llvm/docs/CommandGuide/bugpoint.pod:1.4 llvm/docs/CommandGuide/bugpoint.pod:1.5
--- llvm/docs/CommandGuide/bugpoint.pod:1.4	Fri Jul  2 11:06:19 2004
+++ llvm/docs/CommandGuide/bugpoint.pod	Thu Dec  9 14:28:42 2004
@@ -15,140 +15,9 @@
 can be used to debug three types of failures: optimizer crashes, miscompilations
 by optimizers, or bad native code generation (including problems in the static
 and JIT compilers).  It aims to reduce large test cases to small, useful ones.
-For example, if B crashes while optimizing a file, it will identify the
-optimization (or combination of optimizations) that causes the crash, and reduce
-the file down to a small example which triggers the crash.
-
-=head2 Design Philosophy
-
-B is designed to be a useful tool without requiring any hooks into the
-LLVM infrastructure at all.  It works with any and all LLVM passes and code
-generators, and does not need to "know" how they work.  Because of this, it may
-appear to do stupid things or miss obvious simplifications.  B is also
-designed to trade off programmer time for computer time in the
-compiler-debugging process; consequently, it may take a long period of
-(unattended) time to reduce a test case, but we feel it is still worth it. Note
-that B is generally very quick unless debugging a miscompilation where
-each test of the program (which requires executing it) takes a long time.
-
-=head2 Automatic Debugger Selection
-
-B reads each F<.bc> or F<.ll> file specified on the command line and
-links them together into a single module, called the test program.  If any LLVM
-passes are specified on the command line, it runs these passes on the test
-program.  If any of the passes crash, or if they produce malformed output (which
-causes the verifier to abort), B starts the crash debugger.
-
-Otherwise, if the B<-output> option was not specified, B runs the test
-program with the C backend (which is assumed to generate good code) to generate
-a reference output.  Once B has a reference output for the test
-program, it tries executing it with the selected code generator.  If the
-selected code generator crashes, B starts the L on
-the code generator.  Otherwise, if the resulting output differs from the
-reference output, it assumes the difference resulted from a code generator
-failure, and starts the L.
-
-Finally, if the output of the selected code generator matches the reference
-output, B runs the test program after all of the LLVM passes have been
-applied to it.  If its output differs from the reference output, it assumes the
-difference resulted from a failure in one of the LLVM passes, and enters the
-miscompilation debugger. Otherwise, there is no problem B can debug.
-
-=head2 Crash debugger
-
-If an optimizer or code generator crashes, B will try as hard as it
-can to reduce the list of passes (for optimizer crashes) and the size of the
-test program.  First, B figures out which combination of optimizer
-passes triggers the bug. This is useful when debugging a problem exposed by
-B, for example, because it runs over 38 passes.
-
-Next, B tries removing functions from the test program, to reduce its
-size.  Usually it is able to reduce a test program to a single function, when
-debugging intraprocedural optimizations.  Once the number of functions has been
-reduced, it attempts to delete various edges in the control flow graph, to
-reduce the size of the function as much as possible.  Finally, B
-deletes any individual LLVM instructions whose absence does not eliminate the
-failure.  At the end, B should tell you what passes crash, give you a
-bytecode file, and give you instructions on how to reproduce the failure with
-B, B, or B.
-
-=head2 Code generator debugger
-
-The code generator debugger attempts to narrow down the amount of code that is
-being miscompiled by the selected code generator.  To do this, it takes the test
-program and partitions it into two pieces: one piece which it compiles with the
-C backend (into a shared object), and one piece which it runs with either the
-JIT or the static compiler (B).  It uses several techniques to reduce the
-amount of code pushed through the LLVM code generator, to reduce the potential
-scope of the problem.  After it is finished, it emits two bytecode files (called
-"test" [to be compiled with the code generator] and "safe" [to be compiled with
-the C backend], respectively), and instructions for reproducing the problem.
-The code generator debugger assumes that the C backend produces good code.
-
-=head2 Miscompilation debugger
-
-The miscompilation debugger works similarly to the code generator debugger.  It
-works by splitting the test program into two pieces, running the optimizations
-specified on one piece, linking the two pieces back together, and then executing
-the result.  It attempts to narrow down the list of passes to the one (or few)
-which are causing the miscompilation, then reduce the portion of the test
-program which is being miscompiled.  The miscompilation debugger assumes that
-the selected code generator is working properly.
-
-=head2 Advice for using bugpoint
-
-B can be a remarkably useful tool, but it sometimes works in
-non-obvious ways.  Here are some hints and tips:
-
-=over
-
-=item *
-
-In the code generator and miscompilation debuggers, B only
-works with programs that have deterministic output.  Thus, if the program
-outputs C, the date, time, or any other "random" data, B may
-misinterpret differences in these data, when output, as the result of a
-miscompilation.  Programs should be temporarily modified to disable outputs that
-are likely to vary from run to run.
-
-=item *
-
-In the code generator and miscompilation debuggers, debugging will go faster if
-you manually modify the program or its inputs to reduce the runtime, but still
-exhibit the problem.
-
-=item *
-
-B is extremely useful when working on a new optimization: it helps
-track down regressions quickly.  To avoid having to relink B every
-time you change your optimization, make B dynamically load
-your optimization by using the B<-load> option.
-
-=item *
-
-B can generate a lot of output and run for a long period of time.  It
-is often useful to capture the output of the program to file.  For example, in
-the C shell, you can type:
-
-    bugpoint ... |& tee bugpoint.log
-
-to get a copy of B's output in the file F, as well as on
-your terminal.
-
-=item *
-
-B cannot debug problems with the LLVM linker. If B crashes
-before you see its C message, you might try running C on the same set of input files. If that also crashes, you may be
-experiencing a linker bug.
-
-=item *
-
-If your program is supposed to crash, B will be confused. One way to
-deal with this is to cause B to ignore the exit code from your
-program, by giving it the B<-check-exit-code=false> option.
-
-=back
+For more information on the design and inner workings of B, as well as
+advice for using bugpoint, see F in the LLVM
+distribution.
 
 =head1 OPTIONS
 





From lattner at cs.uiuc.edu  Thu Dec  9 15:06:47 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu, 9 Dec 2004 15:06:47 -0600
Subject: [llvm-commits] CVS: llvm/docs/CommandGuide/Makefile 
Message-ID: <200412092106.iB9L6llO023597@apoc.cs.uiuc.edu>



Changes in directory llvm/docs/CommandGuide:

Makefile updated: 1.9 -> 1.10
---
Log message:

Add new pseudo target


---
Diffs of the changes:  (+2 -0)

Index: llvm/docs/CommandGuide/Makefile
diff -u llvm/docs/CommandGuide/Makefile:1.9 llvm/docs/CommandGuide/Makefile:1.10
--- llvm/docs/CommandGuide/Makefile:1.9	Wed Dec  8 13:01:01 2004
+++ llvm/docs/CommandGuide/Makefile	Thu Dec  9 15:06:32 2004
@@ -57,6 +57,8 @@
 
 $(HTML) : html/.dir man/.dir man/man1/.dir ps/.dir
 
+html: $(HTML)
+
 $(BUILD_OBJ_DIR)/%.html: %.pod
 	$(POD2HTML) --css=manpage.css --htmlroot=. --podpath=. \
 	  --noindex --infile=$< --outfile=$@ --title=$*





From lattner at cs.uiuc.edu  Thu Dec  9 15:16:52 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu, 9 Dec 2004 15:16:52 -0600
Subject: [llvm-commits] CVS: llvm/docs/CommandGuide/llc.pod 
Message-ID: <200412092116.iB9LGqcR023706@apoc.cs.uiuc.edu>



Changes in directory llvm/docs/CommandGuide:

llc.pod updated: 1.6 -> 1.7
---
Log message:

Clean up this man page


---
Diffs of the changes:  (+24 -57)

Index: llvm/docs/CommandGuide/llc.pod
diff -u llvm/docs/CommandGuide/llc.pod:1.6 llvm/docs/CommandGuide/llc.pod:1.7
--- llvm/docs/CommandGuide/llc.pod:1.6	Mon Nov 15 14:22:49 2004
+++ llvm/docs/CommandGuide/llc.pod	Thu Dec  9 15:16:40 2004
@@ -14,34 +14,9 @@
 specified architecture.  The assembly language output can then be passed through
 a native assembler and linker to generate native code.
 
-The choice of architecture for the output assembly code is determined as
-follows, by attempting to satisfy each of the following rules in turn (first
-one wins):
-
-=over
-
-=item *
-
-If the user has specified an architecture with the -m option, use that
-architecture.
-
-=item *
-
-Examine the input LLVM bytecode file: if it is little endian and has a
-pointer size of 32 bits, select the Intel IA-32 architecture.  If it is big
-endian and has a pointer size of 64 bits, select the SparcV9 architecture.
-
-=item *
-
-If B was compiled on an architecture for which it can generate code, select
-the architecture upon which B was compiled.
-
-=item *
-
-Exit with an error message telling the user to specify the output
-architecture explicitly.
-
-=back
+The choice of architecture for the output assembly code is automatically 
+determined from the input bytecode file, unless a B<-m> option is used to override
+the default.
 
 =head1 OPTIONS
 
@@ -90,41 +65,31 @@
 
 =back
 
-=item B<-enable-correct-eh-support>
+=item B<--disable-fp-elim>
+
+Disable frame pointer elimination optimization.
+
+=item B<--enable-correct-eh-support>
 
-Instruct the B<-lowerinvoke> pass to insert code for correct exception handling
+Instruct the B pass to insert code for correct exception handling
 support.  This is expensive and is by default omitted for efficiency.
 
-=item B<-help>
+=item B<--help>
 
 Print a summary of command line options.
 
-=item B<-stats>
+=item B<--stats>
 
 Print statistics recorded by code-generation passes.
 
-=item B<-time-passes>
+=item B<--time-passes>
 
 Record the amount of time needed for each pass and print a report to standard
 error.
 
-=back
-
-=head2 Intel IA-32-specific Options
-
-=over
-
-=item B<--disable-fp-elim>
-
-Disable frame pointer elimination optimization.
-
-=item B<--disable-pattern-isel>
-
-Use the 'simple' X86 instruction selector (the default).
-
 =item B<--print-machineinstrs>
 
-Print generated machine code.
+Print generated machine code between compilation phases (useful for debugging).
 
 =item B<--regalloc>=I
 
@@ -171,6 +136,17 @@
 
 =back
 
+=head2 Intel IA-32-specific Options
+
+=over
+
+=item B<--x86-asm-syntax=att|intel>
+
+Specify whether to emit assembly code in AT&T syntax (the default) or intel
+syntax.
+
+=back
+
 =head2 SPARCV9-specific Options
 
 =over
@@ -183,15 +159,6 @@
 
 Disable local scheduling pass.
 
-=item B<--disable-strip>
-
-The Sparc backend embeds the LLVM bytecode into the assembly output.  This
-option requests that symbol names be retained; by default, they are stripped out.
-
-=item B<--enable-maps>
-
-Emit LLVM-to-machine code mapping information into the assembly output.
-
 =back
 
 =head1 EXIT STATUS





From criswell at cs.uiuc.edu  Thu Dec  9 16:06:54 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 16:06:54 -0600
Subject: [llvm-commits] [release_14] CVS: llvm/docs/CommandGuide/llc.pod 
Message-ID: <200412092206.QAA08418@choi.cs.uiuc.edu>



Changes in directory llvm/docs/CommandGuide:

llc.pod updated: 1.6 -> 1.6.2.1
---
Log message:

Incorporating Chris's update.


---
Diffs of the changes:  (+24 -57)

Index: llvm/docs/CommandGuide/llc.pod
diff -u llvm/docs/CommandGuide/llc.pod:1.6 llvm/docs/CommandGuide/llc.pod:1.6.2.1
--- llvm/docs/CommandGuide/llc.pod:1.6	Mon Nov 15 14:22:49 2004
+++ llvm/docs/CommandGuide/llc.pod	Thu Dec  9 16:06:39 2004
@@ -14,34 +14,9 @@
 specified architecture.  The assembly language output can then be passed through
 a native assembler and linker to generate native code.
 
-The choice of architecture for the output assembly code is determined as
-follows, by attempting to satisfy each of the following rules in turn (first
-one wins):
-
-=over
-
-=item *
-
-If the user has specified an architecture with the -m option, use that
-architecture.
-
-=item *
-
-Examine the input LLVM bytecode file: if it is little endian and has a
-pointer size of 32 bits, select the Intel IA-32 architecture.  If it is big
-endian and has a pointer size of 64 bits, select the SparcV9 architecture.
-
-=item *
-
-If B was compiled on an architecture for which it can generate code, select
-the architecture upon which B was compiled.
-
-=item *
-
-Exit with an error message telling the user to specify the output
-architecture explicitly.
-
-=back
+The choice of architecture for the output assembly code is automatically 
+determined from the input bytecode file, unless a B<-m> option is used to override
+the default.
 
 =head1 OPTIONS
 
@@ -90,41 +65,31 @@
 
 =back
 
-=item B<-enable-correct-eh-support>
+=item B<--disable-fp-elim>
+
+Disable frame pointer elimination optimization.
+
+=item B<--enable-correct-eh-support>
 
-Instruct the B<-lowerinvoke> pass to insert code for correct exception handling
+Instruct the B pass to insert code for correct exception handling
 support.  This is expensive and is by default omitted for efficiency.
 
-=item B<-help>
+=item B<--help>
 
 Print a summary of command line options.
 
-=item B<-stats>
+=item B<--stats>
 
 Print statistics recorded by code-generation passes.
 
-=item B<-time-passes>
+=item B<--time-passes>
 
 Record the amount of time needed for each pass and print a report to standard
 error.
 
-=back
-
-=head2 Intel IA-32-specific Options
-
-=over
-
-=item B<--disable-fp-elim>
-
-Disable frame pointer elimination optimization.
-
-=item B<--disable-pattern-isel>
-
-Use the 'simple' X86 instruction selector (the default).
-
 =item B<--print-machineinstrs>
 
-Print generated machine code.
+Print generated machine code between compilation phases (useful for debugging).
 
 =item B<--regalloc>=I
 
@@ -171,6 +136,17 @@
 
 =back
 
+=head2 Intel IA-32-specific Options
+
+=over
+
+=item B<--x86-asm-syntax=att|intel>
+
+Specify whether to emit assembly code in AT&T syntax (the default) or intel
+syntax.
+
+=back
+
 =head2 SPARCV9-specific Options
 
 =over
@@ -183,15 +159,6 @@
 
 Disable local scheduling pass.
 
-=item B<--disable-strip>
-
-The Sparc backend embeds the LLVM bytecode into the assembly output.  This
-option requests that symbol names be retained; by default, they are stripped out.
-
-=item B<--enable-maps>
-
-Emit LLVM-to-machine code mapping information into the assembly output.
-
 =back
 
 =head1 EXIT STATUS





From criswell at cs.uiuc.edu  Thu Dec  9 16:09:00 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 16:09:00 -0600
Subject: [llvm-commits] CVS: llvm-www/releases/1.4/llvm-1.4.tar.gz 
Message-ID: <200412092209.QAA08446@choi.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.4:

llvm-1.4.tar.gz added (r1.1)
---
Log message:

Initial commit of final LLVM 1.4 tarball.


---
Diffs of the changes:  (+0 -0)

Index: llvm-www/releases/1.4/llvm-1.4.tar.gz





From criswell at cs.uiuc.edu  Thu Dec  9 16:14:08 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 16:14:08 -0600
Subject: [llvm-commits] CVS: llvm-www/releases/1.4/docs/
Message-ID: <200412092214.QAA19681@choi.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.4/docs:

---
Log message:

Directory /home/vadve/shared/InternalCVS/llvm-www/releases/1.4/docs added to the repository


---
Diffs of the changes:  (+0 -0)




From criswell at cs.uiuc.edu  Thu Dec  9 16:14:20 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 16:14:20 -0600
Subject: [llvm-commits] CVS: llvm-www/releases/1.4/docs/img/
Message-ID: <200412092214.QAA19719@choi.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.4/docs/img:

---
Log message:

Directory /home/vadve/shared/InternalCVS/llvm-www/releases/1.4/docs/img added to the repository


---
Diffs of the changes:  (+0 -0)




From criswell at cs.uiuc.edu  Thu Dec  9 16:14:20 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 16:14:20 -0600
Subject: [llvm-commits] CVS: llvm-www/releases/1.4/docs/CommandGuide/
Message-ID: <200412092214.QAA19713@choi.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.4/docs/CommandGuide:

---
Log message:

Directory /home/vadve/shared/InternalCVS/llvm-www/releases/1.4/docs/CommandGuide added to the repository


---
Diffs of the changes:  (+0 -0)




From criswell at cs.uiuc.edu  Thu Dec  9 16:14:20 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 16:14:20 -0600
Subject: [llvm-commits] CVS: llvm-www/releases/1.4/docs/HistoricalNotes/
Message-ID: <200412092214.QAA19716@choi.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.4/docs/HistoricalNotes:

---
Log message:

Directory /home/vadve/shared/InternalCVS/llvm-www/releases/1.4/docs/HistoricalNotes added to the repository


---
Diffs of the changes:  (+0 -0)




From criswell at cs.uiuc.edu  Thu Dec  9 16:14:53 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 16:14:53 -0600
Subject: [llvm-commits] CVS: llvm-www/releases/1.4/docs/CommandGuide/html/
Message-ID: <200412092214.QAA19747@choi.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.4/docs/CommandGuide/html:

---
Log message:

Directory /home/vadve/shared/InternalCVS/llvm-www/releases/1.4/docs/CommandGuide/html added to the repository


---
Diffs of the changes:  (+0 -0)




From criswell at cs.uiuc.edu  Thu Dec  9 16:19:07 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 9 Dec 2004 16:19:07 -0600
Subject: [llvm-commits] CVS: llvm-www/releases/1.4/docs/.cvsignore
	AliasAnalysis.html Bugpoint.html BytecodeFormat.html
	CFEBuildInstrs.html CodeGenerator.html CodingStandards.html
	CommandLine.html CompilerDriver.html CompilerWriterInfo.html
	ExtendingLLVM.html FAQ.html GarbageCollection.html
	GettingStarted.html HowToSubmitABug.html LLVMVsTheWorld.html
	LangRef.html Lexicon.html Makefile MakefileGuide.html
	OpenProjects.html ProgrammersManual.html Projects.html
	ReleaseNotes.html SourceLevelDebugging.html Stacker.html
	SystemLibrary.html TableGenFundamentals.html
	TestingGuide.html UsingLibraries.html
	WritingAnLLVMBackend.html WritingAnLLVMPass.html doxygen.cfg
	doxygen.cfg.in doxygen.css doxygen.footer doxygen.header
	doxygen.intro index.html llvm.css 
Message-ID: <200412092219.QAA19896@choi.cs.uiuc.edu>



Changes in directory llvm-www/releases/1.4/docs:

.cvsignore added (r1.1)
AliasAnalysis.html added (r1.1)
Bugpoint.html added (r1.1)
BytecodeFormat.html added (r1.1)
CFEBuildInstrs.html added (r1.1)
CodeGenerator.html added (r1.1)
CodingStandards.html added (r1.1)
CommandLine.html added (r1.1)
CompilerDriver.html added (r1.1)
CompilerWriterInfo.html added (r1.1)
ExtendingLLVM.html added (r1.1)
FAQ.html added (r1.1)
GarbageCollection.html added (r1.1)
GettingStarted.html added (r1.1)
HowToSubmitABug.html added (r1.1)
LLVMVsTheWorld.html added (r1.1)
LangRef.html added (r1.1)
Lexicon.html added (r1.1)
Makefile added (r1.1)
MakefileGuide.html added (r1.1)
OpenProjects.html added (r1.1)
ProgrammersManual.html added (r1.1)
Projects.html added (r1.1)
ReleaseNotes.html added (r1.1)
SourceLevelDebugging.html added (r1.1)
Stacker.html added (r1.1)
SystemLibrary.html added (r1.1)
TableGenFundamentals.html added (r1.1)
TestingGuide.html added (r1.1)
UsingLibraries.html added (r1.1)
WritingAnLLVMBackend.html added (r1.1)
WritingAnLLVMPass.html added (r1.1)
doxygen.cfg added (r1.1)
doxygen.cfg.in added (r1.1)
doxygen.css added (r1.1)
doxygen.footer added (r1.1)
doxygen.header added (r1.1)
doxygen.intro added (r1.1)
index.html added (r1.1)
llvm.css added (r1.1)
---
Log message:

Adding in documentation for LLVM 1.4.


---
Diffs of the changes:  (+27140 -0)

Index: llvm-www/releases/1.4/docs/.cvsignore
diff -c /dev/null llvm-www/releases/1.4/docs/.cvsignore:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/.cvsignore	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,2 ----
+ doxygen.cfg
+ 


Index: llvm-www/releases/1.4/docs/AliasAnalysis.html
diff -c /dev/null llvm-www/releases/1.4/docs/AliasAnalysis.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/AliasAnalysis.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,953 ----
+ 
+ 
+ 
+   LLVM Alias Analysis Infrastructure
+   
+ 
+ 
+ 
+ 
      
+   LLVM Alias Analysis Infrastructure
+ 
      
+ 
+ 
        
+   
      1. Introduction
        2. 
+ 
+   
      2. AliasAnalysis Class Overview
+     
+   
        3. 
+ 
+   
      3. Writing a new AliasAnalysis Implementation
+     
+   
        4. 
+ 
+   
      4. Using alias analysis results
+     
+   
        5. 
+ 
+   
      5. Existing alias analysis implementations and clients
+     
+   
        6. 
+ 
      
+ 
+ 
      
+   
      Written by Chris Lattner
      
+ 
      
+ 
+ 
+ 
      
+   Introduction
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Alias Analysis (aka Pointer Analysis) is a class of techniques which attempt
+ to determine whether or not two pointers ever can point to the same object in
+ memory.  There are many different algorithms for alias analysis and many
+ different ways of classifying them: flow-sensitive vs flow-insensitive,
+ context-sensitive vs context-insensitive, field-sensitive vs field-insensitive,
+ unification-based vs subset-based, etc.  Traditionally, alias analyses respond
+ to a query with a Must, May, or No alias response,
+ indicating that two pointers always point to the same object, might point to the
+ same object, or are known to never point to the same object.
      
+ 
+ 
      The LLVM AliasAnalysis
+ class is the primary interface used by clients and implementations of alias
+ analyses in the LLVM system.  This class is the common interface between clients
+ of alias analysis information and the implementations providing it, and is
+ designed to support a wide range of implementations and clients (but currently
+ all clients are assumed to be flow-insensitive).  In addition to simple alias
+ analysis information, this class exposes Mod/Ref information from those
+ implementations which can provide it, allowing for powerful analyses and
+ transformations to work well together.
      
+ 
+ 
      This document contains information necessary to successfully implement this
+ interface, use it, and to test both sides.  It also explains some of the finer
+ points about what exactly results mean.  If you feel that something is unclear
+ or should be added, please let me
+ know.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   AliasAnalysis Class Overview
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      The AliasAnalysis
+ class defines the interface that the various alias analysis implementations
+ should support.  This class exports two important enums: AliasResult
+ and ModRefResult which represent the result of an alias query or a
+ mod/ref query, respectively.
      
+ 
+ 
      The AliasAnalysis interface exposes information about memory,
+ represented in several different ways.  In particular, memory objects are
+ represented as a starting address and size, and function calls are represented
+ as the actual call or invoke instructions that performs the
+ call.  The AliasAnalysis interface also exposes some helper methods
+ which allow you to get mod/ref information for arbitrary instructions.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Representation of Pointers
+ 
      
+ 
+ 
      
+ 
+ 
      Most importantly, the AliasAnalysis class provides several methods
+ which are used to query whether or not two memory objects alias, whether
+ function calls can modify or read a memory object, etc.  For all of these
+ queries, memory objects are represented as a pair of their starting address (a
+ symbolic LLVM Value*) and a static size.
      
+ 
+ 
      Representing memory objects as a starting address and a size is critically
+ important for correct Alias Analyses.  For example, consider this (silly, but
+ possible) C code:
      
+ 
+ 
      
+ 
      + int i;
+ char C[2];
+ char A[10]; 
+ /* ... */
+ for (i = 0; i != 10; ++i) {
+   C[0] = A[i];          /* One byte store */
+   C[1] = A[9-i];        /* One byte store */
+ }
+ 
      
+ 
      
+ 
+ 
      In this case, the basicaa pass will disambiguate the stores to
+ C[0] and C[1] because they are accesses to two distinct
+ locations one byte apart, and the accesses are each one byte.  In this case, the
+ LICM pass can use store motion to remove the stores from the loop.  In
+ constrast, the following code:
      
+ 
+ 
      
+ 
      + int i;
+ char C[2];
+ char A[10]; 
+ /* ... */
+ for (i = 0; i != 10; ++i) {
+   ((short*)C)[0] = A[i];  /* Two byte store! */
+   C[1] = A[9-i];          /* One byte store */
+ }
+ 
      
+ 
      
+ 
+ 
      In this case, the two stores to C do alias each other, because the access to
+ the &C[0] element is a two byte access.  If size information wasn't
+ available in the query, even the first case would have to conservatively assume
+ that the accesses alias.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The alias method
+ 
      
+   
+ 
      
+ The alias method is the primary interface used to determine whether or
+ not two memory objects alias each other.  It takes two memory objects as input
+ and returns MustAlias, MayAlias, or NoAlias as appropriate.
+ 
      
+ 
+ 
+ 
      
+   Must, May, and No Alias Responses
+ 
      
+ 
+ 
      
+ 
+ 
      An Alias Analysis implementation can return one of three responses:
+ MustAlias, MayAlias, and NoAlias.  The No and May alias results are obvious: if
+ the two pointers can never equal each other, return NoAlias, if they might,
+ return MayAlias.
      
+ 
+ 
      The MustAlias response is trickier though.  In LLVM, the Must Alias response
+ may only be returned if the two memory objects are guaranteed to always start at
+ exactly the same location.  If two memory objects overlap, but do not start at
+ the same location, return MayAlias.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The getModRefInfo methods
+ 
      
+ 
+ 
      
+ 
+ 
      The getModRefInfo methods return information about whether the
+ execution of an instruction can read or modify a memory location.  Mod/Ref
+ information is always conservative: if an instruction might read or write
+ a location, ModRef is returned.
      
+ 
+ 
      The AliasAnalysis class also provides a getModRefInfo
+ method for testing dependencies between function calls.  This method takes two
+ call sites (CS1 & CS2), returns NoModRef if the two calls refer to disjoint
+ memory locations, Ref if CS1 reads memory written by CS2, Mod if CS1 writes to
+ memory read or written by CS2, or ModRef if CS1 might read or write memory
+ accessed by CS2.  Note that this relation is not commutative.  Clients that use
+ this method should be predicated on the hasNoModRefInfoForCalls()
+ method, which indicates whether or not an analysis can provide mod/ref
+ information for function call pairs (most can not).  If this predicate is false,
+ the client shouldn't waste analysis time querying the getModRefInfo
+ method many times.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Other useful AliasAnalysis methods
+ 
      
+ 
+ 
      
+ 
+ 
      
+ Several other tidbits of information are often collected by various alias
+ analysis implementations and can be put to good use by various clients.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The getMustAliases method
+ 
      
+ 
+ 
      
+ 
+ 
      The getMustAliases method returns all values that are known to
+ always must alias a pointer.  This information can be provided in some cases for
+ important objects like the null pointer and global values.  Knowing that a
+ pointer always points to a particular function allows indirect calls to be
+ turned into direct calls, for example.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The pointsToConstantMemory method
+ 
      
+ 
+ 
      
+ 
+ 
      The pointsToConstantMemory method returns true if and only if the
+ analysis can prove that the pointer only points to unchanging memory locations
+ (functions, constant global variables, and the null pointer).  This information
+ can be used to refine mod/ref information: it is impossible for an unchanging
+ memory location to be modified.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The doesNotAccessMemory and
+   onlyReadsMemory methods
+ 
      
+ 
+ 
      
+ 
+ 
      These methods are used to provide very simple mod/ref information for
+ function calls.  The doesNotAccessMemory method returns true for a
+ function if the analysis can prove that the function never reads or writes to
+ memory, or if the function only reads from constant memory.  Functions with this
+ property are side-effect free and only depend on their input arguments, allowing
+ them to be eliminated if they form common subexpressions or be hoisted out of
+ loops.  Many common functions behave this way (e.g., sin and
+ cos) but many others do not (e.g., acos, which modifies the
+ errno variable).
      
+ 
+ 
      The onlyReadsMemory method returns true for a function if analysis
+ can prove that (at most) the function only reads from non-volatile memory.
+ Functions with this property are side-effect free, only depending on their input
+ arguments and the state of memory when they are called.  This property allows
+ calls to these functions to be eliminated and moved around, as long as there is
+ no store instruction that changes the contents of memory.  Note that all
+ functions that satisfy the doesNotAccessMemory method also satisfies
+ onlyReadsMemory.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Writing a new AliasAnalysis Implementation
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Writing a new alias analysis implementation for LLVM is quite
+ straight-forward.  There are already several implementations that you can use
+ for examples, and the following information should help fill in any details.
+ For a examples, take a look at the various alias analysis
+ implementations included with LLVM.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Different Pass styles
+ 
      
+ 
+ 
      
+ 
+ 
      The first step to determining what type of LLVM pass you need to use for your Alias
+ Analysis.  As is the case with most other analyses and transformations, the
+ answer should be fairly obvious from what type of problem you are trying to
+ solve:
      
+ 
+ 
        
+   
      1. If you require interprocedural analysis, it should be a
+       Pass.
        2. 
+   
      2. If you are a function-local analysis, subclass FunctionPass.
        3. 
+   
      3. If you don't need to look at the program at all, subclass 
+       ImmutablePass.
        4. 
+ 
      
+ 
+ 
      In addition to the pass that you subclass, you should also inherit from the
+ AliasAnalysis interface, of course, and use the
+ RegisterAnalysisGroup template to register as an implementation of
+ AliasAnalysis.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Required initialization calls
+ 
      
+ 
+ 
      
+ 
+ 
      Your subclass of AliasAnalysis is required to invoke two methods on
+ the AliasAnalysis base class: getAnalysisUsage and
+ InitializeAliasAnalysis.  In particular, your implementation of
+ getAnalysisUsage should explicitly call into the
+ AliasAnalysis::getAnalysisUsage method in addition to doing any
+ declaring any pass dependencies your pass has.  Thus you should have something
+ like this:
      
+ 
+ 
      
+ 
      + void getAnalysisUsage(AnalysisUsage &AU) const {
+   AliasAnalysis::getAnalysisUsage(AU);
+   // declare your dependencies here.
+ }
+ 
      
+ 
      
+ 
+ 
      Additionally, your must invoke the InitializeAliasAnalysis method
+ from your analysis run method (run for a Pass,
+ runOnFunction for a FunctionPass, or InitializePass
+ for an ImmutablePass).  For example (as part of a Pass):
      
+ 
+ 
      
+ 
      + bool run(Module &M) {
+   InitializeAliasAnalysis(this);
+   // Perform analysis here...
+   return false;
+ }
+ 
      
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Interfaces which may be specified
+ 
      
+ 
+ 
      
+ 
+ 
      All of the AliasAnalysis
+ virtual methods default to providing chaining to another
+ alias analysis implementation, which ends up returning conservatively correct
+ information (returning "May" Alias and "Mod/Ref" for alias and mod/ref queries
+ respectively).  Depending on the capabilities of the analysis you are
+ implementing, you just override the interfaces you can improve.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
+ 
      
+   AliasAnalysis chaining behavior
+ 
      
+ 
+ 
      
+ 
+ 
      With only two special exceptions (the basicaa and no-aa
+ passes) every alias analysis pass chains to another alias analysis
+ implementation (for example, the user can specify "-basicaa -ds-aa
+ -anders-aa -licm" to get the maximum benefit from the three alias
+ analyses).  The alias analysis class automatically takes care of most of this
+ for methods that you don't override.  For methods that you do override, in code
+ paths that return a conservative MayAlias or Mod/Ref result, simply return
+ whatever the superclass computes.  For example:
      
+ 
+ 
      
+ 
      + AliasAnalysis::AliasResult alias(const Value *V1, unsigned V1Size,
+                                  const Value *V2, unsigned V2Size) {
+   if (...)
+     return NoAlias;
+   ...
+ 
+   // Couldn't determine a must or no-alias result.
+   return AliasAnalysis::alias(V1, V1Size, V2, V2Size);
+ }
+ 
      
+ 
      
+ 
+ 
      In addition to analysis queries, you must make sure to unconditionally pass
+ LLVM update notification methods to the superclass as
+ well if you override them, which allows all alias analyses in a change to be
+ updated.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Updating analysis results for transformations
+ 
      
+ 
+ 
      
+ 
      
+ Alias analysis information is initially computed for a static snapshot of the
+ program, but clients will use this information to make transformations to the
+ code.  All but the most trivial forms of alias analysis will need to have their
+ analysis results updated to reflect the changes made by these transformations.
+ 
      
+ 
+ 
      
+ The AliasAnalysis interface exposes two methods which are used to
+ communicate program changes from the clients to the analysis implementations.
+ Various alias analysis implementations should use these methods to ensure that
+ their internal data structures are kept up-to-date as the program changes (for
+ example, when an instruction is deleted), and clients of alias analysis must be
+ sure to call these interfaces appropriately.
+ 
      
+ 
      
+ 
+ 
+ 
      The deleteValue method
      
+ 
+ 
      
+ The deleteValue method is called by transformations when they remove an
+ instruction or any other value from the program (including values that do not
+ use pointers).  Typically alias analyses keep data structures that have entries
+ for each value in the program.  When this method is called, they should remove
+ any entries for the specified value, if they exist.
+ 
      
+ 
+ 
+ 
      The copyValue method
      
+ 
+ 
      
+ The copyValue method is used when a new value is introduced into the
+ program.  There is no way to introduce a value into the program that did not
+ exist before (this doesn't make sense for a safe compiler transformation), so
+ this is the only way to introduce a new value.  This method indicates that the
+ new value has exactly the same properties as the value being copied.
+ 
      
+ 
+ 
+ 
      The replaceWithNewValue method
      
+ 
+ 
      
+ This method is a simple helper method that is provided to make clients easier to
+ use.  It is implemented by copying the old analysis information to the new
+ value, then deleting the old value.  This method cannot be overridden by alias
+ analysis implementations.
+ 
      
+ 
+ 
+ 
      
+   Efficiency Issues
+ 
      
+ 
+ 
      
+ 
+ 
      From the LLVM perspective, the only thing you need to do to provide an
+ efficient alias analysis is to make sure that alias analysis queries are
+ serviced quickly.  The actual calculation of the alias analysis results (the
+ "run" method) is only performed once, but many (perhaps duplicate) queries may
+ be performed.  Because of this, try to move as much computation to the run
+ method as possible (within reason).
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Using alias analysis results
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      There are several different ways to use alias analysis results.  In order of
+ preference, these are...
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Using the -load-vn Pass
+ 
      
+ 
+ 
      
+ 
+ 
      The load-vn pass uses alias analysis to provide value numbering
+ information for load instructions and pointer values.  If your analysis
+ or transformation can be modeled in a form that uses value numbering
+ information, you don't have to do anything special to handle load instructions:
+ just use the load-vn pass, which uses alias analysis.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Using the AliasSetTracker class
+ 
      
+ 
+ 
      
+ 
+ 
      Many transformations need information about alias sets that are active
+ in some scope, rather than information about pairwise aliasing.  The AliasSetTracker class
+ is used to efficiently build these Alias Sets from the pairwise alias analysis
+ information provided by the AliasAnalysis interface.
      
+ 
+ 
      First you initialize the AliasSetTracker by using the "add" methods
+ to add information about various potentially aliasing instructions in the scope
+ you are interested in.  Once all of the alias sets are completed, your pass
+ should simply iterate through the constructed alias sets, using the
+ AliasSetTracker begin()/end() methods.
      
+ 
+ 
      The AliasSets formed by the AliasSetTracker are guaranteed
+ to be disjoint, calculate mod/ref information and volatility for the set, and
+ keep track of whether or not all of the pointers in the set are Must aliases.
+ The AliasSetTracker also makes sure that sets are properly folded due to call
+ instructions, and can provide a list of pointers in each set.
      
+ 
+ 
      As an example user of this, the Loop
+ Invariant Code Motion pass uses AliasSetTrackers to calculate alias
+ sets for each loop nest.  If an AliasSet in a loop is not modified,
+ then all load instructions from that set may be hoisted out of the loop.  If any
+ alias sets are stored to and are must alias sets, then the stores may be
+ sunk to outside of the loop, promoting the memory location to a register for the
+ duration of the loop nest.  Both of these transformations only apply if the
+ pointer argument is loop-invariant.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The AliasSetTracker implementation
+ 
      
+ 
+ 
      
+ 
+ 
      The AliasSetTracker class is implemented to be as efficient as possible.  It
+ uses the union-find algorithm to efficiently merge AliasSets when a pointer is
+ inserted into the AliasSetTracker that aliases multiple sets.  The primary data
+ structure is a hash table mapping pointers to the AliasSet they are in.
      
+ 
+ 
      The AliasSetTracker class must maintain a list of all of the LLVM Value*'s
+ that are in each AliasSet.  Since the hash table already has entries for each
+ LLVM Value* of interest, the AliasesSets thread the linked list through these
+ hash-table nodes to avoid having to allocate memory unnecessarily, and to make
+ merging alias sets extremely efficient (the linked list merge is constant time).
+ 
      
+ 
+ 
      You shouldn't need to understand these details if you are just a client of
+ the AliasSetTracker, but if you look at the code, hopefully this brief
+ description will help make sense of why things are designed the way they
+ are.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Using the AliasAnalysis interface directly
+ 
      
+ 
+ 
      
+ 
+ 
      If neither of these utility class are what your pass needs, you should use
+ the interfaces exposed by the AliasAnalysis class directly.  Try to use
+ the higher-level methods when possible (e.g., use mod/ref information instead of
+ the alias method directly if possible) to get the
+ best precision and efficiency.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Existing alias analysis implementations and clients
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      If you're going to be working with the LLVM alias analysis infrastructure,
+ you should know what clients and implementations of alias analysis are
+ available.  In particular, if you are implementing an alias analysis, you should
+ be aware of the the clients that are useful
+ for monitoring and evaluating different implementations.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Available AliasAnalysis implementations
+ 
      
+ 
+ 
      
+ 
+ 
      This section lists the various implementations of the AliasAnalysis
+ interface.  With the exception of the -no-aa and
+ -basicaa implementations, all of these chain to other alias analysis implementations.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The -no-aa pass
+ 
      
+ 
+ 
      
+ 
+ 
      The -no-aa pass is just like what it sounds: an alias analysis that
+ never returns any useful information.  This pass can be useful if you think that
+ alias analysis is doing something wrong and are trying to narrow down a
+ problem.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The -basicaa pass
+ 
      
+ 
+ 
      
+ 
+ 
      The -basicaa pass is the default LLVM alias analysis.  It is an
+ aggressive local analysis that "knows" many important facts:
      
+ 
+ 
        
+ 
      • Distinct globals, stack allocations, and heap allocations can never
+     alias.
        • 
+ 
      • Globals, stack allocations, and heap allocations never alias the null
+     pointer.
        • 
+ 
      • Different fields of a structure do not alias.
        • 
+ 
      • Indexes into arrays with statically differing subscripts cannot alias.
        • 
+ 
      • Many common standard C library functions never access memory or only read memory.
        • 
+ 
      • Pointers that obviously point to constant globals
+     "pointToConstantMemory".
        • 
+ 
      • Function calls can not modify or references stack allocations if they never
+     escape from the function that allocates them (a common case for automatic
+     arrays).
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The -globalsmodref-aa pass
+ 
      
+ 
+ 
      
+ 
+ 
      This pass implements a simple context-sensitive mod/ref and alias analysis
+ for internal global variables that don't "have their address taken".  If a
+ global does not have its address taken, the pass knows that no pointers alias
+ the global.  This pass also keeps track of functions that it knows never access
+ memory or never read memory.  This allows certain optimizations (e.g. GCSE) to
+ eliminate call instructions entirely.
+ 
      
+ 
+ 
      The real power of this pass is that it provides context-sensitive mod/ref 
+ information for call instructions.  This allows the optimizer to know that 
+ calls to a function do not clobber or read the value of the global, allowing 
+ loads and stores to be eliminated.
      
+ 
+ 
      Note that this pass is somewhat limited in its scope (only support 
+ non-address taken globals), but is very quick analysis.
      
+ 
      
+ 
+ 
+ 
      
+   The -anders-aa pass
+ 
      
+ 
+ 
      
+ 
+ 
      The -anders-aa pass implements the well-known "Andersen's algorithm"
+ for interprocedural alias analysis.  This algorithm is a subset-based,
+ flow-insensitive, context-insensitive, and field-insensitive alias analysis that
+ is widely believed to be fairly precise.  Unfortunately, this algorithm is also
+ O(N3).  The LLVM implementation currently does not implement any of
+ the refinements (such as "online cycle elimination" or "offline variable
+ substitution") to improve its efficiency, so it can be quite slow in common
+ cases.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The -steens-aa pass
+ 
      
+ 
+ 
      
+ 
+ 
      The -steens-aa pass implements a variation on the well-known
+ "Steensgaard's algorithm" for interprocedural alias analysis.  Steensgaard's
+ algorithm is a unification-based, flow-insensitive, context-insensitive, and
+ field-insensitive alias analysis that is also very scalable (effectively linear
+ time).
      
+ 
+ 
      The LLVM -steens-aa pass implements a "speculatively
+ field-sensitive" version of Steensgaard's algorithm using the Data
+ Structure Analysis framework.  This gives it substantially more precision than
+ the standard algorithm while maintaining excellent analysis scalability.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The -ds-aa pass
+ 
      
+ 
+ 
      
+ 
+ 
      The -ds-aa pass implements the full Data Structure Analysis
+ algorithm.  Data Structure Analysis is a modular unification-based,
+ flow-insensitive, context-sensitive, and speculatively
+ field-sensitive alias analysis that is also quite scalable, usually at
+ O(n*log(n)).
      
+ 
+ 
      This algorithm is capable of responding to a full variety of alias analysis
+ queries, and can provide context-sensitive mod/ref information as well.  The
+ only major facility not implemented so far is support for must-alias
+ information.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Alias analysis driven transformations
+ 
      
+ 
+ 
      
+ LLVM includes several alias-analysis driven transformations which can be used
+ with any of the implementations above.
+ 
      
+ 
+ 
+ 
      
+   The -adce pass
+ 
      
+ 
+ 
      
+ 
+ 
      The -adce pass, which implements Aggressive Dead Code Elimination
+ uses the AliasAnalysis interface to delete calls to functions that do
+ not have side-effects and are not used.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   The -licm pass
+ 
      
+ 
+ 
      
+ 
+ 
      The -licm pass implements various Loop Invariant Code Motion related
+ transformations.  It uses the AliasAnalysis interface for several
+ different transformations:
      
+ 
+ 
        
+ 
      • It uses mod/ref information to hoist or sink load instructions out of loops
+ if there are no instructions in the loop that modifies the memory loaded.
        • 
+ 
+ 
      • It uses mod/ref information to hoist function calls out of loops that do not
+ write to memory and are loop-invariant.
        • 
+ 
+ 
      • If uses alias information to promote memory objects that are loaded and
+ stored to in loops to live in a register instead.  It can do this if there are
+ no may aliases to the loaded/stored memory location.
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The -argpromotion pass
+ 
      
+ 
+ 
      
+ 
      
+ The -argpromotion pass promotes by-reference arguments to be passed in
+ by-value instead.  In particular, if pointer arguments are only loaded from it
+ passes in the value loaded instead of the address to the function.  This pass
+ uses alias information to make sure that the value loaded from the argument
+ pointer is not modified between the entry of the function and any load of the
+ pointer.
      
+ 
      
+ 
+ 
+ 
      
+   The -load-vn & -gcse passes
+ 
      
+ 
+ 
      
+ 
+ 
      The -load-vn pass uses alias analysis to "value
+ number" loads and pointers values, which is used by the GCSE pass to
+ eliminate instructions.  The -load-vn pass relies on alias information
+ and must-alias information.  This combination of passes can make the following
+ transformations:
      
+ 
+ 
        
+ 
      • Redundant load instructions are eliminated.
        • 
+ 
      • Load instructions that follow a store to the same location are replaced with
+ the stored value ("store forwarding").
        • 
+ 
      • Pointers values (e.g. formal arguments) that must-alias simpler expressions
+ (e.g. global variables or the null pointer) are replaced.  Note that this
+ implements transformations like "virtual method resolution", turning indirect
+ calls into direct calls.
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Clients for debugging and evaluation of
+   implementations
+ 
      
+ 
+ 
      
+ 
+ 
      These passes are useful for evaluating the various alias analysis
+ implementations.  You can use them with commands like 'opt -anders-aa -ds-aa
+ -aa-eval foo.bc -disable-output -stats'.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The -print-alias-sets pass
+ 
      
+ 
+ 
      
+ 
+ 
      The -print-alias-sets pass is exposed as part of the
+ analyze tool to print out the Alias Sets formed by the AliasSetTracker class.  This is useful if you're using
+ the AliasSetTracker class.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   The -count-aa pass
+ 
      
+ 
+ 
      
+ 
+ 
      The -count-aa pass is useful to see how many queries a particular
+ pass is making and what responses are returned by the alias analysis.  As an
+ example,
      
+ 
+ 
      
+ 
      + % opt -basicaa -count-aa -ds-aa -count-aa -licm
+ 
      
+ 
      
+ 
+ 
      will print out how many queries (and what responses are returned) by the
+ -licm pass (of the -ds-aa pass) and how many queries are made
+ of the -basicaa pass by the -ds-aa pass.  This can be useful
+ when debugging a transformation or an alias analysis implementation.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The -aa-eval pass
+ 
      
+ 
+ 
      
+ 
+ 
      The -aa-eval pass simply iterates through all pairs of pointers in a
+ function and asks an alias analysis whether or not the pointers alias.  This
+ gives an indication of the precision of the alias analysis.  Statistics are
+ printed indicating the percent of no/may/must aliases found (a more precise
+ algorithm will have a lower number of may aliases).
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Chris Lattner
      
+   LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/Bugpoint.html
diff -c /dev/null llvm-www/releases/1.4/docs/Bugpoint.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/Bugpoint.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,253 ----
+ 
+ 
+ 
+   
+   LLVM: bugpoint tool
+   
+   
+   
+ 
+ 
+ 
+ 
+ 
      LLVM: bugpoint tool
      
+ 
      
+ 
+ 
      NAME
      
+ bugpoint
+ 
+ 
      SYNOPSIS
      
+ bugpoint [options] [input LLVM ll/bc files] [LLVM passes] --args <program arguments>...
+ 
+ 
+ 
      DESCRIPTION
      
+ 
+ The bugpoint tool narrows down the source of
+ problems in LLVM tools and passes.  It can be used to debug three types of
+ failures: optimizer crashes, miscompilations by optimizers, or bad native
+ code generation (including problems in the static and JIT compilers).  It aims 
+ to reduce large test cases to small, useful ones.  For example,
+ if gccas crashes while optimizing a file, it
+ will identify the optimization (or combination of optimizations) that causes the
+ crash, and reduce the file down to a small example which triggers the crash.
      
+ 
+ 
+ 
      Design Philosophy
      
+ 
+ bugpoint is designed to be a useful tool without requiring any
+ hooks into the LLVM infrastructure at all.  It works with any and all LLVM
+ passes and code generators, and does not need to "know" how they work.  Because
+ of this, it may appear to do stupid things or miss obvious
+ simplifications.  bugpoint is also designed to trade off programmer
+ time for computer time in the compiler-debugging process; consequently, it may
+ take a long period of (unattended) time to reduce a test case, but we feel it
+ is still worth it. Note that bugpoint is generally very quick unless
+ debugging a miscompilation where each test of the program (which requires 
+ executing it) takes a long time.
      
+ 
+ 
+ 
      Automatic Debugger Selection
      
+ 
+ bugpoint reads each .bc or .ll file
+ specified on the command line and links them together into a single module,
+ called the test program.  If any LLVM passes are
+ specified on the command line, it runs these passes on the test program.  If
+ any of the passes crash, or if they produce malformed output (which causes the 
+ verifier to abort),
+ bugpoint starts the crash debugger.
      
+ 
+ Otherwise, if the -output option was not
+ specified, bugpoint runs the test program with the C backend (which is
+ assumed to generate good code) to generate a reference output.  Once
+ bugpoint has a reference output for the test program, it tries
+ executing it with the selected code generator.  If the
+ selected code generator crashes, bugpoint starts the crash debugger on the code generator.  Otherwise, if the
+ resulting output differs from the reference output, it assumes the difference
+ resulted from a code generator failure, and starts the code generator debugger.
      
+ 
+ Finally, if the output of the selected code generator matches the reference
+ output, bugpoint runs the test program after all of the LLVM passes
+ have been applied to it.  If its output differs from the reference output, it
+ assumes the difference resulted from a failure in one of the LLVM passes, and
+ enters the miscompilation
+ debugger. Otherwise, there is no problem bugpoint can debug.
      
+ 
+ 
+ 
      Crash debugger
      
+ 
+ If an optimizer or code generator crashes, bugpoint will try as hard as
+ it can to reduce the list of passes (for optimizer crashes) and the size of the
+ test program.  First, bugpoint figures out which combination of
+ optimizer passes triggers the bug. This is useful when debugging a problem
+ exposed by gccas, for example, because it runs over 38 passes.
      
+ 
+ Next, bugpoint tries removing functions from the test program, to
+ reduce its size.  Usually it is able to reduce a test program to a single
+ function, when debugging intraprocedural optimizations.  Once the number of
+ functions has been reduced, it attempts to delete various edges in the control
+ flow graph, to reduce the size of the function as much as possible.  Finally,
+ bugpoint deletes any individual LLVM instructions whose absence does
+ not eliminate the failure.  At the end, bugpoint should tell you what
+ passes crash, give you a bytecode file, and give you instructions on how to
+ reproduce the failure with opt, analyze, or llc.
      
+ 
+ 
+ 
      Code generator debugger
      
+ 
+ 
      The code generator debugger attempts to narrow down the amount of code that
+ is being miscompiled by the selected code generator.  To
+ do this, it takes the test program and partitions it into two pieces: one piece
+ which it compiles with the C backend (into a shared object), and one piece which
+ it runs with either the JIT or the static LLC compiler.  It uses several
+ techniques to reduce the amount of code pushed through the LLVM code generator,
+ to reduce the potential scope of the problem.  After it is finished, it emits
+ two bytecode files (called "test" [to be compiled with the code generator] and
+ "safe" [to be compiled with the C backend], respectively), and instructions for
+ reproducing the problem.  The code generator debugger assumes that the C backend
+ produces good code.
      
+ 
+ 
+ 
      Miscompilation debugger
      
+ 
+ The miscompilation debugger works similarly to the code generator
+ debugger.  It works by splitting the test program into two pieces, running the
+ optimizations specified on one piece, linking the two pieces back together,
+ and then executing the result.
+ It attempts to narrow down the list of passes to the one (or few) which are
+ causing the miscompilation, then reduce the portion of the test program which is
+ being miscompiled.  The miscompilation debugger assumes that the selected
+ code generator is working properly.
      
+ 
+ 
+ 
      Advice for using bugpoint
      
+ 
+ bugpoint can be a remarkably useful tool, but it sometimes works in
+ non-obvious ways.  Here are some hints and tips:
      
+ 
+ 
        
+ 
      1. In the code generator and miscompilation debuggers, bugpoint only
+     works with programs that have deterministic output.  Thus, if the program
+     outputs argv[0], the date, time, or any other "random" data, bugpoint may
+     misinterpret differences in these data, when output, as the result of a
+     miscompilation.  Programs should be temporarily modified to disable
+     outputs that are likely to vary from run to run.
+ 
+ 
      2. In the code generator and miscompilation debuggers, debugging will go
+     faster if you manually modify the program or its inputs to reduce the
+     runtime, but still exhibit the problem.
+ 
+ 
      3. bugpoint is extremely useful when working on a new optimization:
+     it helps track down regressions quickly.  To avoid having to relink
+     bugpoint every time you change your optimization however, have
+     bugpoint dynamically load your optimization with the -load option.
+ 
+ 
      4. bugpoint can generate a lot of output and run for a long period of
+     time.  It is often useful to capture the output of the program to file.  For
+     example, in the C shell, you can type:
        
+     bugpoint  ..... |& tee bugpoint.log
+     
        to get a copy of bugpoint's output in the file
+     bugpoint.log, as well as on your terminal.
+ 
+ 
      5. bugpoint cannot debug problems with the LLVM linker. If
+     bugpoint crashes before you see its "All input ok" message,
+     you might try llvm-link -v on the same set of input files. If
+     that also crashes, you may be experiencing a linker bug.
+ 
+ 
      6. If your program is supposed to crash, bugpoint will be
+     confused. One way to deal with this is to cause bugpoint to ignore the exit
+     code from your program, by giving it the -check-exit-code=false
+     option.
+     
+ 
      
+ 
+ 
      OPTIONS
      
+ 
+ 
+ 
+ 
      EXIT STATUS
      
+ 
+ If bugpoint succeeds in finding a problem, it will exit with 0.
+ Otherwise, if an error occurs, it will exit with a non-zero value.
+ 
+ 
      
+ Maintained by the       LLVM Team.
+ 
+ 


Index: llvm-www/releases/1.4/docs/BytecodeFormat.html
diff -c /dev/null llvm-www/releases/1.4/docs/BytecodeFormat.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/BytecodeFormat.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,1904 ----
+ 
+ 
+ 
+   
+   LLVM Bytecode File Format
+   
+   
+ 
+ 
+ 
       LLVM Bytecode File Format 
      
+ 
        
+   
      1. Abstract
        2. 
+   
      2. Concepts
+     
          
+       
        1. Blocks
          2. 
+       
        2. Lists
          3. 
+       
        3. Fields
          4. 
+       
        4. Alignment
          5. 
+       
        5. Variable Bit-Rate Encoding
          6. 
+       
        6. Encoding Primitives
          7. 
+       
        7. Slots
          8. 
+     
        
+   
        3. 
+   
      3. General Structure 
        4. 
+   
      4. Block Definitions
+     
          
+       
        1. Signature Block
          2. 
+       
        2. Module Block
          3. 
+       
        3. Global Type Pool
          4. 
+       
        4. Module Info Block
          5. 
+       
        5. Global Constant Pool
          6. 
+       
        6. Function Definition
          7. 
+       
        7. Compaction Table
          8. 
+       
        8. Instruction List
          9. 
+       
        9. Instruction Opcodes
          10. 
+       
        10. Symbol Table
          11. 
+     
        
+   
        5. 
+   
      5. Version Differences
+     
          
+       
        1. Version 1.3 Differences From 1.4
          2. 
+       
        2. Version 1.2 Differences From 1.3
          3. 
+       
        3. Version 1.1 Differences From 1.2
          4. 
+       
        4. Version 1.0 Differences From 1.1
          5. 
+     
        
+   
        6. 
+ 
      
+ 
      
+ 
      Written by Reid Spencer
+ 
      
+ 
      
+ 
+ 
       Abstract 
      
+ 
+ 
      
+ 
      This document describes the LLVM bytecode file format. It specifies
+ the binary encoding rules of the bytecode file format so that
+ equivalent systems can encode bytecode files correctly. The LLVM
+ bytecode representation is used to store the intermediate
+ representation on disk in compacted form.
      
+ 
      The LLVM bytecode format may change in the future, but LLVM will
+ always be backwards compatible with older formats. This document will
+ only describe the most current version of the bytecode format. See Version Differences for the details on how
+ the current version is different from previous versions.
      
+ 
      
+ 
+ 
       Concepts 
      
+ 
+ 
      
+ 
      This section describes the general concepts of the bytecode file
+ format without getting into specific layout details. It is recommended
+ that you read this section thoroughly before interpreting the detailed
+ descriptions.
      
+ 
      
+ 
+ 
      Blocks 
      
+ 
      
+ 
      LLVM bytecode files consist simply of a sequence of blocks of bytes
+ using a binary encoding Each block begins with an header of two
+ unsigned integers. The first value identifies the type of block and the
+ second value provides the size of the block in bytes. The block
+ identifier is used because it is possible for entire blocks to be
+ omitted from the file if they are empty. The block identifier helps the
+ reader determine which kind of block is next in the file. Note that
+ blocks can be nested within other blocks.
      
+ 
       All blocks are variable length, and the block header specifies the
+ size of the block. All blocks begin on a byte index that is aligned to
+ an even 32-bit boundary. That is, the first block is 32-bit aligned
+ because it starts at offset 0. Each block is padded with zero fill
+ bytes to ensure that the next block also starts on a 32-bit boundary.
      
+ 
      
+ 
+ 
      Lists 
      
+ 
      
+ 
      LLVM Bytecode blocks often contain lists of things of a similar
+ type. For example, a function contains a list of instructions and a
+ function type contains a list of argument types. There are two basic
+ types of lists: length lists (llist), and null
+ terminated lists (zlist), as described below in
+ the Encoding Primitives.
      
+ 
      
+ 
+ 
      Fields 
      
+ 
      
+ 
      Fields are units of information that LLVM knows how to write atomically. Most 
+ fields have a uniform length or some kind of length indication built into their 
+ encoding. For example, a constant string (array of bytes) is written simply as 
+ the length followed by the characters. Although this is similar to a list, 
+ constant strings are treated atomically and are thus fields.
      
+ 
      Fields use a condensed bit format specific to the type of information
+ they must contain. As few bits as possible are written for each field. The
+ sections that follow will provide the details on how these fields are
+ written and how the bits are to be interpreted.
      
+ 
      
+ 
+ 
      Alignment 
      
+ 
      
+   
      To support cross-platform differences, the bytecode file is aligned on 
+   certain boundaries. This means that a small amount of padding (at most 3 
+   bytes) will be added to ensure that the next entry is aligned to a 32-bit 
+   boundary.
      
+ 
      
+ 
+ 
      Variable Bit-Rate Encoding
+ 
      
+ 
      
+ 
      Most of the values written to LLVM bytecode files are small integers. To 
+ minimize the number of bytes written for these quantities, an encoding scheme 
+ similar to UTF-8 is used to write integer data. The scheme is known as
+ variable bit rate (vbr) encoding. In this encoding, the high bit of
+ each byte is used to indicate if more bytes follow. If (byte &
+ 0x80) is non-zero in any given byte, it means there is another byte
+ immediately following that also contributes to the value. For the final
+ byte (byte & 0x80) is false (the high bit is not set). In each byte
+ only the low seven bits contribute to the value. Consequently 32-bit
+ quantities can take from one to five bytes to encode. In
+ general, smaller quantities will encode in fewer bytes, as follows:
      
+ 
      13. 
   
      
 
 
 
      
       GNU Automake2.591.9.2
       aclocal macro generator (Note 1)
     
      
 
     
      
       perl>5.6.0≥5.6.0
       Nightly tester, utilities
     
      
       CVS>1.11≥1.11
       CVS access to LLVM (Note 4)
     
      
 
 
      
       GNU Automake2.591.9.2
       aclocal macro generator (Note 1)
     
      
 
     
      
       perl>5.6.0≥5.6.0
       Nightly tester, utilities
     
      
       CVS>1.11≥1.11
       CVS access to LLVM (Note 4)
     
      
+   
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+   
+ 
      Byte #Significant BitsMaximum Value
      10-6127
      27-1316,383
      314-202,097,151
      421-27268,435,455
      528-3434,359,738,367
      635-414,398,046,511,103
      742-48562,949,953,421,311
      849-5572,057,594,037,927,935
      956-629,223,372,036,854,775,807
      1063-691,180,591,620,717,411,303,423
      
+ 
      Note that in practice, the tenth byte could only encode bit 63 since
+ the maximum quantity to use this encoding is a 64-bit integer.
      
+ 
      Signed VBR values are encoded with the standard vbr
+ encoding, but with the sign bit as the low order bit instead of the
+ high order bit. This allows small negative quantities to be encoded
+ efficiently. For example, -3
+ is encoded as "((3 << 1) | 1)" and 3 is encoded as "(3 <<
+ 1) | 0)", emitted with the standard vbr encoding above.
      
+ 
      
+ 
+ 
      Encoding Primitives 
      
+ 
      
+ 
      Each field in the bytecode format is encoded into the file using a
+ small set of primitive formats. The table below defines the encoding
+ rules for the various primitives used and gives them each a type name.
+ The type names used in the descriptions of blocks and fields in the Detailed Layoutnext section. Any type name with
+ the suffix _vbr indicates a quantity that is encoded using
+ variable bit rate encoding as described above.
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeRule
      unsignedA 32-bit unsigned integer that always occupies four 
+       consecutive bytes. The unsigned integer is encoded using LSB first 
+       ordering. That is bits 20 through 27 are in the 
+       byte with the lowest file offset (little endian).
      
+         uint24_vbrA 24-bit unsigned 
+       integer that occupies from one to four bytes using variable bit rate 
+       encoding.
      uint32_vbrA 32-bit unsigned integer that occupies from one to 
+         five bytes using variable bit rate encoding.
      uint64_vbrA 64-bit unsigned integer that occupies from one to ten 
+         bytes using variable bit rate encoding.
      int64_vbrA 64-bit signed integer that occupies from one to ten 
+         bytes using the signed variable bit rate encoding.
      charA single unsigned character encoded into one byte
      bit(n-m)A set of bit within some larger integer field. The values 
+         of n and m specify the inclusive range of bits 
+         that define the subfield. The value for m may be omitted if 
+         its the same as n.
      floatA floating point value encoded 
+         as a 32-bit IEEE value written in little-endian form.
      
+       
      doubleA floating point value encoded 
+         as a64-bit IEEE value written in little-endian form
      stringA uint32_vbr indicating the type of the
+ constant string which also includes its length, immediately followed by
+ the characters of the string. There is no terminating null byte in the
+ string.
      dataAn arbitrarily long segment of data to which
+ no interpretation is implied. This is used for constant initializers.
      
+       
      llist(x)A length list of x. This means the list is
+ encoded as an uint32_vbr providing the
+ length of the list, followed by a sequence of that many "x" items. This
+ implies that the reader should iterate the number of times provided by
+ the length.
      zlist(x)A zero-terminated list of x. This means the
+ list is encoded as a sequence of an indeterminate number of "x" items,
+ followed by an uint32_vbr terminating value.
+ This implies that none of the "x" items can have a zero value (or else
+ the list terminates).
      blockA block of data that is logically related. A
+ block is an unsigned 32-bit integer that encodes the type of the block
+ in the low 5 bits and the size of the block in the high 27 bits. The
+ length does not include the block header or any alignment bytes at the
+ end of the block. Blocks may compose other blocks. 
      
+ 
      
+ 
+ 
      Field Notation 
      
+ 
      
+ 
      In the detailed block and field descriptions that follow, a regex
+ like notation is used to describe optional and repeated fields. A very
+ limited subset of regex is used to describe these, as given in the
+ following table: 
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      CharacterMeaning
      ?The question mark indicates 0 or 1
+ occurrences of the thing preceding it.
      *The asterisk indicates 0 or more occurrences
+ of the thing preceding it.
      +The plus sign indicates 1 or more occurrences
+ of the thing preceding it.
      ()Parentheses are used for grouping.
      ,The comma separates sequential fields.
      
+ 
      So, for example, consider the following specifications:
      
+ 
      
+ 
        
+   
      1. string?
        2. 
+   
      2. (uint32_vbr,uin32_vbr)+
        3. 
+   
      3. (unsigned?,uint32_vbr)*
        4. 
+   
      4. (llist(unsigned))?
        5. 
+ 
      
+ 
      
+ 
      with the following interpretations:
      
+ 
        
+   
      1. An optional string. Matches either nothing or a single string
        2. 
+   
      2. One or more pairs of uint32_vbr.
        3. 
+   
      3. Zero or more occurrences of either an unsigned followed by a
+ uint32_vbr or just a uint32_vbr.
        4. 
+   
      4. An optional length list of unsigned values.
        5. 
+ 
      
+ 
      
+ 
+ 
      Slots 
      
+ 
      
+ 
      The bytecode format uses the notion of a "slot" to reference Types
+ and Values. Since the bytecode file is a direct representation of
+ LLVM's intermediate representation, there is a need to represent pointers in
+ the file.  Slots are used for this purpose. For example, if one has the following
+ assembly:
+ 
      
+ 
       %MyType = type { int, sbyte }
      
+ %MyVar = external global %MyType
+ 
      
+ 
      there are two definitions. The definition of %MyVar uses %MyType.
+ In the C++ IR this linkage between %MyVar and %MyType
+ is explicit through the use of C++ pointers. In bytecode, however, there's no
+ ability to store memory addresses. Instead, we compute and write out
+ slot numbers for every Type and Value written to the file.
      
+ 
      A slot number is simply an unsigned 32-bit integer encoded in the variable
+ bit rate scheme (see encoding). This ensures that
+ low slot numbers are encoded in one byte. Through various bits of magic LLVM
+ attempts to always keep the slot numbers low. The first attempt is to associate
+ slot numbers with their "type plane". That is, Values of the same type
+ are written to the bytecode file in a list (sequentially). Their order in 
+ that list determines their slot number. This means that slot #1 doesn't mean
+ anything unless you also specify for which type you want slot #1. Types are
+ always written to the file first (in the Global Type 
+ Pool) and in such a way that both forward and backward references of the 
+ types can often be resolved with a single pass through the type pool. 
      
+ 
      Slot numbers are also kept small by rearranging their order. Because
+ of the structure of LLVM, certain values are much more likely to be used
+ frequently in the body of a function. For this reason, a compaction table is
+ provided in the body of a function if its use would make the function body 
+ smaller.  Suppose you have a function body that uses just the types "int*" and
+ "{double}" but uses them thousands of time. Its worthwhile to ensure that the 
+ slot number for these types are low so they can be encoded in a single byte 
+ (via vbr). This is exactly what the compaction table does.
      
+ 
      In summary then, a slot number can be though of as just a vbr encoded index 
+ into a list of Type* or Value*. To keep slot numbers low, Value* are indexed by
+ two slot numbers: the "type plane index" (type slot) and the "value index"
+ (value slot).
      
+ 
      
+ 
+ 
       General Structure 
      
+ 
+ 
      
+ 
      This section provides the general structure of the LLVM bytecode
+ file format. The bytecode file format requires blocks to be in a
+ certain order and nested in a particular way so that an LLVM module can
+ be constructed efficiently from the contents of the file. This ordering
+ defines a general structure for bytecode files as shown below. The
+ table below shows the order in which all block types may appear. Please
+ note that some of the blocks are optional and some may be repeated. The
+ structure is fairly loose because optional blocks, if empty, are
+ completely omitted from the file.
      
+ 
+   
+     
+       
+       
+       
+       
+       
+       
+       
+     
+     
+       
+       
+       
+       
+       
+       
+       
+     
+     
+       
+       
+       
+       
+       
+       
+       
+     
+     
+       
+       
+       
+       
+       
+       
+       
+     
+     
+       
+       
+       
+       
+       
+       
+       
+     
+     
+       
+       
+       
+       
+       
+       
+       
+     
+     
+       
+       
+       
+       
+       
+       
+       
+     
+     
+       
+       
+       
+       
+       
+       
+       
+     
+     
+       
+       
+       
+       
+       
+       
+       
+     
+     
+       
+       
+       
+       
+       
+       
+       
+     
+     
+       
+       
+       
+       
+       
+       
+       
+     
+     
+       
+       
+       
+       
+       
+       
+       
+     
+   
+ 
      IDParentOptional?Repeated?LevelBlock TypeDescription
      N/AFileNoNo0SignatureThis contains the file signature (magic
+ number) that identifies the file as LLVM bytecode.
      0x01FileNoNo0ModuleThis is the top level block in a bytecode
+ file. It contains all the other blocks. 
      0x06ModuleNoNo1   Global Type PoolThis block contains all the global (module)
+ level types.
      0x05ModuleNoNo1   Module Globals InfoThis block contains the type, constness, and
+ linkage for each of the global variables in the module. It also
+ contains the type of the functions and the constant initializers.
      0x03ModuleYesNo1   Module Constant PoolThis block contains all the global constants
+ except function arguments, global values and constant strings.
      0x02ModuleYesYes1   Function Definitions*One function block is written for each
+ function in the module. The function block contains the instructions,
+ compaction table, type constant pool, and symbol table for the function.
      0x03FunctionYesNo2      Function Constant PoolAny constants (including types) used solely
+ within the function are emitted here in the function constant pool. 
      0x08FunctionYesNo2      Compaction TableThis table reduces bytecode size by providing
+ a funtion-local mapping of type and value slot numbers to their global
+ slot numbers
      0x07FunctionNoNo2      Instruction ListThis block contains all the instructions of
+ the function. The basic blocks are inferred by terminating
+ instructions. 
      0x04FunctionYesNo2      Function Symbol TableThis symbol table provides the names for the
+ function specific values used (basic block labels mostly).
      0x04ModuleYesNo1   Module Symbol TableThis symbol table provides the names for the
+ various entries in the file that are not function specific (global
+ vars, and functions mostly).
      
+ 
      Use the links in the table for details about the contents of each of
+ the block types.
      
+ 
      
+ 
+ 
       Block Definitions 
      
+ 
+ 
      
+ 
      This section provides the detailed layout of the individual block
+ types in the LLVM bytecode file format. 
      
+ 
      
+ 
+ 
      Signature Block 
      
+ 
      
+ 
      The signature occurs in every LLVM bytecode file and is always first.
+ It simply provides a few bytes of data to identify the file as being an LLVM
+ bytecode file. This block is always four bytes in length and differs from the
+ other blocks because there is no identifier and no block length at the start
+ of the block. Essentially, this block is just the "magic number" for the file.
+ 
      
+ 
      There are two types of signatures for LLVM bytecode: uncompressed and
+ compressed as shown in the table below. 
      
+ 
+   
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+   
+ 
      TypeUncompressedCompressed
      charConstant "l" (0x6C)Constant "l" (0x6C)
      charConstant "l" (0x6C)Constant "l" (0x6C)
      charConstant "v" (0x76)Constant "v" (0x76)
      charConstant "m" (0x6D)Constant "c" (0x63)
      charN/A'0'=null,'1'=gzip,'2'=bzip2
      
+ 
      In other words, the uncompressed signature is just the characters 'llvm'
+ while the compressed signature is the characters 'llvc' followed by an ascii
+ digit ('0', '1', or '2') that indicates the kind of compression used. A value of
+ '0' indicates that null compression was used. This can happen when compression
+ was requested on a platform that wasn't configured for gzip or bzip2. A value of
+ '1' means that the rest of the file is compressed using the gzip algorithm and
+ should be uncompressed before interpretation. A value of '2' means that the rest
+ of the file is compressed using the bzip2 algorithm and should be uncompressed
+ before interpretation. In all cases, the data resulting from uncompression
+ should be interpreted as if it occurred immediately after the 'llvm'
+ signature (i.e. the uncompressed data begins with the 
+ Module Block
      
+ 
      NOTE: As of LLVM 1.4, all bytecode files produced by the LLVM tools
+ are compressed by default. To disable compression, pass the 
+ --disable-compression option to the tool, if it supports it.
+ 
      
+ 
+ 
      Module Block 
      
+ 
      
+ 
      The module block contains a small pre-amble and all the other blocks in
+ the file. The table below shows the structure of the module block. Note that it
+ only provides the module identifier, size of the module block, and the format
+ information. Everything else is contained in other blocks, described in other
+ sections.
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      unsigned
      		Module Block Identifier
+           (0x01)
      unsignedModule Block Size
      uint32_vbrFormat Information
      blockGlobal Type Pool
      blockModule Globals Info
      blockModule Constant Pool
      block*Function Definitions
      blockModule Symbol Table
      
+ 
      
+ 
+ 
+ 
      Module Block Header
      
+ 
      
+   
      The block header for the module block uses a longer format than the other
+   blocks in a bytecode file. Specifically, instead of encoding the type and size
+   of the block into a 32-bit integer with 5-bits for type and 27-bits for size,
+   the module block header uses two 32-bit unsigned values, one for type, and one
+   for size. While the 227 byte limit on block size is sufficient for the blocks
+   contained in the module, it isn't sufficient for the module block itself
+   because we want to ensure that bytecode files as large as 232 bytes
+   are possible. For this reason, the module block (and only the module block)
+   uses a long format header.
      
+ 
      
+ 
+ 
+ 
      Format Information
      
+ 
      
+ 
      The format information field is encoded into a uint32_vbr
+ as shown in the following table.
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeDescription
      bit(0)Target is big endian?
      bit(1)On target pointers are 64-bit?
      bit(2)Target has no endianess?
      bit(3)Target has no pointer size?
      bit(4-31)Bytecode format version
      
+ 
      
+ Of particular note, the bytecode format number is simply a 28-bit
+ monotonically increase integer that identifies the version of the bytecode
+ format (which is not directly related to the LLVM release number). The
+ bytecode versions defined so far are (note that this document only
+ describes the latest version, 1.3):
      
+ 
        
+   
      • #0: LLVM 1.0 & 1.1
        • 
+   
      • #1: LLVM 1.2
        • 
+   
      • #2: LLVM 1.2.5 (not released)
        • 
+   
      • #3: LLVM 1.3
        
+   
        • 
+ 
      
+ 
      Note that we plan to eventually expand the target description
+ capabilities
+ of bytecode files to target
+ triples.
+ 
      
+ 
      
+ 
+ 
      Global Type Pool 
      
+ 
      
+ 
      The global type pool consists of type definitions. Their order of appearance
+ in the file determines their type slot number (0 based). Slot numbers are
+ used to replace pointers in the intermediate representation. Each slot number 
+ uniquely identifies one entry in a type plane (a collection of values of the
+ same type).  Since all values have types and are associated with the order in 
+ which the type pool is written, the global type pool must be written 
+ as the first block of a module. If it is not, attempts to read the file will
+ fail because both forward and backward type resolution will not be possible.
      
+ 
      The type pool is simply a list of type definitions, as shown in the
+ table below.
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      blockType Pool Identifier (0x06) + Size
      
+       
      llist(type)A length list of type definitions.
      
+ 
      
+ 
+ 
      Type Definitions
      
+ 
      
+ 
      Types in the type pool are defined using a different format for each kind
+ of type, as given in the following sections.
      
+ 
      Primitive Types
      
+ 
      The primitive types encompass the basic integer and floating point
+ types. They are encoded simply as their TypeID.
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeDescription
      uint24_vbrType ID for the primitive types (values 1 to
+ 11) 1
      
+ Notes:
+ 
        
+   
      1. The values for the Type IDs for the primitive types are provided
+ by the definition of the llvm::Type::TypeID enumeration
+ in include/llvm/Type.h. The enumeration gives the
+ following mapping:
+     
          
+       
        1. bool
          2. 
+       
        2. ubyte
          3. 
+       
        3. sbyte
          4. 
+       
        4. ushort
          5. 
+       
        5. short
          6. 
+       
        6. uint
          7. 
+       
        7. int
          8. 
+       
        8. ulong
          9. 
+       
        9. long
          10. 
+       
        10. float
          11. 
+       
        11. double
          12. 
+     
        
+   
        2. 
+ 
      
+ 
      Function Types
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeDescription
      uint24_vbrType ID for function types (13)
      uint24_vbrType slot number of function's return type.
      llist(uint24_vbr)Type slot number of each argument's type.
      uint32_vbr?Value 0 if this is a varargs function,
+ missing otherwise.
      
+ 
      Structure Types
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeDescription
      uint24_vbrType ID for structure types (14)
      zlist(uint24_vbr)Slot number of each of the element's fields.
      
+ 
      Array Types
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeDescription
      uint24_vbrType ID for Array Types (15)
      uint24_vbrType slot number of array's element type.
      uint32_vbrThe number of elements in the array.
      
+ 
      Pointer Types
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeDescription
      uint24_vbrType ID For Pointer Types (16)
      uint24_vbrType slot number of pointer's element type.
      
+ 
      Opaque Types
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeDescription
      uint24_vbrType ID For Opaque Types (17)
      
+ 
      Packed Types
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeDescription
      uint24_vbrType ID for Packed Types (18)
      uint24_vbrSlot number of packed vector's element type.
      uint32_vbrThe number of elements in the packed vector.
      
+ 
      
+ 
+ 
      Module Global Info
+ 
      
+ 
      
+ 
      The module global info block contains the definitions of all global
+ variables including their initializers and the declaration of
+ all functions. The format is shown in the table below:
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      blockModule global info identifier (0x05) + size
      
+       
      zlist(globalvar)A zero terminated list of global var
+ definitions occurring in the module.
      zlist(funcfield)A zero terminated list of function definitions
+ occurring in the module.
      llist(string)
      
+             		A length list
+ of strings that specify the names of the libraries that this module
+ depends upon.
      
+       
      string
      
+             		The target
+ triple for the module (blank means no target triple specified, i.e. a
+ platform independent module).
      
+       
      
+ 
      
+ 
+ 
+ 
      Global Variable Field
+ 
      
+ 
      
+ 
      Global variables are written using an uint32_vbr
+ that encodes information about the global variable and a list of the
+ constant initializers for the global var, if any.
      
+ 
      The table below provides the bit layout of the first uint32_vbr that describes the global variable.
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeDescription
      bit(0)Is constant?
      bit(1)Has initializer? Note that this bit
+ determines whether the constant initializer field (described below)
+ follows. 
      bit(2-4)Linkage type: 0=External, 1=Weak,
+ 2=Appending, 3=Internal, 4=LinkOnce
      bit(5-31)Type slot number of type for the global variable.
      
+ 
      The table below provides the format of the constant initializers for
+ the global variable field, if it has one.
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeDescription
      (zlist(uint32_vbr))?
+       An optional zero-terminated list of value slot
+ numbers of the global variable's constant initializer.
      
+ 
      
+ 
+ 
+ 
      Function Field
+ 
      
+ 
      
+ 
      Functions are written using an uint32_vbr
+ that encodes information about the function and a set of flags.
      
+ 
+ 
      The table below provides the bit layout of the uint32_vbr that describes the function.
      
+ 
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeDescription
      bit(0-3)Reserved for future use.  Currently set to 0001.
      bit(4)If this bit is set to 1, the indicated function is
+       external, and there is no Function Definiton
+       Block in the bytecode file for the function.
      bit(5-)Type slot number of type for the function.
      
+ 
+ 
      
+ 
+ 
+ 
      Constant Pool 
      
+ 
      
+ 
      A constant pool defines as set of constant values. There are
+ actually two types of constant pool blocks: one for modules and one for
+ functions. For modules, the block begins with the constant strings
+ encountered anywhere in the module. For functions, the block begins
+ with types only encountered in the function. In both cases the header
+ is identical. The tables that follow, show the header, module constant
+ pool preamble, function constant pool preamble, and the part common to
+ both function and module constant pools.
      
+ 
      Common Block Header
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      blockConstant pool identifier (0x03) + size
      
+       
      
+ 
      Module Constant Pool Preamble (constant strings)
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      uint32_vbrThe number of constant strings that follow.
      uint32_vbrZero. This identifies the following "plane"
+ as containing the constant strings. This is needed to identify it
+ uniquely from other constant planes that follow. 
      uint24_vbr+Type slot number of the constant string's type.
+ Note that the constant string's type implicitly defines the length of
+ the string. 
      
+ 
      Function Constant Pool Preamble (function types)
      
+ 
      The structure of the types for functions is identical to the Global Type Pool. Please refer to that section
+ for the details. 
      
+ 
      Common Part (other constants)
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      uint32_vbrNumber of entries in this type plane.
      uint24_vbrType slot number of this plane.
      constant+The definition of a constant (see below).
      
+ 
      
+ 
+ 
      Constant Field
      
+ 
      
+ 
      Constants come in many shapes and flavors. The sections that follow
+ define the format for each of them. All constants start with a uint32_vbr encoded integer that provides the
+ number of operands for the constant. For primitive, structure, and
+ array constants, this will always be zero since those types of
+ constants have no operands. In this case, we have the following field
+ definitions:
      
+ 
        
+   
      • Bool. This is written as an uint32_vbr
+ of value 1U or 0U.
        • 
+   
      • Signed Integers (sbyte,short,int,long). These are written
+ as an int64_vbr with the corresponding value.
        • 
+   
      • Unsigned Integers (ubyte,ushort,uint,ulong). These are
+ written as an uint64_vbr with the
+ corresponding value. 
        • 
+   
      • Floating Point. Both the float and double types are
+ written literally in binary format.
        • 
+   
      • Arrays. Arrays are written simply as a list of uint32_vbr encoded value slot numbers to the constant
+ element values.
        • 
+   
      • Structures. Structures are written simply as a list of uint32_vbr encoded value slot numbers to the constant
+ field values of the structure.
        • 
+ 
      
+ 
+ 
      When the number of operands to the constant is one, we have an 'undef' value
+ of the specified type.
      
+ 
+ 
      When the number of operands to the constant is greater than one, we have a
+ constant expression and its field format is provided in the table below, and the
+ number is equal to the number of operands+1.
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      uint32_vbrOp code of the instruction for the constant
+ expression.
      uint32_vbrThe value slot number of the constant value for an
+ operand.1
      uint24_vbrThe type slot number for the type of the constant
+ value for an operand.1
      
+ Notes:
+ 
        
+   
      1. Both these fields are repeatable but only in pairs.
        2. 
+ 
      
+ 
      
+ 
+ 
      Function Definition
      
+ 
      
+ 
      Function definitions contain the linkage, constant pool or
+ compaction table, instruction list, and symbol table for a function.
+ The following table shows the structure of a function definition.
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      block
      
+             		Function definition block identifier (0x02) +
+ size
      
+       
      uint32_vbrThe linkage type of the function: 0=External,
+ 1=Weak, 2=Appending, 3=Internal, 4=LinkOnce1
      blockThe constant pool
+ block for this function.2
      blockThe compaction
+ table block for the function.2
      blockThe instruction
+ list for the function.
      blockThe function's symbol
+ table containing only those symbols pertinent to the function
+ (mostly block labels).
      
+ Notes:
+ 
        
+   
      1. Note that if the linkage type is "External" then none of the
+ other fields will be present as the function is defined elsewhere.
        2. 
+   
      2. Note that only one of the constant pool or compaction table will
+ be written. Compaction tables are only written if they will actually
+ save bytecode space. If not, then a regular constant pool is written.
        3. 
+ 
      
+ 
      
+ 
+ 
      Compaction Table
+ 
      
+ 
      
+ 
      Compaction tables are part of a function definition. They are merely
+ a device for reducing the size of bytecode files. The size of a
+ bytecode file is dependent on the values of the slot numbers
+ used because larger values use more bytes in the variable bit rate
+ encoding scheme. Furthermore, the compressed instruction format
+ reserves only six bits for the type of the instruction. In large
+ modules, declaring hundreds or thousands of types, the values of the
+ slot numbers can be quite large. However, functions may use only a
+ small fraction of the global types. In such cases a compaction table is
+ created that maps the global type and value slot numbers to smaller
+ values used by a function. Functions will contain either a
+ function-specific constant pool or a compaction table but not
+ both. Compaction tables have the format shown in the table below.
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      uint32_vbrThe number of types that follow
      uint24_vbr+The type slot number in the global types of
+ the type that will be referenced in the function with the index of this
+ entry in the compaction table.
      type_lenAn encoding of the type and number of values
+ that follow. This field's encoding varies depending on the size of the
+ type plane. See Type and Length for further
+ details.
      uint32_vbr+The value slot number in the global values
+ that will be referenced in the function with the index of this entry in
+ the compaction table.
      
+ 
      
+ 
+ 
      Type and Length
      
+ 
      
+ 
      The type and length of a compaction table type plane is encoded
+ differently depending on the length of the plane. For planes of length
+ 1 or 2, the length is encoded into bits 0 and 1 of a uint32_vbr and the type is encoded into bits
+ 2-31. Because type numbers are often small, this often saves an extra
+ byte per plane. If the length of the plane is greater than 2 then the
+ encoding uses a uint32_vbr for each of the
+ length and type, in that order.
      
+ 
      
+ 
+ 
      Instruction List
      
+ 
      
+ 
      The instructions in a function are written as a simple list. Basic
+ blocks are inferred by the terminating instruction types. The format of
+ the block is given in the following table.
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      block
      
+             		Instruction list identifier (0x07) + size
      
+       
      instruction+An instruction. Instructions have a variety
+ of formats. See Instructions for details.
      
+ 
      
+ 
+ 
      Instructions
      
+ 
      
+ 
      For brevity, instructions are written in one of four formats,
+ depending on the number of operands to the instruction. Each
+ instruction begins with a uint32_vbr that
+ encodes the type of the instruction as well as other things. The tables
+ that follow describe the format of this first part of each instruction.
      
+ 
      Instruction Format 0
      
+ 
      This format is used for a few instructions that can't easily be
+ shortened because they have large numbers of operands (e.g. PHI Node or
+ getelementptr). Each of the opcode, type, and operand fields is found in
+ successive fields.
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      uint32_vbrSpecifies the opcode of the instruction. Note
+ that for compatibility with the other instruction formats, the opcode
+ is shifted left by 2 bits. Bits 0 and 1 must have value zero for this
+ format.
      uint24_vbrProvides the type slot number of the result type of
+         the instruction.
      uint32_vbrThe number of operands that follow.
      uint32_vbr+The slot number of the value(s) for the operand(s).
+         1
      
+ Notes:
+ 
        
+   
      1. Note that if the instruction is a getelementptr and the type of
+ the operand is a sequential type (array or pointer) then the slot
+ number is shifted up two bits and the low order bits will encode the
+ type of index used, as follows: 0=uint, 1=int, 2=ulong, 3=long.
        2. 
+ 
      
+ 
      Instruction Format 1
      
+ 
      This format encodes the opcode, type and a single operand into a
+ single uint32_vbr as follows:
      
+ 
+   
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+   
+ 
      BitsTypeField Description
      0-1constant "1"These two bits must be the value 1 which identifies 
+         this as an instruction of format 1.
      2-7opcodeSpecifies the opcode of the instruction. Note that 
+         the maximum opcode value is 63.
      8-19unsignedSpecifies the slot number of the type for this 
+         instruction. Maximum slot number is 212-1=4095.
      20-31unsignedSpecifies the slot number of the value for the 
+         first operand. Maximum slot number is 212-1=4095. Note that 
+         the value 212-1 denotes zero operands.
      
+ 
      Instruction Format 2
      
+ 
      This format encodes the opcode, type and two operands into a single uint32_vbr as follows:
      
+ 
+   
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+   
+ 
      BitsTypeField Description
      0-1constant "2"These two bits must be the value 2 which identifies 
+         this as an instruction of format 2.
      2-7opcodeSpecifies the opcode of the instruction. Note that 
+         the maximum opcode value is 63.
      8-15unsignedSpecifies the slot number of the type for this 
+         instruction. Maximum slot number is 28-1=255.
      16-23unsignedSpecifies the slot number of the value for the first 
+         operand. Maximum slot number is 28-1=255.
      24-31unsignedSpecifies the slot number of the value for the second 
+         operand. Maximum slot number is 28-1=255.
      
+ 
      Instruction Format 3
      
+ 
      This format encodes the opcode, type and three operands into a
+ single uint32_vbr as follows:
      
+ 
+   
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+   
+ 
      BitsTypeField Description
      0-1constant "3"These two bits must be the value 3 which identifies 
+         this as an instruction of format 3.
      2-7opcodeSpecifies the opcode of the instruction. Note that 
+         the maximum opcode value is 63.
      8-13unsignedSpecifies the slot number of the type for this 
+         instruction. Maximum slot number is 26-1=63.
      14-19unsignedSpecifies the slot number of the value for the first 
+         operand. Maximum slot number is 26-1=63.
      20-25unsignedSpecifies the slot number of the value for the second
+         operand. Maximum slot number is 26-1=63.
      26-31unsignedSpecifies the slot number of the value for the third
+         operand. Maximum slot number is 26-1=63.
      
+ 
      
+ 
+ 
+ 
      Instruction Opcodes
      
+ 
      
+   
      Instructions encode an opcode that identifies the kind of instruction.
+   Opcodes are an enumerated integer value. The specific values used depend on
+   the version of LLVM you're using. The opcode values are defined in the
+   
+   include/llvm/Instruction.def file. You should check there for the
+   most recent definitions. The table below provides the opcodes defined as of
+   the writing of this document. The table associates each opcode mnemonic with
+   its enumeration value and the bytecode and LLVM version numbers in which the
+   opcode was introduced.
      
+   
+     
+       
+         
+         
+         
+         
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+       
+     
+   
      OpcodeNumberBytecode VersionLLVM Version
      Terminator Instructions
      Ret111.0
      Br211.0
      Switch311.0
      Invoke411.0
      Unwind511.0
      Unreachable611.4
      Binary Operators
      Add711.0
      Sub811.0
      Mul911.0
      Div1011.0
      Rem1111.0
      Logical Operators
      And1211.0
      Or1311.0
      Xor1411.0
      Binary Comparison Operators
      SetEQ1511.0
      SetNE1611.0
      SetLE1711.0
      SetGE1811.0
      SetLT1911.0
      SetGT2011.0
      Memory Operators
      Malloc2111.0
      Free2211.0
      Alloca2311.0
      Load2411.0
      Store2511.0
      GetElementPtr2611.0
      Other Operators
      PHI2711.0
      Cast2811.0
      Call2911.0
      Shl3011.0
      Shr3111.0
      VANext3211.0
      VAArg3311.0
      Select3421.2
      UserOp13511.0
      UserOp23611.0
      
+ 
      
+ 
+ 
+ 
      Symbol Table 
      
+ 
      
+ 
      A symbol table can be put out in conjunction with a module or a function. A
+ symbol table has a list of name/type associations followed by a list of
+ name/value associations. The name/value associations are organized into "type
+ planes" so that all values of a common type are listed together.  Each type 
+ plane starts with the number of entries in the plane and the type slot number
+ for all the values in that plane (so the type can be looked up in the global 
+ type pool). For each entry in a type plane, the slot number of the value and 
+ the name associated with that value are written. The format is given in the 
+ table below. 
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      block
      
+             		Symbol Table Identifier (0x04)
      llist(type_entry)A length list of symbol table entries for
+         Types
+       
      llist(symtab_plane)A length list of "type planes" of symbol table
+         entries for Values
      
+ 
      
+ 
+ 
+ 
       Symbol Table Type
+ Entry
+ 
      
+ 
      
+ 
      A symbol table type entry associates a name with a type. The name is provided
+ simply as an array of chars. The type is provided as a type slot number (index)
+ into the global type pool. The format is given in the following table:
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      uint24_vbrType slot number of the type being given a
+         name relative to the global type pool.
+       
      uint32_vbrLength of the character array that follows.
      char+The characters of the name.
      
+ 
      
+ 
+ 
       Symbol Table
+ Plane
+ 
      
+ 
      
+ 
      A symbol table plane provides the symbol table entries for all
+ values of a common type. The encoding is given in the following table:
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      uint32_vbrNumber of entries in this plane.
      uint32_vbrType slot number of type for all values in this plane..
      value_entry+The symbol table entries for to associate values with
+         names.
      
+ 
      
+ 
+ 
      Symbol Table Value
+ Entry
+ 
      
+ 
      
+ 
      A symbol table value entry provides the assocation between a value and the
+ name given to the value. The value is referenced by its slot number. The
+ format is given in the following table:
      
+ 
+   
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      TypeField Description
      uint24_vbrValue slot number of the value being given a name.
+       
      uint32_vbrLength of the character array that follows.
      char+The characters of the name.
      
+ 
      
+ 
+ 
+ 
       Version Differences
+ 
      
+ 
+ 
      
+ 
      This section describes the differences in the Bytecode Format across
+ LLVM
+ versions. The versions are listed in reverse order because it assumes
+ the current version is as documented in the previous sections. Each
+ section here
+ describes the differences between that version and the one that follows.
+ 
      
+ 
      
+ 
+ 
+ 
      Version 1.3 Differences From 
+     1.4
      
+ 
+ 
+ 
      Unreachable Instruction
      
+ 
      
+   
      The LLVM Unreachable instruction
+   was added in version 1.4 of LLVM.  This caused all instruction numbers after
+   it to shift down by one.
      
+ 
      
+ 
+ 
      Function Flags
      
+ 
      
+   
      LLVM bytecode versions prior to 1.4 did not include the 5 bit offset 
+      in the function list in the Module Global Info block.
      
+ 
      
+ 
+ 
      Function Flags
      
+ 
      
+   
      LLVM bytecode versions prior to 1.4 did not include the 'undef' constant
+      value, which affects the encoding of Constant
+      Fields.
      
+ 
      
+ 
+ 
+ 
+ 
+ 
      Version 1.2 Differences
+ From 1.3
      
+ 
+ 
+ 
      Type Derives From Value
      
+ 
      
+ 
      In version 1.2, the Type class in the LLVM IR derives from the Value
+ class. This is not the case in version 1.3. Consequently, in version
+ 1.2 the notion of a "Type Type" was used to write out values that were
+ Types. The types always occuped plane 12 (corresponding to the
+ TypeTyID) of any type planed set of values. In 1.3 this representation
+ is not convenient because the TypeTyID (12) is not present and its
+ value is now used for LabelTyID. Consequently, the data structures
+ written that involve types do so by writing all the types first and
+ then each of the value planes according to those types. In version 1.2,
+ the types would have been written intermingled with the values.
      
+ 
      
+ 
+ 
      Restricted getelementptr Types
      
+ 
      
+ 
      In version 1.2, the getelementptr instruction required a ubyte type
+ index for accessing a structure field and a long type index for
+ accessing an array element. Consequently, it was only possible to
+ access structures of 255 or fewer elements. Starting in version 1.3,
+ this restriction was lifted. Structures must now be indexed with uint
+ constants. Arrays may now be indexed with int, uint, long, or ulong
+ typed values. The consequence of this was that the bytecode format had
+ to change in order to accommodate the larger range of structure indices.
      
+ 
      
+ 
+ 
      Short Block Headers
      
+ 
      
+ 
      In version 1.2, block headers were always 8 bytes being comprised of
+ both an unsigned integer type and an unsigned integer size. For very
+ small modules, these block headers turn out to be a large fraction of
+ the total bytecode file size. In an attempt to make these small files
+ smaller, the type and size information was encoded into a single
+ unsigned integer (4 bytes) comprised of 5 bits for the block type
+ (maximum 31 block types) and 27 bits for the block size (max
+ ~134MBytes). These limits seemed sufficient for any blocks or sizes
+ forseen in the future. Note that the module block, which encloses all
+ the other blocks is still written as 8 bytes since bytecode files
+ larger than 134MBytes might be possible.
      
+ 
      
+ 
+ 
      Dependent Libraries and Target Triples
      
+ 
      
+ 
      In version 1.2, the bytecode format does not store module's target
+ triple or dependent. These fields have been added to the end of the module global info block. The purpose of these
+ fields is to allow a front end compiler to specifiy that the generated
+ module is specific to a particular target triple (operating
+ system/manufacturer/processor) which makes it non-portable; and to
+ allow front end compilers to specify the list of libraries that the
+ module depends on for successful linking.
      
+ 
      
+ 
+ 
      Types Restricted to 24-bits
      
+ 
      
+ 
      In version 1.2, type slot identifiers were written as 32-bit VBR
+ quantities. In 1.3 this has been reduced to 24-bits in order to ensure
+ that it is not possible to overflow the type field of a global variable
+ definition. 24-bits for type slot numbers is deemed sufficient for any
+ practical use of LLVM.
      
+ 
      
+ 
+ 
+ 
      Version 1.1 Differences
+ From 1.2 
      
+ 
+ 
      Explicit Primitive Zeros
      
+ 
      
+ 
      In version 1.1, the zero value for primitives was explicitly encoded
+ into the bytecode format. Since these zero values are constant values
+ in the LLVM IR and never change, there is no reason to explicitly
+ encode them. This explicit encoding was removed in version 1.2.
      
+ 
      
+ 
+ 
      Inconsistent Module Global Info
      
+ 
      
+ 
      In version 1.1, the Module Global Info block was not aligned causing
+ the next block to be read in on an unaligned boundary. This problem was
+ corrected in version 1.2.
      
+ 
      
+ 
      
+ 
      
+ 
+ 
      Version 1.0 Differences
+ From 1.1
      
+ 
      
+ 
      None. Version 1.0 and 1.1 bytecode formats are identical.
      
+ 
      
+ 
+ 
      
+ 
       Valid CSS!
+ Valid HTML 4.01!
+ Reid Spencer and Chris Lattner
      
+ The LLVM Compiler Infrastructure
      
+ Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 


Index: llvm-www/releases/1.4/docs/CFEBuildInstrs.html
diff -c /dev/null llvm-www/releases/1.4/docs/CFEBuildInstrs.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/CFEBuildInstrs.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,339 ----
+ 
+ 
+ 
+   
+   
+   Bootstrapping the LLVM C/C++ Front-End
+ 
+ 
+ 
+ 
      
+   Bootstrapping the LLVM C/C++ Front-End
+ 
      
+ 
+ 
        
+   
      1. A Cautionary Note
+     
+   
        2. 
+   
      2. Instructions
        3. 
+   
      3. License Information
        4. 
+ 
      
+ 
+ 
          
+   
      Written by Brian R. Gaeke and 
+      Chris Lattner
      
+ 
      
+ 
+ 
+ 
      
+   A Cautionary Note
+ 
      
+ 
+ 
+ 
      
+ 
      This document is intended to explain the process of building the
+ LLVM C/C++ front-end, based on GCC 3.4, from its source code. You
+ would have to do this, for example, if you are porting LLVM to a new
+ architecture or operating system.
      
+ 
+ 
      NOTE: This is currently a somewhat fragile, error-prone
+ process, and you should only try to do it if:
      
+ 
+ 
        
+   
      1. you really, really, really can't use the binaries we distribute
        2. 
+   
      2. you are an elite GCC hacker.
        3. 
+ 
      
+ 
+ 
      We welcome patches to help make this process simpler.
      
+ 
      
+ 
+ 
+ 
      
+   Building under Cygwin
+ 
      
+ 
+ 
+ 
      
+ 
      If you are building LLVM and the GCC front-end under Cygwin, please note that
+ the LLVM and GCC makefiles do not correctly handle spaces in paths.  To deal
+ with this issue, make sure that your LLVM and GCC source and build trees are 
+ located in a top-level directory (like /cygdrive/c/llvm and 
+ /cygdrive/c/llvm-cfrontend), not in a directory that contains a space
+ (which includes your "home directory", because it lives under the "Documents 
+ and Settings" directory).  We welcome patches to fix this issue.
+ 
      
+ 
      
+ 
+ 
+ 
      
+   Building under AIX
+ 
      
+ 
+ 
+ 
      
+ 
      If you are building LLVM and the GCC front-end under AIX, do NOT use GNU
+ Binutils.  They are not stable under AIX and may produce incorrect and/or
+ invalid code.  Instead, use the system assembler and linker.
+ 
      
+ 
      
+ 
+ 
+ 
      
+   Instructions
+ 
      
+ 
+ 
+ 
      
+ 
      
+ 
        
+ 
      1. Configure and build the LLVM libraries and tools using:
        
+ 
        +  % cd llvm
+  % ./configure --prefix=/some/path/you/can/install/to [options...]
+  % gmake tools-only
+ 
        
+   
        This will build all of the LLVM tools and libraries. The --prefix 
+   option defaults to /usr/local (per configure standards) but unless you are a 
+   system administrator, you probably won't be able to install LLVM there because
+   of permissions. Specify a path into which LLVM can be installed (e.g.
+   --prefix=/home/user/llvm).
        
+ 
        2. 
+ 
+ 
      2. Add the directory containing the tools to your PATH.
        
+ 
        +  % set path = ( `cd llvm/Debug/bin && pwd` $path )
+ 
        3. 
+ 
+ 
      3. Unpack the C/C++ front-end source into cfrontend/src.
        4. 
+ 
+ 
      4. Make "build" and "install" directories as siblings of the "src" tree.
        
+ 
        +  % pwd
+  /usr/local/example/cfrontend/src
+  % cd ..
+  % mkdir build install
+  % set CFEINSTALL = `pwd`/install
+ 
        5. 
+ 
+ 
+ 
      5. Configure, build, and install the GCC front-end:
        
+ 
+ 
        
+ Linux/x86:
        
+ MacOS X/PowerPC (requires dlcompat library):
        
+ AIX/PowerPC:
+ 
        
+ 
+ 
        +  % cd build
+  % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
+    --disable-shared --enable-languages=c,c++
+  % gmake
+  % setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc 
+  % gmake all; gmake install
+ 
        
+ 
+ 
        Cygwin/x86:
        
+ 
+ 
        +  % cd build
+  % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
+    --disable-shared --enable-languages=c,c++ --disable-c-mbchar
+  % gmake
+  % setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc 
+  % gmake all; gmake install
+ 
        
+ 
+ 
        Solaris/SPARC:
        
+ 
+ 
        
+ For Solaris/SPARC, LLVM only supports the SPARC V9 architecture.  Therefore,
+ the configure command line should specify sparcv9, as shown below. Also,
+ note that Solaris has trouble with various wide (multibyte) character
+ functions from C as referenced from C++, so we typically configure with
+ --disable-c-mbchar (cf. Bug 206).
+ 
        
+ 
+ 
        +  % cd build
+  % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
+    --disable-shared --enable-languages=c,c++ --host=sparcv9-sun-solaris2.8 \
+    --disable-c-mbchar
+  % gmake
+  % setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc 
+  % gmake all; gmake install
+ 
        
+ 
+  
        Common Problem: You may get error messages regarding the fact
+  that LLVM does not support inline assembly. Here are two common
+  fixes:
        
+ 
+  
          
+   
        • Fix 1: If you have system header files that include
+    inline assembly, you may have to modify them to remove the inline
+    assembly and install the modified versions in
+    $CFEINSTALL/lib/gcc/target-triplet/3.4-llvm/include.
          • 
+ 
+   
        • Fix 2: If you are building the C++ front-end on a CPU we
+    haven't tried yet, you will probably have to edit the appropriate
+    version of atomicity.h under
+    src/libstdc++-v3/config/cpu/name-of-cpu/atomicity.h
+    and apply a patch so that it does not use inline assembly.
          • 
+  
        
+ 
+  
        Porting to a new architecture: If you are porting the front-end
+  to a new architecture or compiling in a configuration that we have
+  not tried previously, there are probably several changes you will have to make
+  to the GCC target to get it to work correctly.  These include:
        
+ 
+  
          
+   
        • Often targets include special assembler or linker flags which
+       gccas/gccld does not understand.  In general, these can
+       just be removed.
          • 
+   
        • LLVM currently does not support any floating point values other than 
+       32-bit and 64-bit IEEE floating point.  The primary effect of this is
+       that you may have to map "long double" onto "double".
          • 
+   
        • The profiling hooks in GCC do not apply at all to the LLVM front-end.
+       These may need to be disabled.
          • 
+   
        • No inline assembly for position independent code.  At the LLVM level,
+       everything is position independent.
          • 
+   
        • We handle .init and .fini differently.
          • 
+   
        • You may have to disable multilib support in your target.  Using multilib
+       support causes the GCC compiler driver to add a lot of "-L"
+       options to the link line, which do not relate to LLVM and confuse
+       gccld.  To disable multilibs, delete any
+       MULTILIB_OPTIONS lines from your target files.
          • 
+   
        • Did we mention that we don't support inline assembly?  You'll probably
+       have to add some fixinclude hacks to disable it in the system
+       headers.
          • 
+  
        
+ 
        6. 
+ 
+ 
      6. Go back into the LLVM source tree proper.  Rerun configure, using
+ the --with-llvmgccdir=$CFEINSTALL option to specify the path
+ to the newly built GCC front-end.
        7. 
+ 
+ 
      7. If you edited header files during the C/C++ front-end build as
+ described in "Fix 1" above, you must now copy those header files from
+ $CFEINSTALL/target-triplet/sys-include to
+ $CFEINSTALL/lib/gcc/target-triplet/3.4-llvm/include.
+ (This should be the "include" directory in the same directory as the
+ libgcc.a library, which you can find by running
+ $CFEINSTALL/bin/gcc --print-libgcc-file-name.)
        8. 
+ 
+ 
      8. Rebuild your CVS tree.  This shouldn't cause the whole thing to be
+   rebuilt, but it should build the runtime libraries.  After the tree is
+   built, install the runtime libraries into your GCC front-end build tree.
+   These are the commands you need.
        
+ 
        +  % gmake
+  % mkdir $CFEINSTALL/bytecode-libs
+  % gmake -C runtime install-bytecode
+  % setenv LLVM_LIB_SEARCH_PATH $CFEINSTALL/bytecode-libs
+ 
        9. 
+ 
+ 
      9. Optionally, build a symbol table for the newly installed runtime 
+ libraries. Although this step is optional, you are encouraged to do this as the
+ symbol tables will make a significant difference in your link times. Use 
+ the llvm-ranlib tool to do this, as follows:
        
+ 
        +  % cd $CFEINSTALL/lib
+  % llvm-ranlib libiberty.a
+  % llvm-ranlib libstdc++.a
+  % llvm-ranlib libsupc++.a
+  % cd $CFEINSTALL/lib/target-triplet/3.4-llvm
+  % llvm-ranlib libgcc.a
+  % llvm-ranlib libgcov.a
+ 
        
+ 
+ 
      10. Test the newly-installed C frontend by one or more of the
+ following means:
        
+  
          
+   
        •  compiling and running a "hello, LLVM" program in C and C++.
          • 
+   
        •  running the regression tests in llvm/test
+   
        •  running the tests found in the llvm-test CVS module
          • 
+  
        11. 
+ 
      
+ 
      
+ 
+ 
+ 
      
+   License Information
+ 
      
+ 
+ 
      
+ 
      
+ The LLVM GCC frontend is licensed to you under the GNU General Public License
+ and the GNU Lesser General Public License.  Please see the files COPYING and
+ COPYING.LIB for more details.
+ 
      
+ 
+ 
      
+ The software also has the following additional copyrights:
+ 
      
+ 
+ 
      + 
+ Copyright (c) 2003, 2004 University of Illinois at Urbana-Champaign.
+ All rights reserved.
+ 
+ Developed by:
+ 
+     LLVM Team
+ 
+     University of Illinois at Urbana-Champaign
+ 
+     http://llvm.cs.uiuc.edu
+ 
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
+ FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
+ CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE
+ SOFTWARE.
+ 
+ Copyright (c) 1994
+ Hewlett-Packard Company
+ 
+ Permission to use, copy, modify, distribute and sell this software
+ and its documentation for any purpose is hereby granted without fee,
+ provided that the above copyright notice appear in all copies and
+ that both that copyright notice and this permission notice appear
+ in supporting documentation.  Hewlett-Packard Company makes no
+ representations about the suitability of this software for any
+ purpose.  It is provided "as is" without express or implied warranty.
+ 
+ Copyright (c) 1996, 1997, 1998, 1999
+ Silicon Graphics Computer Systems, Inc.
+ 
+ Permission to use, copy, modify, distribute and sell this software
+ and its documentation for any purpose is hereby granted without fee,
+ provided that the above copyright notice appear in all copies and
+ that both that copyright notice and this permission notice appear
+ in supporting documentation.  Silicon Graphics makes no
+ representations about the suitability of this software for any
+ purpose.  It is provided "as is" without express or implied warranty.
+ 
      
+ 
      
+ 
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Brian Gaeke
      
+   LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/CodeGenerator.html
diff -c /dev/null llvm-www/releases/1.4/docs/CodeGenerator.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/CodeGenerator.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,644 ----
+ 
+ 
+ 
+   The LLVM Target-Independent Code Generator
+   
+ 
+ 
+ 
+ 
      
+   The LLVM Target-Independent Code Generator
+ 
      
+ 
+ 
        
+   
      1. Introduction
+     
+   
        2. 
+   
      2. Target description classes
+     
+   
        3. 
+   
      3. Machine code description classes
+     
+   
        4. 
+   
      4. Target-independent code generation algorithms
+   
        5. 
+   
      5. Target description implementations
+     
+   
        6. 
+ 
+ 
      
+ 
+ 
      
+   
      Written by Chris Lattner
      
+ 
      
+ 
+ 
      
+   
      Warning: This is a work in progress.
      
+ 
      
+ 
+ 
+ 
      
+   Introduction
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      The LLVM target-independent code generator is a framework that provides a
+ suite of reusable components for translating the LLVM internal representation to
+ the machine code for a specified target -- either in assembly form (suitable for
+ a static compiler) or in binary machine code format (usable for a JIT compiler).
+ The LLVM target-independent code generator consists of five main components:
      
+ 
+ 
        
+ 
      1. Abstract target description interfaces which
+ capture important properties about various aspects of the machine, independently
+ of how they will be used.  These interfaces are defined in
+ include/llvm/Target/.
        2. 
+ 
+ 
      2. Classes used to represent the machine code being
+ generated for a target.  These classes are intended to be abstract enough to
+ represent the machine code for any target machine.  These classes are
+ defined in include/llvm/CodeGen/.
        3. 
+ 
+ 
      3. Target-independent algorithms used to implement
+ various phases of native code generation (register allocation, scheduling, stack
+ frame representation, etc).  This code lives in lib/CodeGen/.
        4. 
+ 
+ 
      4. Implementations of the abstract target description
+ interfaces for particular targets.  These machine descriptions make use of
+ the components provided by LLVM, and can optionally provide custom
+ target-specific passes, to build complete code generators for a specific target.
+ Target descriptions live in lib/Target/.
        5. 
+ 
+ 
      5. The target-independent JIT components.  The LLVM JIT is
+ completely target independent (it uses the TargetJITInfo structure to
+ interface for target-specific issues.  The code for the target-independent
+ JIT lives in lib/ExecutionEngine/JIT.
        6. 
+ 
+ 
      
+ 
+ 
      
+ Depending on which part of the code generator you are interested in working on,
+ different pieces of this will be useful to you.  In any case, you should be
+ familiar with the target description and machine code representation classes.  If you want to add
+ a backend for a new target, you will need to implement the
+ target description classes for your new target and understand the LLVM code representation.  If you are interested in
+ implementing a new code generation algorithm, it
+ should only depend on the target-description and machine code representation
+ classes, ensuring that it is portable.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+  Required components in the code generator
+ 
      
+ 
+ 
      
+ 
+ 
      The two pieces of the LLVM code generator are the high-level interface to the
+ code generator and the set of reusable components that can be used to build
+ target-specific backends.  The two most important interfaces (TargetMachine and TargetData classes) are the only ones that are
+ required to be defined for a backend to fit into the LLVM system, but the others
+ must be defined if the reusable code generator components are going to be
+ used.
      
+ 
+ 
      This design has two important implications.  The first is that LLVM can
+ support completely non-traditional code generation targets.  For example, the C
+ backend does not require register allocation, instruction selection, or any of
+ the other standard components provided by the system.  As such, it only
+ implements these two interfaces, and does its own thing.  Another example of a
+ code generator like this is a (purely hypothetical) backend that converts LLVM
+ to the GCC RTL form and uses GCC to emit machine code for a target.
      
+ 
+ 
      This design also implies that it is possible to design and
+ implement radically different code generators in the LLVM system that do not
+ make use of any of the built-in components.  Doing so is not recommended at all,
+ but could be required for radically different targets that do not fit into the
+ LLVM machine description model: programmable FPGAs for example.
      
+ 
+ 
      Important Note: For historical reasons, the LLVM SparcV9 code
+ generator uses almost entirely different code paths than described in this
+ document.  For this reason, there are some deprecated interfaces (such as
+ TargetRegInfo and TargetSchedInfo), which are only used by the
+ V9 backend and should not be used by any other targets.  Also, all code in the
+ lib/Target/SparcV9 directory and subdirectories should be considered
+ deprecated, and should not be used as the basis for future code generator work.
+ The SparcV9 backend is slowly being merged into the rest of the
+ target-independent code generators, but this is a low-priority process with no
+ predictable completion date.
      
+ 
+ 
      
+ 
+ 
+ 
      
+  The high-level design of the code generator
+ 
      
+ 
+ 
      
+ 
+ 
      The LLVM target-indendent code generator is designed to support efficient and
+ quality code generation for standard register-based microprocessors.  Code
+ generation in this model is divided into the following stages:
      
+ 
+ 
        
+ 
      1. Instruction Selection - Determining an efficient implementation of the
+ input LLVM code in the target instruction set.  This stage produces the initial
+ code for the program in the target instruction set, then makes use of virtual
+ registers in SSA form and physical registers that represent any required
+ register assignments due to target constraints or calling conventions.
        2. 
+ 
+ 
      2. SSA-based Machine Code Optimizations - This (optional) stage consists
+ of a series of machine-code optimizations that operate on the SSA-form produced
+ by the instruction selector.  Optimizations like modulo-scheduling, normal
+ scheduling, or peephole optimization work here.
        3. 
+ 
+ 
      3. Register Allocation - The target code is transformed from an infinite
+ virtual register file in SSA form to the concrete register file used by the
+ target.  This phase introduces spill code and eliminates all virtual register
+ references from the program.
        4. 
+ 
+ 
      4. Prolog/Epilog Code Insertion - Once the machine code has been
+ generated for the function and the amount of stack space required is known (used
+ for LLVM alloca's and spill slots), the prolog and epilog code for the function
+ can be inserted and "abstract stack location references" can be eliminated.
+ This stage is responsible for implementing optimizations like frame-pointer
+ elimination and stack packing.
        5. 
+ 
+ 
      5. Late Machine Code Optimizations - Optimizations that operate on
+ "final" machine code can go here, such as spill code scheduling and peephole
+ optimizations.
        6. 
+ 
+ 
      6. Code Emission - The final stage actually outputs the code for
+ the current function, either in the target assembler format or in machine
+ code.
        7. 
+ 
+ 
      
+ 
+ 
      
+ The code generator is based on the assumption that the instruction selector will
+ use an optimal pattern matching selector to create high-quality sequences of
+ native instructions.  Alternative code generator designs based on pattern 
+ expansion and
+ aggressive iterative peephole optimization are much slower.  This design 
+ permits efficient compilation (important for JIT environments) and
+ aggressive optimization (used when generating code offline) by allowing 
+ components of varying levels of sophisication to be used for any step of 
+ compilation.
      
+ 
+ 
      
+ In addition to these stages, target implementations can insert arbitrary
+ target-specific passes into the flow.  For example, the X86 target uses a
+ special pass to handle the 80x87 floating point stack architecture.  Other
+ targets with unusual requirements can be supported with custom passes as needed.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+  Using TableGen for target description
+ 
      
+ 
+ 
      
+ 
+ 
      The target description classes require a detailed description of the target
+ architecture.  These target descriptions often have a large amount of common
+ information (e.g., an add instruction is almost identical to a sub instruction).
+ In order to allow the maximum amount of commonality to be factored out, the LLVM
+ code generator uses the TableGen tool to
+ describe big chunks of the target machine, which allows the use of domain- and 
+ target-specific abstractions to reduce the amount of repetition.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Target description classes
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      The LLVM target description classes (which are located in the
+ include/llvm/Target directory) provide an abstract description of the
+ target machine, independent of any particular client.  These classes are
+ designed to capture the abstract properties of the target (such as what
+ instruction and registers it has), and do not incorporate any particular pieces
+ of code generation algorithms (these interfaces do not take interference graphs
+ as inputs or other algorithm-specific data structures).
      
+ 
+ 
      All of the target description classes (except the TargetData class) are designed to be subclassed by
+ the concrete target implementation, and have virtual methods implemented.  To
+ get to these implementations, the TargetMachine class provides accessors that
+ should be implemented by the target.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The TargetMachine class
+ 
      
+ 
+ 
      
+ 
+ 
      The TargetMachine class provides virtual methods that are used to
+ access the target-specific implementations of the various target description
+ classes (with the getInstrInfo, getRegisterInfo,
+ getFrameInfo, ... methods).  This class is designed to be specialized by
+ a concrete target implementation (e.g., X86TargetMachine) which
+ implements the various virtual methods.  The only required target description
+ class is the TargetData class, but if the
+ code generator components are to be used, the other interfaces should be
+ implemented as well.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   The TargetData class
+ 
      
+ 
+ 
      
+ 
+ 
      The TargetData class is the only required target description class,
+ and it is the only class that is not extensible (it cannot be derived from).  It
+ specifies information about how the target lays out memory for structures, the
+ alignment requirements for various data types, the size of pointers in the
+ target, and whether the target is little- or big-endian.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   The MRegisterInfo class
+ 
      
+ 
+ 
      
+ 
+ 
      The MRegisterInfo class (which will eventually be renamed to
+ TargetRegisterInfo) is used to describe the register file of the
+ target and any interactions between the registers.
      
+ 
+ 
      Registers in the code generator are represented in the code generator by
+ unsigned numbers.  Physical registers (those that actually exist in the target
+ description) are unique small numbers, and virtual registers are generally
+ large.
      
+ 
+ 
      Each register in the processor description has an associated
+ MRegisterDesc entry, which provides a textual name for the register
+ (used for assembly output and debugging dumps), a set of aliases (used to
+ indicate that one register overlaps with another), and some flag bits.
+ 
      
+ 
+ 
      In addition to the per-register description, the MRegisterInfo class
+ exposes a set of processor specific register classes (instances of the
+ TargetRegisterClass class).  Each register class contains sets of
+ registers that have the same properties (for example, they are all 32-bit
+ integer registers).  Each SSA virtual register created by the instruction
+ selector has an associated register class.  When the register allocator runs, it
+ replaces virtual registers with a physical register in the set.
      
+ 
+ 
      
+ The target-specific implementations of these classes is auto-generated from a TableGen description of the register file.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The TargetInstrInfo class
+ 
      
+ 
+ 
+ 
      
+   The TargetFrameInfo class
+ 
      
+ 
+ 
+ 
      
+   The TargetJITInfo class
+ 
      
+ 
+ 
+ 
      
+   Machine code description classes
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      
+ At the high-level, LLVM code is translated to a machine specific representation
+ formed out of MachineFunction, MachineBasicBlock, and MachineInstr instances
+ (defined in include/llvm/CodeGen).  This representation is completely target
+ agnostic, representing instructions in their most abstract form: an opcode and a
+ series of operands.  This representation is designed to support both SSA
+ representation for machine code, as well as a register allocated, non-SSA form.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The MachineInstr class
+ 
      
+ 
+ 
      
+ 
+ 
      Target machine instructions are represented as instances of the
+ MachineInstr class.  This class is an extremely abstract way of
+ representing machine instructions.  In particular, all it keeps track of is 
+ an opcode number and some number of operands.
      
+ 
+ 
      The opcode number is an simple unsigned number that only has meaning to a 
+ specific backend.  All of the instructions for a target should be defined in 
+ the *InstrInfo.td file for the target, and the opcode enum values
+ are autogenerated from this description.  The MachineInstr class does
+ not have any information about how to intepret the instruction (i.e., what the 
+ semantics of the instruction are): for that you must refer to the 
+ TargetInstrInfo class.
       
+ 
+ 
      The operands of a machine instruction can be of several different types:
+ they can be a register reference, constant integer, basic block reference, etc.
+ In addition, a machine operand should be marked as a def or a use of the value
+ (though only registers are allowed to be defs).
      
+ 
+ 
      By convention, the LLVM code generator orders instruction operands so that
+ all register definitions come before the register uses, even on architectures
+ that are normally printed in other orders.  For example, the sparc add 
+ instruction: "add %i1, %i2, %i3" adds the "%i1", and "%i2" registers
+ and stores the result into the "%i3" register.  In the LLVM code generator,
+ the operands should be stored as "%i3, %i1, %i2": with the destination
+ first.
      
+ 
+ 
      Keeping destination operands at the beginning of the operand list has several
+ advantages.  In particular, the debugging printer will print the instruction 
+ like this:
      
+ 
+ 
      +   %r3 = add %i1, %i2
+ 
      
+ 
+ 
      If the first operand is a def, and it is also easier to create instructions whose only def is the first 
+ operand.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Using the MachineInstrBuilder.h functions
+ 
      
+ 
+ 
      
+ 
+ 
      Machine instructions are created by using the BuildMI functions,
+ located in the include/llvm/CodeGen/MachineInstrBuilder.h file.  The
+ BuildMI functions make it easy to build arbitrary machine 
+ instructions.  Usage of the BuildMI functions look like this: 
+ 
      
+ 
+ 
      +   // Create a 'DestReg = mov 42' (rendered in X86 assembly as 'mov DestReg, 42')
+   // instruction.  The '1' specifies how many operands will be added.
+   MachineInstr *MI = BuildMI(X86::MOV32ri, 1, DestReg).addImm(42);
+ 
+   // Create the same instr, but insert it at the end of a basic block.
+   MachineBasicBlock &MBB = ...
+   BuildMI(MBB, X86::MOV32ri, 1, DestReg).addImm(42);
+ 
+   // Create the same instr, but insert it before a specified iterator point.
+   MachineBasicBlock::iterator MBBI = ...
+   BuildMI(MBB, MBBI, X86::MOV32ri, 1, DestReg).addImm(42);
+ 
+   // Create a 'cmp Reg, 0' instruction, no destination reg.
+   MI = BuildMI(X86::CMP32ri, 2).addReg(Reg).addImm(0);
+   // Create an 'sahf' instruction which takes no operands and stores nothing.
+   MI = BuildMI(X86::SAHF, 0);
+ 
+   // Create a self looping branch instruction.
+   BuildMI(MBB, X86::JNE, 1).addMBB(&MBB);
+ 
      
+ 
+ 
      
+ The key thing to remember with the BuildMI functions is that you have
+ to specify the number of operands that the machine instruction will take 
+ (allowing efficient memory allocation).  Also, if operands default to be uses
+ of values, not definitions.  If you need to add a definition operand (other 
+ than the optional destination register), you must explicitly mark it as such.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Fixed (aka preassigned) registers
+ 
      
+ 
+ 
      
+ 
+ 
      One important issue that the code generator needs to be aware of is the
+ presence of fixed registers.  In particular, there are often places in the 
+ instruction stream where the register allocator must arrange for a
+ particular value to be in a particular register.  This can occur due to 
+ limitations in the instruction set (e.g., the X86 can only do a 32-bit divide 
+ with the EAX/EDX registers), or external factors like calling
+ conventions.  In any case, the instruction selector should emit code that 
+ copies a virtual register into or out of a physical register when needed.
      
+ 
+ 
      For example, consider this simple LLVM example:
      
+ 
+ 
      +   int %test(int %X, int %Y) {
+     %Z = div int %X, %Y
+     ret int %Z
+   }
+ 
      
+ 
+ 
      The X86 instruction selector produces this machine code for the div 
+ and ret (use 
+ "llc X.bc -march=x86 -print-machineinstrs" to get this):
      
+ 
+ 
      +         ;; Start of div
+         %EAX = mov %reg1024           ;; Copy X (in reg1024) into EAX
+         %reg1027 = sar %reg1024, 31
+         %EDX = mov %reg1027           ;; Sign extend X into EDX
+         idiv %reg1025                 ;; Divide by Y (in reg1025)
+         %reg1026 = mov %EAX           ;; Read the result (Z) out of EAX
+ 
+         ;; Start of ret
+         %EAX = mov %reg1026           ;; 32-bit return value goes in EAX
+         ret
+ 
      
+ 
+ 
      By the end of code generation, the register allocator has coallesced
+ the registers and deleted the resultant identity moves, producing the
+ following code:
      
+ 
+ 
      +         ;; X is in EAX, Y is in ECX
+         mov %EAX, %EDX
+         sar %EDX, 31
+         idiv %ECX
+         ret 
+ 
      
+ 
+ 
      This approach is extremely general (if it can handle the X86 architecture, 
+ it can handle anything!) and allows all of the target specific
+ knowledge about the instruction stream to be isolated in the instruction 
+ selector.  Note that physical registers should have a short lifetime for good 
+ code generation, and all physical registers are assumed dead on entry and
+ exit of basic blocks (before register allocation).  Thus if you need a value
+ to be live across basic block boundaries, it must live in a virtual 
+ register.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Machine code SSA form
+ 
      
+ 
+ 
      
+ 
+ 
      MachineInstr's are initially instruction selected in SSA-form, and
+ are maintained in SSA-form until register allocation happens.  For the most 
+ part, this is trivially simple since LLVM is already in SSA form: LLVM PHI nodes
+ become machine code PHI nodes, and virtual registers are only allowed to have a
+ single definition.
      
+ 
+ 
      After register allocation, machine code is no longer in SSA-form, as there 
+ are no virtual registers left in the code.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Target description implementations
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      This section of the document explains any features or design decisions that
+ are specific to the code generator for a particular target.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   The X86 backend
+ 
      
+ 
+ 
      
+ 
+ 
      
+ The X86 code generator lives in the lib/Target/X86 directory.  This
+ code generator currently targets a generic P6-like processor.  As such, it
+ produces a few P6-and-above instructions (like conditional moves), but it does
+ not make use of newer features like MMX or SSE.  In the future, the X86 backend
+ will have subtarget support added for specific processor families and 
+ implementations.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Representing X86 addressing modes in MachineInstrs
+ 
      
+ 
+ 
      
+ 
+ 
      
+ The x86 has a very, uhm, flexible, way of accessing memory.  It is capable of
+ forming memory addresses of the following expression directly in integer
+ instructions (which use ModR/M addressing):
      
+ 
+ 
      +    Base+[1,2,4,8]*IndexReg+Disp32
+ 
      
+ 
+ 
      Wow, that's crazy.  In order to represent this, LLVM tracks no less than 4
+ operands for each memory operand of this form.  This means that the "load" form
+ of 'mov' has the following "Operands" in this order:
      
+ 
+ 
      + Index:        0     |    1        2       3           4
+ Meaning:   DestReg, | BaseReg,  Scale, IndexReg, Displacement
+ OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg,   SignExtImm
+ 
      
+ 
+ 
      Stores and all other instructions treat the four memory operands in the same
+ way, in the same order.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Instruction naming
+ 
      
+ 
+ 
      
+ 
+ 
      
+ An instruction name consists of the base name, a default operand size
+ followed by a character per operand with an optional special size. For
+ example:
      
+ 
+ 
      
+ ADD8rr -> add, 8-bit register, 8-bit register
      
+ IMUL16rmi -> imul, 16-bit register, 16-bit memory, 16-bit immediate
      
+ IMUL16rmi8 -> imul, 16-bit register, 16-bit memory, 8-bit immediate
      
+ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Chris Lattner
      
+   The LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/CodingStandards.html
diff -c /dev/null llvm-www/releases/1.4/docs/CodingStandards.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/CodingStandards.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,646 ----
+ 
+ 
+ 
+   
+   A Few Coding Standards
+ 
+ 
+ 
+ 
      
+   A Few Coding Standards
+ 
      
+ 
+ 
        
+   
      1. Introduction
        2. 
+   
      2. Mechanical Source Issues
+     
          
+       
        1. Source Code Formatting
+         
            
+           
          1. Commenting
            2. 
+           
          2. Comment Formatting
            3. 
+           
          3. #include Style
            4. 
+           
          4. Source Code Width
            5. 
+           
          5. Use Spaces Instead of Tabs
            6. 
+           
          6. Indent Code Consistently
            7. 
+         
          2. 
+       
        2. Compiler Issues
+         
            
+           
          1. Treat Compiler Warnings Like
+               Errors
            2. 
+           
          2. Write Portable Code
            3. 
+           
          3. Use of class/struct Keywords
            4. 
+         
          3. 
+     
        3. 
+   
      3. Style Issues
+     
          
+       
        1. The High Level Issues
+         
            
+           
          1. A Public Header File is a
+               Module
            2. 
+           
          2. #include as Little as Possible
            3. 
+           
          3. Keep "internal" Headers
+               Private
            4. 
+         
          2. 
+       
        2. The Low Level Issues
+         
            
+           
          1. Assert Liberally
            2. 
+           
          2. Prefer Preincrement
            3. 
+           
          3. Avoid std::endl
            4. 
+           
          4. Exploit C++ to its Fullest
            5. 
+         
          3. 
+     
        4. 
+   
      4. See Also
        5. 
+ 
      
+ 
+ 
      
+   
      Written by Chris Lattner
      
+ 
      
+ 
+ 
+ 
+ 
      
+   Introduction
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      This document attempts to describe a few coding standards that are being used
+ in the LLVM source tree.  Although no coding standards should be regarded as
+ absolute requirements to be followed in all instances, coding standards can be
+ useful.
      
+ 
+ 
      This document intentionally does not prescribe fixed standards for religious
+ issues such as brace placement and space usage.  For issues like this, follow
+ the golden rule:
      
+ 
+ 
      
+ 
+ 
      If you are adding a significant body of source to a
+ project, feel free to use whatever style you are most comfortable with.  If you
+ are extending, enhancing, or bug fixing already implemented code, use the style
+ that is already being used so that the source is uniform and easy to
+ follow.
      
+ 
+ 
      
+ 
+ 
      The ultimate goal of these guidelines is the increase readability and
+ maintainability of our common source base. If you have suggestions for topics to
+ be included, please mail them to Chris.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Mechanical Source Issues
+ 
      
+ 
+ 
+ 
+ 
      
+   Source Code Formatting
+ 
      
+ 
+ 
+ 
      
+   Commenting
+ 
      
+ 
+ 
      
+ 
+ 
      Comments are one critical part of readability and maintainability.  Everyone
+ knows they should comment, so should you.  Although we all should probably
+ comment our code more than we do, there are a few very critical places that
+ documentation is very useful:
      
+ 
+ File Headers
+ 
+ 
      Every source file should have a header on it that
+ describes the basic purpose of the file.  If a file does not have a header, it
+ should not be checked into CVS.  Most source trees will probably have a standard
+ file header format.  The standard format for the LLVM source tree looks like
+ this:
      
+ 
+ 
      
+ 
      + //===-- llvm/Instruction.h - Instruction class definition -------*- C++ -*-===//
+ // 
+ //                     The LLVM Compiler Infrastructure
+ //
+ // This file was developed by the LLVM research group and is distributed under
+ // the University of Illinois Open Source License. See LICENSE.TXT for details.
+ // 
+ //===----------------------------------------------------------------------===//
+ //
+ // This file contains the declaration of the Instruction class, which is the
+ // base class for all of the VM instructions.
+ //
+ //===----------------------------------------------------------------------===//
+ 
      
+ 
      
+ 
+ 
      A few things to note about this particular format:  The "-*- C++
+ -*-" string on the first line is there to tell Emacs that the source file
+ is a C++ file, not a C file (Emacs assumes .h files are C files by default).
+ Note that this tag is not necessary in .cpp files.  The name of the file is also
+ on the first line, along with a very short description of the purpose of the
+ file.  This is important when printing out code and flipping though lots of
+ pages.
      
+ 
+ 
      The next section in the file is a concise note that defines the license that
+ the file is released under.  This makes it perfectly clear what terms the source
+ code can be distributed under.
      
+ 
+ 
      The main body of the description does not have to be very long in most cases.
+ Here it's only two lines.  If an algorithm is being implemented or something
+ tricky is going on, a reference to the paper where it is published should be
+ included, as well as any notes or "gotchas" in the code to watch out for.
      
+ 
+ Class overviews
+ 
+ 
      Classes are one fundemental part of a good object oriented design.  As such,
+ a class definition should have a comment block that explains what the class is
+ used for... if it's not obvious.  If it's so completely obvious your grandma
+ could figure it out, it's probably safe to leave it out.  Naming classes
+ something sane goes a long ways towards avoiding writing documentation.
      
+ 
+ 
+ Method information
+ 
+ 
      Methods defined in a class (as well as any global functions) should also be
+ documented properly.  A quick note about what it does any a description of the
+ borderline behaviour is all that is necessary here (unless something
+ particularly tricky or insideous is going on).  The hope is that people can
+ figure out how to use your interfaces without reading the code itself... that is
+ the goal metric.
      
+ 
+ 
      Good things to talk about here are what happens when something unexpected
+ happens: does the method return null?  Abort?  Format your hard disk?
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Comment Formatting
+ 
      
+ 
+ 
      
+ 
+ 
      In general, prefer C++ style (//) comments.  They take less space,
+ require less typing, don't have nesting problems, etc.  There are a few cases
+ when it is useful to use C style (/* */) comments however:
      
+ 
+ 
        
+   
      1. When writing a C code: Obviously if you are writing C code, use C style
+       comments.
        2. 
+   
      2. When writing a header file that may be #included by a C source
+       file.
        3. 
+   
      3. When writing a source file that is used by a tool that only accepts C
+       style comments.
        4. 
+ 
      
+ 
+ 
      To comment out a large block of code, use #if 0 and #endif.
+ These nest properly and are better behaved in general than C style comments.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   #include Style
+ 
      
+ 
+ 
      
+ 
+ 
      Immediately after the header file comment (and
+ include guards if working on a header file), the minimal list of #includes required by the
+ file should be listed.  We prefer these #includes to be listed in this
+ order:
      
+ 
+ 
        
+   
      1. Main Module header
        2. 
+   
      2. Local/Private Headers
        3. 
+   
      3. llvm/*
        4. 
+   
      4. llvm/Analysis/*
        5. 
+   
      5. llvm/Assembly/*
        6. 
+   
      6. llvm/Bytecode/*
        7. 
+   
      7. llvm/CodeGen/*
        8. 
+   
      8. ...
        9. 
+   
      9. Support/*
        10. 
+   
      10. Config/*
        11. 
+   
      11. System #includes
        12. 
+ 
      
+ 
+ 
      ... and each catagory should be sorted by name.
      
+ 
+ 
      The "Main Module Header" file applies to .cpp file
+ which implement an interface defined by a .h file.  This #include
+ should always be included first regardless of where it lives on the file
+ system.  By including a header file first in the .cpp files that implement the
+ interfaces, we ensure that the header does not have any hidden dependencies
+ which are not explicitly #included in the header, but should be.  It is also a
+ form of documentation in the .cpp file to indicate where the interfaces it
+ implements are defined.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Source Code Width
+ 
      
+ 
+ 
      
+ 
+ 
      Write your code to fit within 80 columns of text.  This helps those of us who
+ like to print out code and look at your code in an xterm without resizing
+ it.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Use Spaces Instead of Tabs
+ 
      
+ 
+ 
      
+ 
+ 
      In all cases, prefer spaces to tabs in source files.  People have different
+ prefered indentation levels, and different styles of indentation that they
+ like... this is fine.  What isn't is that different editors/viewers expand tabs
+ out to different tab stops.  This can cause your code to look completely
+ unreadable, and it is not worth dealing with.
      
+ 
+ 
      As always, follow the Golden Rule above: follow the
+ style of existing code if your are modifying and extending it.  If you like four
+ spaces of indentation, DO NOT do that in the middle of a chunk of code
+ with two spaces of indentation.  Also, do not reindent a whole source file: it
+ makes for incredible diffs that are absolutely worthless.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Indent Code Consistently
+ 
      
+ 
+ 
      
+ 
+ 
      Okay, your first year of programming you were told that indentation is
+ important.  If you didn't believe and internalize this then, now is the time.
+ Just do it.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Compiler Issues
+ 
      
+ 
+ 
+ 
+ 
      
+   Treat Compiler Warnings Like Errors
+ 
      
+ 
+ 
      
+ 
+ 
      If your code has compiler warnings in it, something is wrong: you aren't
+ casting values correctly, your have "questionable" constructs in your code, or
+ you are doing something legitimately wrong.  Compiler warnings can cover up
+ legitimate errors in output and make dealing with a translation unit
+ difficult.
      
+ 
+ 
      It is not possible to prevent all warnings from all compilers, nor is it
+ desirable.  Instead, pick a standard compiler (like gcc) that provides
+ a good thorough set of warnings, and stick to them.  At least in the case of
+ gcc, it is possible to work around any spurious errors by changing the
+ syntax of the code slightly.  For example, an warning that annoys me occurs when
+ I write code like this:
      
+ 
+ 
      
+ 
      + if (V = getValue()) {
+   ...
+ }
+ 
      
+ 
      
+ 
+ 
      gcc will warn me that I probably want to use the ==
+ operator, and that I probably mistyped it.  In most cases, I haven't, and I
+ really don't want the spurious errors.  To fix this particular problem, I
+ rewrite the code like this:
      
+ 
+ 
      
+ 
      + if ((V = getValue())) {
+   ...
+ }
+ 
      
+ 
      
+ 
+ 
      ...which shuts gcc up.  Any gcc warning that annoys you can
+ be fixed by massaging the code appropriately.
      
+ 
+ 
      These are the gcc warnings that I prefer to enable: -Wall
+ -Winline -W -Wwrite-strings -Wno-unused
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Write Portable Code
+ 
      
+ 
+ 
      
+ 
+ 
      In almost all cases, it is possible and within reason to write completely
+ portable code.  If there are cases where it isn't possible to write portable
+ code, isolate it behind a well defined (and well documented) interface.
      
+ 
+ 
      In practice, this means that you shouldn't assume much about the host
+ compiler, including its support for "high tech" features like partial
+ specialization of templates.  In fact, Visual C++ 6 could be an important target
+ for our work in the future, and we don't want to have to rewrite all of our code
+ to support it.
      
+ 
+ 
      
+ 
+ 
+ 
      
+ Use of class and struct Keywords
+ 
      
+ 
      
+ 
+ 
      In C++, the class and struct keywords can be used almost
+ interchangeably. The only difference is when they are used to declare a class:
+ class makes all members private by default while struct makes
+ all members public by default.
      
+ 
+ 
      Unfortunately, not all compilers follow the rules and some will generate
+ different symbols based on whether class or struct was used to
+ declare the symbol.  This can lead to problems at link time.
       
+ 
+ 
      So, the rule for LLVM is to always use the class keyword, unless
+ all members are public, in which case struct is allowed.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Style Issues
+ 
      
+ 
+ 
+ 
+ 
+ 
      
+   The High Level Issues
+ 
      
+ 
+ 
+ 
+ 
      
+   A Public Header File is a Module
+ 
      
+ 
+ 
      
+ 
+ 
      C++ doesn't do too well in the modularity department.  There is no real
+ encapsulation or data hiding (unless you use expensive protocol classes), but it
+ is what we have to work with.  When you write a public header file (in the LLVM
+ source tree, they live in the top level "include" directory), you are defining a
+ module of functionality.
      
+ 
+ 
      Ideally, modules should be completely independent of each other, and their
+ header files should only include the absolute minimum number of headers
+ possible. A module is not just a class, a function, or a namespace: it's a collection
+ of these that defines an interface.  This interface may be several
+ functions, classes or data structures, but the important issue is how they work
+ together.
      
+ 
+ 
      In general, a module should be implemented with one or more .cpp
+ files.  Each of these .cpp files should include the header that defines
+ their interface first.  This ensure that all of the dependences of the module
+ header have been properly added to the module header itself, and are not
+ implicit.  System headers should be included after user headers for a
+ translation unit.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   #include as Little as Possible
+ 
      
+ 
+ 
      
+ 
+ 
      #include hurts compile time performance.  Don't do it unless you
+ have to, especially in header files.
      
+ 
+ 
      But wait, sometimes you need to have the definition of a class to use it, or
+ to inherit from it.  In these cases go ahead and #include that header
+ file.  Be aware however that there are many cases where you don't need to have
+ the full definition of a class.  If you are using a pointer or reference to a
+ class, you don't need the header file.  If you are simply returning a class
+ instance from a prototyped function or method, you don't need it.  In fact, for
+ most cases, you simply don't need the definition of a class... and not
+ #include'ing speeds up compilation.
      
+ 
+ 
      It is easy to try to go too overboard on this recommendation, however.  You
+ must include all of the header files that you are using, either directly
+ or indirectly (through another header file).  To make sure that you don't
+ accidently forget to include a header file in your module header, make sure to
+ include your module header first in the implementation file (as mentioned
+ above).  This way there won't be any hidden dependencies that you'll find out
+ about later...
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Keep "internal" Headers Private
+ 
      
+ 
+ 
      
+ 
+ 
      Many modules have a complex implementation that causes them to use more than
+ one implementation (.cpp) file.  It is often tempting to put the
+ internal communication interface (helper classes, extra functions, etc) in the
+ public module header file.  Don't do this.
      
+ 
+ 
      If you really need to do something like this, put a private header file in
+ the same directory as the source files, and include it locally.  This ensures
+ that your private interface remains private and undisturbed by outsiders.
      
+ 
+ 
      Note however, that it's okay to put extra implementation methods a public
+ class itself... just make them private (or protected), and all is well.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The Low Level Issues
+ 
      
+ 
+ 
+ 
+ 
      
+   Assert Liberally
+ 
      
+ 
+ 
      
+ 
+ 
      Use the "assert" function to its fullest.  Check all of your
+ preconditions and assumptions, you never know when a bug (not neccesarily even
+ yours) might be caught early by an assertion, which reduces debugging time
+ dramatically.  The "<cassert>" header file is probably already
+ included by the header files you are using, so it doesn't cost anything to use
+ it.
      
+ 
+ 
      To further assist with debugging, make sure to put some kind of error message
+ in the assertion statement (which is printed if the assertion is tripped). This
+ helps the poor debugging make sense of why an assertion is being made and
+ enforced, and hopefully what to do about it.  Here is one complete example:
      
+ 
+ 
      
+ 
      + inline Value *getOperand(unsigned i) { 
+   assert(i < Operands.size() && "getOperand() out of range!");
+   return Operands[i]; 
+ }
+ 
      
+ 
      
+ 
+ 
      Here are some examples:
      
+ 
+ 
      
+ 
      + assert(Ty->isPointerType() && "Can't allocate a non pointer type!");
+ 
+ assert((Opcode == Shl || Opcode == Shr) && "ShiftInst Opcode invalid!");
+ 
+ assert(idx < getNumSuccessors() && "Successor # out of range!");
+ 
+ assert(V1.getType() == V2.getType() && "Constant types must be identical!");
+ 
+ assert(isa<PHINode>(Succ->front()) && "Only works on PHId BBs!");
+ 
      
+ 
      
+ 
+ 
      You get the idea...
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Prefer Preincrement
+ 
      
+ 
+ 
      
+ 
+ 
      Hard fast rule: Preincrement (++X) may be no slower than
+ postincrement (X++) and could very well be a lot faster than it.  Use
+ preincrementation whenever possible.
      
+ 
+ 
      The semantics of postincrement include making a copy of the value being
+ incremented, returning it, and then preincrementing the "work value".  For
+ primitive types, this isn't a big deal... but for iterators, it can be a huge
+ issue (for example, some iterators contains stack and set objects in them...
+ copying an iterator could invoke the copy ctor's of these as well).  In general,
+ get in the habit of always using preincrement, and you won't have a problem.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Avoid std::endl
+ 
      
+ 
+ 
      
+ 
+ 
      The std::endl modifier, when used with iostreams outputs a newline
+ to the output stream specified.  In addition to doing this, however, it also
+ flushes the output stream.  In other words, these are equivalent:
      
+ 
+ 
      
+ 
      + std::cout << std::endl;
+ std::cout << '\n' << std::flush;
+ 
      
+ 
      
+ 
+ 
      Most of the time, you probably have no reason to flush the output stream, so
+ it's better to use a literal '\n'.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Exploit C++ to its Fullest
+ 
      
+ 
+ 
      
+ 
+ 
      C++ is a powerful language.  With a firm grasp on its capabilities, you can
+ make write effective, consise, readable and maintainable code all at the same
+ time.  By staying consistent, you reduce the amount of special cases that need
+ to be remembered.  Reducing the total number of lines of code you write is a
+ good way to avoid documentation, and avoid giving bugs a place to hide.
      
+ 
+ 
      For these reasons, come to know and love the contents of your local
+ <algorithm> header file.  Know about <functional>
+ and what it can do for you.  C++ is just a tool that wants you to master it.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   See Also
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      A lot of these comments and recommendations have been culled for other
+ sources.  Two particularly important books for our work are:
      
+ 
+ 
        
+ 
+ 
      1. Effective
+ C++ by Scott Meyers.  There is an online version of the book (only some
+ chapters though) available as well.  Also
+ interesting and useful are "More Effective C++" and "Effective STL" by the same
+ author.
        2. 
+ 
+ 
      2. Large-Scale C++
+ Software Design by John Lakos
        3. 
+ 
+ 
      
+ 
+ 
      If you get some free time, and you haven't read them: do so, you might learn
+ something.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Chris Lattner
      
+   LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/CommandLine.html
diff -c /dev/null llvm-www/releases/1.4/docs/CommandLine.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/CommandLine.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,1815 ----
+ 
+ 
+ 
+   
+   CommandLine 2.0 Library Manual
+   
+ 
+ 
+ 
+ 
      
+   CommandLine 2.0 Library Manual
+ 
      
+ 
+ 
        
+   
      1. Introduction
        2. 
+ 
+   
      2. Quick Start Guide
+     
          
+       
        1. Boolean Arguments
          2. 
+       
        2. Argument Aliases
          3. 
+       
        3. Selecting an alternative from a
+                                     set of possibilities
          4. 
+       
        4. Named alternatives
          5. 
+       
        5. Parsing a list of options
          6. 
+       
        6. Adding freeform text to help output
          7. 
+     
        3. 
+ 
+   
      3. Reference Guide
+     
          
+       
        1. Positional Arguments
+         
          2. 
+ 
+       
        2. Internal vs External Storage
          3. 
+ 
+       
        3. Option Attributes
          4. 
+ 
+       
        4. Option Modifiers
+         
          5. 
+ 
+       
        5. Top-Level Classes and Functions
+         
          6. 
+ 
+       
        6. Builtin parsers
+         
          7. 
+     
        4. 
+   
      4. Extension Guide
+     
          
+       
        1. Writing a custom parser
          2. 
+       
        2. Exploiting external storage
          3. 
+       
        3. Dynamically adding command line 
+           options
          4. 
+     
        5. 
+ 
      
+ 
+ 
      
+   
      Written by Chris Lattner
      
+ 
      
+ 
+ 
+ 
      
+   Introduction
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      This document describes the CommandLine argument processing library.  It will
+ show you how to use it, and what it can do.  The CommandLine library uses a
+ declarative approach to specifying the command line options that your program
+ takes.  By default, these options declarations implicitly hold the value parsed
+ for the option declared (of course this can be
+ changed).
      
+ 
+ 
      Although there are a lot of command line argument parsing libraries
+ out there in many different languages, none of them fit well with what I needed.
+ By looking at the features and problems of other libraries, I designed the
+ CommandLine library to have the following features:
      
+ 
+ 
        
+ 
      1. Speed: The CommandLine library is very quick and uses little resources.  The
+ parsing time of the library is directly proportional to the number of arguments
+ parsed, not the the number of options recognized.  Additionally, command line
+ argument values are captured transparently into user defined global variables,
+ which can be accessed like any other variable (and with the same
+ performance).
        2. 
+ 
+ 
      2. Type Safe: As a user of CommandLine, you don't have to worry about
+ remembering the type of arguments that you want (is it an int?  a string? a
+ bool? an enum?) and keep casting it around.  Not only does this help prevent
+ error prone constructs, it also leads to dramatically cleaner source code.
        3. 
+ 
+ 
      3. No subclasses required: To use CommandLine, you instantiate variables that
+ correspond to the arguments that you would like to capture, you don't subclass a
+ parser.  This means that you don't have to write any boilerplate
+ code.
        4. 
+ 
+ 
      4. Globally accessible: Libraries can specify command line arguments that are
+ automatically enabled in any tool that links to the library.  This is possible
+ because the application doesn't have to keep a "list" of arguments to pass to
+ the parser.  This also makes supporting dynamically
+ loaded options trivial.
        5. 
+ 
+ 
      5. Cleaner: CommandLine supports enum and other types directly, meaning that
+ there is less error and more security built into the library.  You don't have to
+ worry about whether your integral command line argument accidentally got
+ assigned a value that is not valid for your enum type.
        6. 
+ 
+ 
      6. Powerful: The CommandLine library supports many different types of
+ arguments, from simple boolean flags to scalars arguments (strings, integers, enums, doubles), to lists of
+ arguments.  This is possible because CommandLine is...
        7. 
+ 
+ 
      7. Extensible: It is very simple to add a new argument type to CommandLine.
+ Simply specify the parser that you want to use with the command line option when
+ you declare it.  Custom parsers are no problem.
        8. 
+ 
+ 
      8. Labor Saving: The CommandLine library cuts down on the amount of grunt work
+ that you, the user, have to do.  For example, it automatically provides a
+ --help option that shows the available command line options for your
+ tool.  Additionally, it does most of the basic correctness checking for
+ you.
        9. 
+ 
+ 
      9. Capable: The CommandLine library can handle lots of different forms of
+ options often found in real programs.  For example, positional arguments, ls style grouping options (to allow processing 'ls
+ -lad' naturally), ld style prefix
+ options (to parse '-lmalloc -L/usr/lib'), and interpreter style options.
        10. 
+ 
+ 
      
+ 
+ 
      This document will hopefully let you jump in and start using CommandLine in
+ your utility quickly and painlessly.  Additionally it should be a simple
+ reference manual to figure out how stuff works.  If it is failing in some area
+ (or you want an extension to the library), nag the author, Chris Lattner.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Quick Start Guide
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      This section of the manual runs through a simple CommandLine'ification of a
+ basic compiler tool.  This is intended to show you how to jump into using the
+ CommandLine library in your own program, and show you some of the cool things it
+ can do.
      
+ 
+ 
      To start out, you need to include the CommandLine header file into your
+ program:
      
+ 
+ 
      +   #include "Support/CommandLine.h"
+ 
      
+ 
+ 
      Additionally, you need to add this as the first line of your main
+ program:
      
+ 
+ 
      + int main(int argc, char **argv) {
+   cl::ParseCommandLineOptions(argc, argv);
+   ...
+ }
+ 
      
+ 
+ 
      ... which actually parses the arguments and fills in the variable
+ declarations.
      
+ 
+ 
      Now that you are ready to support command line arguments, we need to tell the
+ system which ones we want, and what type of argument they are.  The CommandLine
+ library uses a declarative syntax to model command line arguments with the
+ global variable declarations that capture the parsed values.  This means that
+ for every command line option that you would like to support, there should be a
+ global variable declaration to capture the result.  For example, in a compiler,
+ we would like to support the unix standard '-o <filename>' option
+ to specify where to put the output.  With the CommandLine library, this is
+ represented like this:
      
+ 
+ 
+ 
      + cl::opt<string> OutputFilename("o", cl::desc("Specify output filename"), cl::value_desc("filename"));
+ 
      
+ 
+ 
      This declares a global variable "OutputFilename" that is used to
+ capture the result of the "o" argument (first parameter).  We specify
+ that this is a simple scalar option by using the "cl::opt" template (as opposed to the "cl::list template), and tell the CommandLine library
+ that the data type that we are parsing is a string.
      
+ 
+ 
      The second and third parameters (which are optional) are used to specify what
+ to output for the "--help" option.  In this case, we get a line that
+ looks like this:
      
+ 
+ 
      + USAGE: compiler [options]
+ 
+ OPTIONS:
+   -help             - display available options (--help-hidden for more)
+   -o <filename>     - Specify output filename
+ 
      
+ 
+ 
      Because we specified that the command line option should parse using the
+ string data type, the variable declared is automatically usable as a
+ real string in all contexts that a normal C++ string object may be used.  For
+ example:
      
+ 
+ 
      +   ...
+   ofstream Output(OutputFilename.c_str());
+   if (Out.good()) ...
+   ...
+ 
      
+ 
+ 
      There are many different options that you can use to customize the command
+ line option handling library, but the above example shows the general interface
+ to these options.  The options can be specified in any order, and are specified
+ with helper functions like cl::desc(...), so
+ there are no positional dependencies to remember.  The available options are
+ discussed in detail in the Reference Guide.
      
+ 
+ 
      Continuing the example, we would like to have our compiler take an input
+ filename as well as an output filename, but we do not want the input filename to
+ be specified with a hyphen (ie, not -filename.c).  To support this
+ style of argument, the CommandLine library allows for positional arguments to be specified for the program.
+ These positional arguments are filled with command line parameters that are not
+ in option form.  We use this feature like this:
      
+ 
+ 
      + cl::opt<string> InputFilename(cl::Positional, cl::desc("<input file>"), cl::init("-"));
+ 
      
+ 
+ 
      This declaration indicates that the first positional argument should be
+ treated as the input filename.  Here we use the cl::init option to specify an initial value for the
+ command line option, which is used if the option is not specified (if you do not
+ specify a cl::init modifier for an option, then
+ the default constructor for the data type is used to initialize the value).
+ Command line options default to being optional, so if we would like to require
+ that the user always specify an input filename, we would add the cl::Required flag, and we could eliminate the
+ cl::init modifier, like this:
      
+ 
+ 
      + cl::opt<string> InputFilename(cl::Positional, cl::desc("<input file>"), cl::Required);
+ 
      
+ 
+ 
      Again, the CommandLine library does not require the options to be specified
+ in any particular order, so the above declaration is equivalent to:
      
+ 
+ 
      + cl::opt<string> InputFilename(cl::Positional, cl::Required, cl::desc("<input file>"));
+ 
      
+ 
+ 
      By simply adding the cl::Required flag,
+ the CommandLine library will automatically issue an error if the argument is not
+ specified, which shifts all of the command line option verification code out of
+ your application into the library.  This is just one example of how using flags
+ can alter the default behaviour of the library, on a per-option basis.  By
+ adding one of the declarations above, the --help option synopsis is now
+ extended to:
      
+ 
+ 
      + USAGE: compiler [options] <input file>
+ 
+ OPTIONS:
+   -help             - display available options (--help-hidden for more)
+   -o <filename>     - Specify output filename
+ 
      
+ 
+ 
      ... indicating that an input filename is expected.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Boolean Arguments
+ 
      
+ 
+ 
      
+ 
+ 
      In addition to input and output filenames, we would like the compiler example
+ to support three boolean flags: "-f" to force overwriting of the output
+ file, "--quiet" to enable quiet mode, and "-q" for backwards
+ compatibility with some of our users.  We can support these by declaring options
+ of boolean type like this:
      
+ 
+ 
      + cl::opt<bool> Force ("f", cl::desc("Overwrite output files"));
+ cl::opt<bool> Quiet ("quiet", cl::desc("Don't print informational messages"));
+ cl::opt<bool> Quiet2("q", cl::desc("Don't print informational messages"), cl::Hidden);
+ 
      
+ 
+ 
      This does what you would expect: it declares three boolean variables
+ ("Force", "Quiet", and "Quiet2") to recognize these
+ options.  Note that the "-q" option is specified with the "cl::Hidden" flag.  This modifier prevents it
+ from being shown by the standard "--help" output (note that it is still
+ shown in the "--help-hidden" output).
      
+ 
+ 
      The CommandLine library uses a different parser
+ for different data types.  For example, in the string case, the argument passed
+ to the option is copied literally into the content of the string variable... we
+ obviously cannot do that in the boolean case, however, so we must use a smarter
+ parser.  In the case of the boolean parser, it allows no options (in which case
+ it assigns the value of true to the variable), or it allows the values
+ "true" or "false" to be specified, allowing any of the
+ following inputs:
      
+ 
+ 
      +  compiler -f          # No value, 'Force' == true
+  compiler -f=true     # Value specified, 'Force' == true
+  compiler -f=TRUE     # Value specified, 'Force' == true
+  compiler -f=FALSE    # Value specified, 'Force' == false
+ 
      
+ 
+ 
      ... you get the idea.  The bool parser just turns
+ the string values into boolean values, and rejects things like 'compiler
+ -f=foo'.  Similarly, the float, double, and int parsers work
+ like you would expect, using the 'strtol' and 'strtod' C
+ library calls to parse the string value into the specified data type.
      
+ 
+ 
      With the declarations above, "compiler --help" emits this:
      
+ 
+ 
      + USAGE: compiler [options] <input file>
+ 
+ OPTIONS:
+   -f     - Overwrite output files
+   -o     - Override output filename
+   -quiet - Don't print informational messages
+   -help  - display available options (--help-hidden for more)
+ 
      
+ 
+ 
      and "opt --help-hidden" prints this:
      
+ 
+ 
      + USAGE: compiler [options] <input file>
+ 
+ OPTIONS:
+   -f     - Overwrite output files
+   -o     - Override output filename
+   -q     - Don't print informational messages
+   -quiet - Don't print informational messages
+   -help  - display available options (--help-hidden for more)
+ 
      
+ 
+ 
      This brief example has shown you how to use the 'cl::opt' class to parse simple scalar command line
+ arguments.  In addition to simple scalar arguments, the CommandLine library also
+ provides primitives to support CommandLine option aliases,
+ and lists of options.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Argument Aliases
+ 
      
+ 
+ 
      
+ 
+ 
      So far, the example works well, except for the fact that we need to check the
+ quiet condition like this now:
      
+ 
+ 
      + ...
+   if (!Quiet && !Quiet2) printInformationalMessage(...);
+ ...
+ 
      
+ 
+ 
      ... which is a real pain!  Instead of defining two values for the same
+ condition, we can use the "cl::alias" class to make the "-q"
+ option an alias for the "-quiet" option, instead of providing
+ a value itself:
      
+ 
+ 
      + cl::opt<bool> Force ("f", cl::desc("Overwrite output files"));
+ cl::opt<bool> Quiet ("quiet", cl::desc("Don't print informational messages"));
+ cl::alias     QuietA("q", cl::desc("Alias for -quiet"), cl::aliasopt(Quiet));
+ 
      
+ 
+ 
      The third line (which is the only one we modified from above) defines a
+ "-q alias that updates the "Quiet" variable (as specified by
+ the cl::aliasopt modifier) whenever it is
+ specified.  Because aliases do not hold state, the only thing the program has to
+ query is the Quiet variable now.  Another nice feature of aliases is
+ that they automatically hide themselves from the -help output
+ (although, again, they are still visible in the --help-hidden
+ output).
      
+ 
+ 
      Now the application code can simply use:
      
+ 
+ 
      + ...
+   if (!Quiet) printInformationalMessage(...);
+ ...
+ 
      
+ 
+ 
      ... which is much nicer!  The "cl::alias"
+ can be used to specify an alternative name for any variable type, and has many
+ uses.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Selecting an alternative from a set of
+   possibilities
+ 
      
+ 
+ 
      
+ 
+ 
      So far, we have seen how the CommandLine library handles builtin types like
+ std::string, bool and int, but how does it handle
+ things it doesn't know about, like enums or 'int*'s?
      
+ 
+ 
      The answer is that it uses a table driven generic parser (unless you specify
+ your own parser, as described in the Extension
+ Guide).  This parser maps literal strings to whatever type is required, and
+ requires you to tell it what this mapping should be.
      
+ 
+ 
      Lets say that we would like to add four optimization levels to our
+ optimizer, using the standard flags "-g", "-O0",
+ "-O1", and "-O2".  We could easily implement this with boolean
+ options like above, but there are several problems with this strategy:
      
+ 
+ 
        
+ 
      1. A user could specify more than one of the options at a time, for example,
+ "opt -O3 -O2".  The CommandLine library would not be able to catch this
+ erroneous input for us.
        2. 
+ 
+ 
      2. We would have to test 4 different variables to see which ones are set.
        3. 
+ 
+ 
      3. This doesn't map to the numeric levels that we want... so we cannot easily
+ see if some level >= "-O1" is enabled.
        4. 
+ 
+ 
      
+ 
+ 
      To cope with these problems, we can use an enum value, and have the
+ CommandLine library fill it in with the appropriate level directly, which is
+ used like this:
      
+ 
+ 
      + enum OptLevel {
+   g, O1, O2, O3
+ };
+ 
+ cl::opt<OptLevel> OptimizationLevel(cl::desc("Choose optimization level:"),
+   cl::values(
+     clEnumVal(g , "No optimizations, enable debugging"),
+     clEnumVal(O1, "Enable trivial optimizations"),
+     clEnumVal(O2, "Enable default optimizations"),
+     clEnumVal(O3, "Enable expensive optimizations"),
+    clEnumValEnd));
+ 
+ ...
+   if (OptimizationLevel >= O2) doPartialRedundancyElimination(...);
+ ...
+ 
      
+ 
+ 
      This declaration defines a variable "OptimizationLevel" of the
+ "OptLevel" enum type.  This variable can be assigned any of the values
+ that are listed in the declaration (Note that the declaration list must be
+ terminated with the "clEnumValEnd" argument!).  The CommandLine 
+ library enforces
+ that the user can only specify one of the options, and it ensure that only valid
+ enum values can be specified.  The "clEnumVal" macros ensure that the
+ command line arguments matched the enum values.  With this option added, our
+ help output now is:
      
+ 
+ 
      + USAGE: compiler [options] <input file>
+ 
+ OPTIONS:
+   Choose optimization level:
+     -g          - No optimizations, enable debugging
+     -O1         - Enable trivial optimizations
+     -O2         - Enable default optimizations
+     -O3         - Enable expensive optimizations
+   -f            - Overwrite output files
+   -help         - display available options (--help-hidden for more)
+   -o <filename> - Specify output filename
+   -quiet        - Don't print informational messages
+ 
      
+ 
+ 
      In this case, it is sort of awkward that flag names correspond directly to
+ enum names, because we probably don't want a enum definition named "g"
+ in our program.  Because of this, we can alternatively write this example like
+ this:
      
+ 
+ 
      + enum OptLevel {
+   Debug, O1, O2, O3
+ };
+ 
+ cl::opt<OptLevel> OptimizationLevel(cl::desc("Choose optimization level:"),
+   cl::values(
+    clEnumValN(Debug, "g", "No optimizations, enable debugging"),
+     clEnumVal(O1        , "Enable trivial optimizations"),
+     clEnumVal(O2        , "Enable default optimizations"),
+     clEnumVal(O3        , "Enable expensive optimizations"),
+    clEnumValEnd));
+ 
+ ...
+   if (OptimizationLevel == Debug) outputDebugInfo(...);
+ ...
+ 
      
+ 
+ 
      By using the "clEnumValN" macro instead of "clEnumVal", we
+ can directly specify the name that the flag should get.  In general a direct
+ mapping is nice, but sometimes you can't or don't want to preserve the mapping,
+ which is when you would use it.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Named Alternatives
+ 
      
+ 
+ 
      
+ 
+ 
      Another useful argument form is a named alternative style.  We shall use this
+ style in our compiler to specify different debug levels that can be used.
+ Instead of each debug level being its own switch, we want to support the
+ following options, of which only one can be specified at a time:
+ "--debug-level=none", "--debug-level=quick",
+ "--debug-level=detailed".  To do this, we use the exact same format as
+ our optimization level flags, but we also specify an option name.  For this
+ case, the code looks like this:
      
+ 
+ 
      + enum DebugLev {
+   nodebuginfo, quick, detailed
+ };
+ 
+ // Enable Debug Options to be specified on the command line
+ cl::opt<DebugLev> DebugLevel("debug_level", cl::desc("Set the debugging level:"),
+   cl::values(
+     clEnumValN(nodebuginfo, "none", "disable debug information"),
+      clEnumVal(quick,               "enable quick debug information"),
+      clEnumVal(detailed,            "enable detailed debug information"),
+     clEnumValEnd));
+ 
      
+ 
+ 
      This definition defines an enumerated command line variable of type "enum
+ DebugLev", which works exactly the same way as before.  The difference here
+ is just the interface exposed to the user of your program and the help output by
+ the "--help" option:
      
+ 
+ 
      + USAGE: compiler [options] <input file>
+ 
+ OPTIONS:
+   Choose optimization level:
+     -g          - No optimizations, enable debugging
+     -O1         - Enable trivial optimizations
+     -O2         - Enable default optimizations
+     -O3         - Enable expensive optimizations
+   -debug_level  - Set the debugging level:
+     =none       - disable debug information
+     =quick      - enable quick debug information
+     =detailed   - enable detailed debug information
+   -f            - Overwrite output files
+   -help         - display available options (--help-hidden for more)
+   -o <filename> - Specify output filename
+   -quiet        - Don't print informational messages
+ 
      
+ 
+ 
      Again, the only structural difference between the debug level declaration and
+ the optimization level declaration is that the debug level declaration includes
+ an option name ("debug_level"), which automatically changes how the
+ library processes the argument.  The CommandLine library supports both forms so
+ that you can choose the form most appropriate for your application.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Parsing a list of options
+ 
      
+ 
+ 
      
+ 
+ 
      Now that we have the standard run of the mill argument types out of the way,
+ lets get a little wild and crazy.  Lets say that we want our optimizer to accept
+ a list of optimizations to perform, allowing duplicates.  For example, we
+ might want to run: "compiler -dce -constprop -inline -dce -strip".  In
+ this case, the order of the arguments and the number of appearances is very
+ important.  This is what the "cl::list"
+ template is for.  First, start by defining an enum of the optimizations that you
+ would like to perform:
      
+ 
+ 
      + enum Opts {
+   // 'inline' is a C++ keyword, so name it 'inlining'
+   dce, constprop, inlining, strip
+ };
+ 
      
+ 
+ 
      Then define your "cl::list" variable:
      
+ 
+ 
      + cl::list<Opts> OptimizationList(cl::desc("Available Optimizations:"),
+   cl::values(
+     clEnumVal(dce               , "Dead Code Elimination"),
+     clEnumVal(constprop         , "Constant Propagation"),
+    clEnumValN(inlining, "inline", "Procedure Integration"),
+     clEnumVal(strip             , "Strip Symbols"),
+   clEnumValEnd));
+ 
      
+ 
+ 
      This defines a variable that is conceptually of the type
+ "std::vector<enum Opts>".  Thus, you can access it with standard
+ vector methods:
      
+ 
+ 
      +   for (unsigned i = 0; i != OptimizationList.size(); ++i)
+     switch (OptimizationList[i])
+        ...
+ 
      
+ 
+ 
      ... to iterate through the list of options specified.
      
+ 
+ 
      Note that the "cl::list" template is
+ completely general and may be used with any data types or other arguments that
+ you can use with the "cl::opt" template.  One
+ especially useful way to use a list is to capture all of the positional
+ arguments together if there may be more than one specified.  In the case of a
+ linker, for example, the linker takes several '.o' files, and needs to
+ capture them into a list.  This is naturally specified as:
      
+ 
+ 
      + ...
+ cl::list<std::string> InputFilenames(cl::Positional, cl::desc("<Input files>"), cl::OneOrMore);
+ ...
+ 
      
+ 
+ 
      This variable works just like a "vector<string>" object.  As
+ such, accessing the list is simple, just like above.  In this example, we used
+ the cl::OneOrMore modifier to inform the
+ CommandLine library that it is an error if the user does not specify any
+ .o files on our command line.  Again, this just reduces the amount of
+ checking we have to do.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Adding freeform text to help output
+ 
      
+ 
+ 
      
+ 
+ 
      As our program grows and becomes more mature, we may decide to put summary
+ information about what it does into the help output.  The help output is styled
+ to look similar to a Unix man page, providing concise information about
+ a program.  Unix man pages, however often have a description about what
+ the program does.  To add this to your CommandLine program, simply pass a third
+ argument to the cl::ParseCommandLineOptions
+ call in main.  This additional argument is then printed as the overview
+ information for your program, allowing you to include any additional information
+ that you want.  For example:
      
+ 
+ 
      + int main(int argc, char **argv) {
+   cl::ParseCommandLineOptions(argc, argv, " CommandLine compiler example\n\n"
+                               "  This program blah blah blah...\n");
+   ...
+ }
+ 
      
+ 
+ 
      Would yield the help output:
      
+ 
+ 
      + OVERVIEW: CommandLine compiler example
+ 
+   This program blah blah blah...
+ 
+ USAGE: compiler [options] <input file>
+ 
+ OPTIONS:
+   ...
+   -help             - display available options (--help-hidden for more)
+   -o <filename>     - Specify output filename
+ 
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Reference Guide
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Now that you know the basics of how to use the CommandLine library, this
+ section will give you the detailed information you need to tune how command line
+ options work, as well as information on more "advanced" command line option
+ processing capabilities.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Positional Arguments
+ 
      
+ 
+ 
      
+ 
+ 
      Positional arguments are those arguments that are not named, and are not
+ specified with a hyphen.  Positional arguments should be used when an option is
+ specified by its position alone.  For example, the standard Unix grep
+ tool takes a regular expression argument, and an optional filename to search
+ through (which defaults to standard input if a filename is not specified).
+ Using the CommandLine library, this would be specified as:
      
+ 
+ 
      + cl::opt<string> Regex   (cl::Positional, cl::desc("<regular expression>"), cl::Required);
+ cl::opt<string> Filename(cl::Positional, cl::desc("<input file>"), cl::init("-"));
+ 
      
+ 
+ 
      Given these two option declarations, the --help output for our grep
+ replacement would look like this:
      
+ 
+ 
      + USAGE: spiffygrep [options] <regular expression> <input file>
+ 
+ OPTIONS:
+   -help - display available options (--help-hidden for more)
+ 
      
+ 
+ 
      ... and the resultant program could be used just like the standard
+ grep tool.
      
+ 
+ 
      Positional arguments are sorted by their order of construction.  This means
+ that command line options will be ordered according to how they are listed in a
+ .cpp file, but will not have an ordering defined if the positional arguments
+ are defined in multiple .cpp files.  The fix for this problem is simply to
+ define all of your positional arguments in one .cpp file.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Specifying positional options with hyphens
+ 
      
+ 
+ 
      
+ 
+ 
      Sometimes you may want to specify a value to your positional argument that
+ starts with a hyphen (for example, searching for '-foo' in a file).  At
+ first, you will have trouble doing this, because it will try to find an argument
+ named '-foo', and will fail (and single quotes will not save you).
+ Note that the system grep has the same problem:
      
+ 
+ 
      +   $ spiffygrep '-foo' test.txt
+   Unknown command line argument '-foo'.  Try: spiffygrep --help'
+ 
+   $ grep '-foo' test.txt
+   grep: illegal option -- f
+   grep: illegal option -- o
+   grep: illegal option -- o
+   Usage: grep -hblcnsviw pattern file . . .
+ 
      
+ 
+ 
      The solution for this problem is the same for both your tool and the system
+ version: use the '--' marker.  When the user specifies '--' on
+ the command line, it is telling the program that all options after the
+ '--' should be treated as positional arguments, not options.  Thus, we
+ can use it like this:
      
+ 
+ 
      +   $ spiffygrep -- -foo test.txt
+     ...output...
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Determining absolute position with getPosition()
+ 
      
+ 
      
+   
      Sometimes an option can affect or modify the meaning of another option. For
+   example, consider gcc's -x LANG option. This tells
+   gcc to ignore the suffix of subsequent positional arguments and force
+   the file to be interpreted as if it contained source code in language
+   LANG. In order to handle this properly , you need to know the 
+   absolute position of each argument, especially those in lists, so their 
+   interaction(s) can be applied correctly. This is also useful for options like 
+   -llibname which is actually a positional argument that starts with 
+   a dash.
      
+   
      So, generally, the problem is that you have two cl::list variables
+   that interact in some way. To ensure the correct interaction, you can use the
+   cl::list::getPosition(optnum) method. This method returns the
+   absolute position (as found on the command line) of the optnum
+   item in the cl::list.
      
+   
      The idiom for usage is like this:
      
+   static cl::list<std::string> Files(cl::Positional, cl::OneOrMore);
+   static cl::listlt;std::string> Libraries("l", cl::ZeroOrMore);
+ 
+   int main(int argc, char**argv) {
+     // ...
+     std::vector<std::string>::iterator fileIt = Files.begin();
+     std::vector<std::string>::iterator libIt  = Libraries.begin();
+     unsigned libPos = 0, filePos = 0;
+     while ( 1 ) {
+       if ( libIt != Libraries.end() )
+         libPos = Libraries.getPosition( libIt - Libraries.begin() );
+       else
+         libPos = 0;
+       if ( fileIt != Files.end() )
+         filePos = Files.getPosition( fileIt - Files.begin() );
+       else
+         filePos = 0;
+ 
+       if ( filePos != 0 && (libPos == 0 || filePos < libPos) ) {
+         // Source File Is next
+         ++fileIt;
+       }
+       else if ( libPos != 0 && (filePos == 0 || libPos < filePos) ) {
+         // Library is next
+         ++libIt;
+       }
+       else
+         break; // we're done with the list
+     }
+   }
+   
      
+   
      Note that, for compatibility reasons, the cl::opt also supports an
+   unsigned getPosition() option that will provide the absolute position
+   of that option. You can apply the same approach as above with a 
+   cl::opt and a cl::list option as you can with two lists.
      
+ 
      
+ 
+ 
+ 
      
+   The cl::ConsumeAfter modifier
+ 
      
+ 
+ 
      
+ 
+ 
      The cl::ConsumeAfter formatting option is
+ used to construct programs that use "interpreter style" option processing.  With
+ this style of option processing, all arguments specified after the last
+ positional argument are treated as special interpreter arguments that are not
+ interpreted by the command line argument.
      
+ 
+ 
      As a concrete example, lets say we are developing a replacement for the
+ standard Unix Bourne shell (/bin/sh).  To run /bin/sh, first
+ you specify options to the shell itself (like -x which turns on trace
+ output), then you specify the name of the script to run, then you specify
+ arguments to the script.  These arguments to the script are parsed by the bourne
+ shell command line option processor, but are not interpreted as options to the
+ shell itself.  Using the CommandLine library, we would specify this as:
      
+ 
+ 
      + cl::opt<string> Script(cl::Positional, cl::desc("<input script>"), cl::init("-"));
+ cl::list<string>  Argv(cl::ConsumeAfter, cl::desc("<program arguments>..."));
+ cl::opt<bool>    Trace("x", cl::desc("Enable trace output"));
+ 
      
+ 
+ 
      which automatically provides the help output:
      
+ 
+ 
      + USAGE: spiffysh [options] <input script> <program arguments>...
+ 
+ OPTIONS:
+   -help - display available options (--help-hidden for more)
+   -x    - Enable trace output
+ 
      
+ 
+ 
      At runtime, if we run our new shell replacement as 'spiffysh -x test.sh
+ -a -x -y bar', the Trace variable will be set to true, the
+ Script variable will be set to "test.sh", and the
+ Argv list will contain ["-a", "-x", "-y", "bar"], because they
+ were specified after the last positional argument (which is the script
+ name).
      
+ 
+ 
      There are several limitations to when cl::ConsumeAfter options can
+ be specified.  For example, only one cl::ConsumeAfter can be specified
+ per program, there must be at least one positional
+ argument specified, there must not be any cl::list
+ positional arguments, and the cl::ConsumeAfter option should be a cl::list option.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Internal vs External Storage
+ 
      
+ 
+ 
      
+ 
+ 
      By default, all command line options automatically hold the value that they
+ parse from the command line.  This is very convenient in the common case,
+ especially when combined with the ability to define command line options in the
+ files that use them.  This is called the internal storage model.
      
+ 
+ 
      Sometimes, however, it is nice to separate the command line option processing
+ code from the storage of the value parsed.  For example, lets say that we have a
+ '-debug' option that we would like to use to enable debug information
+ across the entire body of our program.  In this case, the boolean value
+ controlling the debug code should be globally accessable (in a header file, for
+ example) yet the command line option processing code should not be exposed to
+ all of these clients (requiring lots of .cpp files to #include
+ CommandLine.h).
      
+ 
+ 
      To do this, set up your .h file with your option, like this for example:
      
+ 
+ 
      + // DebugFlag.h - Get access to the '-debug' command line option
+ //
+ 
+ // DebugFlag - This boolean is set to true if the '-debug' command line option
+ // is specified.  This should probably not be referenced directly, instead, use
+ // the DEBUG macro below.
+ //
+ extern bool DebugFlag;
+ 
+ // DEBUG macro - This macro should be used by code to emit debug information.
+ // In the '-debug' option is specified on the command line, and if this is a
+ // debug build, then the code specified as the option to the macro will be
+ // executed.  Otherwise it will not be.  Example:
+ //
+ // DEBUG(cerr << "Bitset contains: " << Bitset << "\n");
+ //
+ #ifdef NDEBUG
+ #define DEBUG(X)
+ #else
+ #define DEBUG(X) \
+   do { if (DebugFlag) { X; } } while (0)
+ #endif
+ 
      
+ 
+ 
      This allows clients to blissfully use the DEBUG() macro, or the
+ DebugFlag explicitly if they want to.  Now we just need to be able to
+ set the DebugFlag boolean when the option is set.  To do this, we pass
+ an additial argument to our command line argument processor, and we specify
+ where to fill in with the cl::location
+ attribute:
      
+ 
+ 
      + bool DebugFlag;      // the actual value
+ static cl::opt<bool, true>       // The parser
+ Debug("debug", cl::desc("Enable debug output"), cl::Hidden,
+       cl::location(DebugFlag));
+ 
      
+ 
+ 
      In the above example, we specify "true" as the second argument to
+ the cl::opt template, indicating that the template should
+ not maintain a copy of the value itself.  In addition to this, we specify the cl::location attribute, so that DebugFlag is
+ automatically set.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Option Attributes
+ 
      
+ 
+ 
      
+ 
+ 
      This section describes the basic attributes that you can specify on
+ options.
      
+ 
+ 
        
+ 
+ 
      • The option name attribute (which is required for all options, except positional options) specifies what the option name is.
+ This option is specified in simple double quotes:
+ 
+ 
        + cl::opt<bool> Quiet("quiet");
+ 
        
+ 
+ 
        • 
+ 
+ 
      • The cl::desc attribute specifies a
+ description for the option to be shown in the --help output for the
+ program.
        • 
+ 
+ 
      • The cl::value_desc attribute
+ specifies a string that can be used to fine tune the --help output for
+ a command line option.  Look here for an
+ example.
        • 
+ 
+ 
      • The cl::init attribute specifies an
+ inital value for a scalar option.  If this attribute is
+ not specified then the command line option value defaults to the value created
+ by the default constructor for the type. Warning: If you specify both
+ cl::init and cl::location for an option,
+ you must specify cl::location first, so that when the
+ command-line parser sees cl::init, it knows where to put the
+ initial value. (You will get an error at runtime if you don't put them in
+ the right order.)
        • 
+ 
+ 
      • The cl::location attribute where to
+ store the value for a parsed command line option if using external storage.  See
+ the section on Internal vs External Storage for more
+ information.
        • 
+ 
+ 
      • The cl::aliasopt attribute
+ specifies which option a cl::alias option is an alias
+ for.
        • 
+ 
+ 
      • The cl::values attribute specifies
+ the string-to-value mapping to be used by the generic parser.  It takes a
+ clEnumValEnd terminated list of (option, value, description) triplets 
+ that
+ specify the option name, the value mapped to, and the description shown in the
+ --help for the tool.  Because the generic parser is used most
+ frequently with enum values, two macros are often useful:
+ 
+ 
          
+ 
+ 
        1. The clEnumVal macro is used as a
+ nice simple way to specify a triplet for an enum.  This macro automatically
+ makes the option name be the same as the enum name.  The first option to the
+ macro is the enum, the second is the description for the command line
+ option.
          2. 
+ 
+ 
        2. The clEnumValN macro is used to
+ specify macro options where the option name doesn't equal the enum name.  For
+ this macro, the first argument is the enum value, the second is the flag name,
+ and the second is the description.
          3. 
+ 
+ 
        
+ 
+ You will get a compile time error if you try to use cl::values with a parser
+ that does not support it.
        • 
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Option Modifiers
+ 
      
+ 
+ 
      
+ 
+ 
      Option modifiers are the flags and expressions that you pass into the
+ constructors for cl::opt and cl::list.  These modifiers give you the ability to
+ tweak how options are parsed and how --help output is generated to fit
+ your application well.
      
+ 
+ 
      These options fall into five main catagories:
      
+ 
+ 
        
+ 
      1. Hiding an option from --help output
        2. 
+ 
      2. Controlling the number of occurrences
+                              required and allowed
        3. 
+ 
      3. Controlling whether or not a value must be
+                            specified
        4. 
+ 
      4. Controlling other formatting options
        5. 
+ 
      5. Miscellaneous option modifiers
        6. 
+ 
      
+ 
+ 
      It is not possible to specify two options from the same catagory (you'll get
+ a runtime error) to a single option, except for options in the miscellaneous
+ catagory.  The CommandLine library specifies defaults for all of these settings
+ that are the most useful in practice and the most common, which mean that you
+ usually shouldn't have to worry about these.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Hiding an option from --help output
+ 
      
+ 
+ 
      
+ 
+ 
      The cl::NotHidden, cl::Hidden, and
+ cl::ReallyHidden modifiers are used to control whether or not an option
+ appears in the --help and --help-hidden output for the
+ compiled program:
      
+ 
+ 
        
+ 
+ 
      • The cl::NotHidden modifier
+ (which is the default for cl::opt and cl::list options), indicates the option is to appear
+ in both help listings.
        • 
+ 
+ 
      • The cl::Hidden modifier (which is the
+ default for cl::alias options), indicates that
+ the option should not appear in the --help output, but should appear in
+ the --help-hidden output.
        • 
+ 
+ 
      • The cl::ReallyHidden modifier,
+ indicates that the option should not appear in any help output.
        • 
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Controlling the number of occurrences required and
+   allowed
+ 
      
+ 
+ 
      
+ 
+ 
      This group of options is used to control how many time an option is allowed
+ (or required) to be specified on the command line of your program.  Specifying a
+ value for this setting allows the CommandLine library to do error checking for
+ you.
      
+ 
+ 
      The allowed values for this option group are:
      
+ 
+ 
        
+ 
+ 
      • The cl::Optional modifier (which
+ is the default for the cl::opt and cl::alias classes) indicates that your program will
+ allow either zero or one occurrence of the option to be specified.
        • 
+ 
+ 
      • The cl::ZeroOrMore modifier
+ (which is the default for the cl::list class)
+ indicates that your program will allow the option to be specified zero or more
+ times.
        • 
+ 
+ 
      • The cl::Required modifier
+ indicates that the specified option must be specified exactly one time.
        • 
+ 
+ 
      • The cl::OneOrMore modifier
+ indicates that the option must be specified at least one time.
        • 
+ 
+ 
      • The cl::ConsumeAfter modifier is described in the Positional arguments section
        • 
+ 
+ 
      
+ 
+ 
      If an option is not specified, then the value of the option is equal to the
+ value specified by the cl::init attribute.  If
+ the cl::init attribute is not specified, the
+ option value is initialized with the default constructor for the data type.
      
+ 
+ 
      If an option is specified multiple times for an option of the cl::opt class, only the last value will be
+ retained.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Controlling whether or not a value must be specified
+ 
      
+ 
+ 
      
+ 
+ 
      This group of options is used to control whether or not the option allows a
+ value to be present.  In the case of the CommandLine library, a value is either
+ specified with an equal sign (e.g. '-index-depth=17') or as a trailing
+ string (e.g. '-o a.out').
      
+ 
+ 
      The allowed values for this option group are:
      
+ 
+ 
        
+ 
+ 
      • The cl::ValueOptional modifier
+ (which is the default for bool typed options) specifies that it is
+ acceptable to have a value, or not.  A boolean argument can be enabled just by
+ appearing on the command line, or it can have an explicit '-foo=true'.
+ If an option is specified with this mode, it is illegal for the value to be
+ provided without the equal sign.  Therefore '-foo true' is illegal.  To
+ get this behavior, you must use the cl::ValueRequired modifier.
        • 
+ 
+ 
      • The cl::ValueRequired modifier
+ (which is the default for all other types except for unnamed alternatives using the generic parser)
+ specifies that a value must be provided.  This mode informs the command line
+ library that if an option is not provides with an equal sign, that the next
+ argument provided must be the value.  This allows things like '-o
+ a.out' to work.
        • 
+ 
+ 
      • The cl::ValueDisallowed
+ modifier (which is the default for unnamed
+ alternatives using the generic parser) indicates that it is a runtime error
+ for the user to specify a value.  This can be provided to disallow users from
+ providing options to boolean options (like '-foo=true').
        • 
+ 
+ 
      
+ 
+ 
      In general, the default values for this option group work just like you would
+ want them to.  As mentioned above, you can specify the cl::ValueDisallowed modifier to a boolean
+ argument to restrict your command line parser.  These options are mostly useful
+ when extending the library.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Controlling other formatting options
+ 
      
+ 
+ 
      
+ 
+ 
      The formatting option group is used to specify that the command line option
+ has special abilities and is otherwise different from other command line
+ arguments.  As usual, you can only specify at most one of these arguments.
      
+ 
+ 
        
+ 
+ 
      • The cl::NormalFormatting
+ modifier (which is the default all options) specifies that this option is
+ "normal".
        • 
+ 
+ 
      • The cl::Positional modifier
+ specifies that this is a positional argument, that does not have a command line
+ option associated with it.  See the Positional
+ Arguments section for more information.
        • 
+ 
+ 
      • The cl::ConsumeAfter modifier
+ specifies that this option is used to capture "interpreter style" arguments.  See this section for more information.
        • 
+ 
+ 
      • The cl::Prefix modifier specifies
+ that this option prefixes its value.  With 'Prefix' options, the equal sign does
+ not separate the value from the option name specified. Instead, the value is
+ everything after the prefix, including any equal sign if present. This is useful
+ for processing odd arguments like -lmalloc and -L/usr/lib in a
+ linker tool or -DNAME=value in a compiler tool.   Here, the 
+ 'l', 'D' and 'L' options are normal string (or list)
+ options, that have the cl::Prefix modifier added to 
+ allow the CommandLine library to recognize them.  Note that 
+ cl::Prefix options must not have the cl::ValueDisallowed modifier specified.
        • 
+ 
+ 
      • The cl::Grouping modifier is used
+ to implement unix style tools (like ls) that have lots of single letter
+ arguments, but only require a single dash.  For example, the 'ls -labF'
+ command actually enables four different options, all of which are single
+ letters.  Note that cl::Grouping options cannot have
+ values.
        • 
+ 
+ 
      
+ 
+ 
      The CommandLine library does not restrict how you use the cl::Prefix or cl::Grouping
+ modifiers, but it is possible to specify ambiguous argument settings.  Thus, it
+ is possible to have multiple letter options that are prefix or grouping options,
+ and they will still work as designed.
      
+ 
+ 
      To do this, the CommandLine library uses a greedy algorithm to parse the
+ input option into (potentially multiple) prefix and grouping options.  The
+ strategy basically looks like this:
      
+ 
+ 
      parse(string OrigInput) {
+ 
+ 
        
+ 
      1. string input = OrigInput;
+ 
      2. if (isOption(input)) return getOption(input).parse();    // Normal option
+ 
      3. while (!isOption(input) && !input.empty()) input.pop_back();    // Remove the last letter
+ 
      4. if (input.empty()) return error();    // No matching option
+ 
      5. if (getOption(input).isPrefix())
        
+   return getOption(input).parse(input);        
+ 
      6. while (!input.empty()) {    // Must be grouping options
        
+   getOption(input).parse();
        
+   OrigInput.erase(OrigInput.begin(), OrigInput.begin()+input.length());
        
+   input = OrigInput;
        
+   while (!isOption(input) && !input.empty()) input.pop_back();
        
+ }        
+ 
      7. if (!OrigInput.empty()) error();
        8. 
+ 
+ 
      
+ 
+ 
      }
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Miscellaneous option modifiers
+ 
      
+ 
+ 
      
+ 
+ 
      The miscellaneous option modifiers are the only flags where you can specify
+ more than one flag from the set: they are not mutually exclusive.  These flags
+ specify boolean properties that modify the option.
      
+ 
+ 
        
+ 
+ 
      • The cl::CommaSeparated modifier
+ indicates that any commas specified for an option's value should be used to
+ split the value up into multiple values for the option.  For example, these two
+ options are equivalent when cl::CommaSeparated is specified:
+ "-foo=a -foo=b -foo=c" and "-foo=a,b,c".  This option only
+ makes sense to be used in a case where the option is allowed to accept one or
+ more values (i.e. it is a cl::list option).
        • 
+ 
+ 
      • The
+ cl::PositionalEatsArgs modifier (which only applies to
+ positional arguments, and only makes sense for lists) indicates that positional
+ argument should consume any strings after it (including strings that start with
+ a "-") up until another recognized positional argument.  For example, if you
+ have two "eating" positional arguments "pos1" and "pos2" the
+ string "-pos1 -foo -bar baz -pos2 -bork" would cause the "-foo -bar
+ -baz" strings to be applied to the "-pos1" option and the
+ "-bork" string to be applied to the "-pos2" option.
        • 
+ 
+ 
      
+ 
+ 
      So far, these are the only two miscellaneous option modifiers.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Top-Level Classes and Functions
+ 
      
+ 
+ 
      
+ 
+ 
      Despite all of the built-in flexibility, the CommandLine option library
+ really only consists of one function (cl::ParseCommandLineOptions)
+ and three main classes: cl::opt, cl::list, and cl::alias.  This section describes these three
+ classes in detail.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The cl::ParseCommandLineOptions
+   function
+ 
      
+ 
+ 
      
+ 
+ 
      The cl::ParseCommandLineOptions function is designed to be called
+ directly from main, and is used to fill in the values of all of the
+ command line option variables once argc and argv are
+ available.
      
+ 
+ 
      The cl::ParseCommandLineOptions function requires two parameters
+ (argc and argv), but may also take an optional third parameter
+ which holds additional extra text to emit when the
+ --help option is invoked.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The cl::ParseEnvironmentOptions
+   function
+ 
      
+ 
+ 
      
+ 
+ 
      The cl::ParseEnvironmentOptions function has mostly the same effects
+ as cl::ParseCommandLineOptions,
+ except that it is designed to take values for options from an environment
+ variable, for those cases in which reading the command line is not convenient or
+ not desired. It fills in the values of all the command line option variables
+ just like cl::ParseCommandLineOptions
+ does.
      
+ 
+ 
      It takes three parameters: first, the name of the program (since
+ argv may not be available, it can't just look in argv[0]),
+ second, the name of the environment variable to examine, and third, the optional
+ additional extra text to emit when the
+ --help option is invoked.
      
+ 
+ 
      cl::ParseEnvironmentOptions will break the environment
+ variable's value up into words and then process them using
+ cl::ParseCommandLineOptions.
+ Note: Currently cl::ParseEnvironmentOptions does not support
+ quoting, so an environment variable containing -option "foo bar" will
+ be parsed as three words, -option, "foo, and bar",
+ which is different from what you would get from the shell with the same
+ input.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The cl::opt class
+ 
      
+ 
+ 
      
+ 
+ 
      The cl::opt class is the class used to represent scalar command line
+ options, and is the one used most of the time.  It is a templated class which
+ can take up to three arguments (all except for the first have default values
+ though):
      
+ 
+ 
      + namespace cl {
+   template <class DataType, bool ExternalStorage = false,
+             class ParserClass = parser<DataType> >
+   class opt;
+ }
+ 
      
+ 
+ 
      The first template argument specifies what underlying data type the command
+ line argument is, and is used to select a default parser implementation.  The
+ second template argument is used to specify whether the option should contain
+ the storage for the option (the default) or whether external storage should be
+ used to contain the value parsed for the option (see Internal
+ vs External Storage for more information).
      
+ 
+ 
      The third template argument specifies which parser to use.  The default value
+ selects an instantiation of the parser class based on the underlying
+ data type of the option.  In general, this default works well for most
+ applications, so this option is only used when using a custom parser.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The cl::list class
+ 
      
+ 
+ 
      
+ 
+ 
      The cl::list class is the class used to represent a list of command
+ line options.  It too is a templated class which can take up to three
+ arguments:
      
+ 
+ 
      + namespace cl {
+   template <class DataType, class Storage = bool,
+             class ParserClass = parser<DataType> >
+   class list;
+ }
+ 
      
+ 
+ 
      This class works the exact same as the cl::opt class, except that the second argument is
+ the type of the external storage, not a boolean value.  For this class,
+ the marker type 'bool' is used to indicate that internal storage should
+ be used.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The cl::alias class
+ 
      
+ 
+ 
      
+ 
+ 
      The cl::alias class is a nontemplated class that is used to form
+ aliases for other arguments.
      
+ 
+ 
      + namespace cl {
+   class alias;
+ }
+ 
      
+ 
+ 
      The cl::aliasopt attribute should be
+ used to specify which option this is an alias for.  Alias arguments default to
+ being Hidden, and use the aliased options parser to do
+ the conversion from string to data.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The cl::extrahelp class
+ 
      
+ 
+ 
      
+ 
+ 
      The cl::extrahelp class is a nontemplated class that allows extra
+ help text to be printed out for the --help option.
      
+ 
+ 
      + namespace cl {
+   struct extrahelp;
+ }
+ 
      
+ 
+ 
      To use the extrahelp, simply construct one with a const char* 
+ parameter to the constructor. The text passed to the constructor will be printed
+ at the bottom of the help message, verbatim. Note that multiple
+ cl::extrahelp can be used but this practice is discouraged. If
+ your tool needs to print additional help information, put all that help into a
+ single cl::extrahelp instance.
      
+ 
      For example:
      
+ 
      +   cl::extrahelp("\nADDITIONAL HELP:\n\n  This is the extra help\n");
+ 
      
+ 
      
+ 
+ 
+ 
      
+   Builtin parsers
+ 
      
+ 
+ 
      
+ 
+ 
      Parsers control how the string value taken from the command line is
+ translated into a typed value, suitable for use in a C++ program.  By default,
+ the CommandLine library uses an instance of parser<type> if the
+ command line option specifies that it uses values of type 'type'.
+ Because of this, custom option processing is specified with specializations of
+ the 'parser' class.
      
+ 
+ 
      The CommandLine library provides the following builtin parser
+ specializations, which are sufficient for most applications. It can, however,
+ also be extended to work with new data types and new ways of interpreting the
+ same data.  See the Writing a Custom Parser for more
+ details on this type of library extension.
      
+ 
+ 
        
+ 
+ 
      • The generic parser<t> parser
+ can be used to map strings values to any data type, through the use of the cl::values property, which specifies the mapping
+ information.  The most common use of this parser is for parsing enum values,
+ which allows you to use the CommandLine library for all of the error checking to
+ make sure that only valid enum values are specified (as opposed to accepting
+ arbitrary strings).  Despite this, however, the generic parser class can be used
+ for any data type.
        • 
+ 
+ 
      • The parser<bool> specialization
+ is used to convert boolean strings to a boolean value.  Currently accepted
+ strings are "true", "TRUE", "True", "1",
+ "false", "FALSE", "False", and "0".
        • 
+ 
+ 
      • The parser<string>
+ specialization simply stores the parsed string into the string value
+ specified.  No conversion or modification of the data is performed.
        • 
+ 
+ 
      • The parser<int> specialization
+ uses the C strtol function to parse the string input.  As such, it will
+ accept a decimal number (with an optional '+' or '-' prefix) which must start
+ with a non-zero digit.  It accepts octal numbers, which are identified with a
+ '0' prefix digit, and hexadecimal numbers with a prefix of
+ '0x' or '0X'.
        • 
+ 
+ 
      • The parser<double> and
+ parser<float> specializations use the standard C
+ strtod function to convert floating point strings into floating point
+ values.  As such, a broad range of string formats is supported, including
+ exponential notation (ex: 1.7e15) and properly supports locales.
+ 
        • 
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Extension Guide
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Although the CommandLine library has a lot of functionality built into it
+ already (as discussed previously), one of its true strengths lie in its
+ extensibility.  This section discusses how the CommandLine library works under
+ the covers and illustrates how to do some simple, common, extensions.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Writing a custom parser
+ 
      
+ 
+ 
      
+ 
+ 
      One of the simplest and most common extensions is the use of a custom parser.
+ As discussed previously, parsers are the portion
+ of the CommandLine library that turns string input from the user into a
+ particular parsed data type, validating the input in the process.
      
+ 
+ 
      There are two ways to use a new parser:
      
+ 
+ 
        
+ 
+ 
      1. 
+ 
+ 
        Specialize the cl::parser template for
+ your custom data type.
        
+ 
+ 
        This approach has the advantage that users of your custom data type will
+ automatically use your custom parser whenever they define an option with a value
+ type of your data type.  The disadvantage of this approach is that it doesn't
+ work if your fundemental data type is something that is already supported.
        
+ 
+ 
        2. 
+ 
+ 
      2. 
+ 
+ 
        Write an independent class, using it explicitly from options that need
+ it.
        
+ 
+ 
        This approach works well in situations where you would line to parse an
+ option using special syntax for a not-very-special data-type.  The drawback of
+ this approach is that users of your parser have to be aware that they are using
+ your parser, instead of the builtin ones.
        
+ 
+ 
        3. 
+ 
+ 
      
+ 
+ 
      To guide the discussion, we will discuss a custom parser that accepts file
+ sizes, specified with an optional unit after the numeric size.  For example, we
+ would like to parse "102kb", "41M", "1G" into the appropriate integer value.  In
+ this case, the underlying data type we want to parse into is
+ 'unsigned'.  We choose approach #2 above because we don't want to make
+ this the default for all unsigned options.
      
+ 
+ 
      To start out, we declare our new FileSizeParser class:
      
+ 
+ 
      + struct FileSizeParser : public cl::basic_parser<unsigned> {
+   // parse - Return true on error.
+   bool parse(cl::Option &O, const char *ArgName, const std::string &ArgValue,
+              unsigned &Val);
+ };
+ 
      
+ 
+ 
      Our new class inherits from the cl::basic_parser template class to
+ fill in the default, boiler plate, code for us.  We give it the data type that
+ we parse into (the last argument to the parse method so that clients of
+ our custom parser know what object type to pass in to the parse method (here we
+ declare that we parse into 'unsigned' variables.
      
+ 
+ 
      For most purposes, the only method that must be implemented in a custom
+ parser is the parse method.  The parse method is called
+ whenever the option is invoked, passing in the option itself, the option name,
+ the string to parse, and a reference to a return value.  If the string to parse
+ is not well formed, the parser should output an error message and return true.
+ Otherwise it should return false and set 'Val' to the parsed value.  In
+ our example, we implement parse as:
      
+ 
+ 
      + bool FileSizeParser::parse(cl::Option &O, const char *ArgName,
+                            const std::string &Arg, unsigned &Val) {
+   const char *ArgStart = Arg.c_str();
+   char *End;
+  
+   // Parse integer part, leaving 'End' pointing to the first non-integer char
+   Val = (unsigned)strtol(ArgStart, &End, 0);
+ 
+   while (1) {
+     switch (*End++) {
+     case 0: return false;   // No error
+     case 'i':               // Ignore the 'i' in KiB if people use that
+     case 'b': case 'B':     // Ignore B suffix
+       break;
+ 
+     case 'g': case 'G': Val *= 1024*1024*1024; break;
+     case 'm': case 'M': Val *= 1024*1024;      break;
+     case 'k': case 'K': Val *= 1024;           break;
+ 
+     default:
+       // Print an error message if unrecognized character!
+       return O.error(": '" + Arg + "' value invalid for file size argument!");
+     }
+   }
+ }
+ 
      
+ 
+ 
      This function implements a very simple parser for the kinds of strings we are
+ interested in.  Although it has some holes (it allows "123KKK" for
+ example), it is good enough for this example.  Note that we use the option
+ itself to print out the error message (the error method always returns
+ true) in order to get a nice error message (shown below).  Now that we have our
+ parser class, we can use it like this:
      
+ 
+ 
      + static cl::opt<unsigned, false, FileSizeParser>
+ MFS("max-file-size", cl::desc("Maximum file size to accept"),
+     cl::value_desc("size"));
+ 
      
+ 
+ 
      Which adds this to the output of our program:
      
+ 
+ 
      + OPTIONS:
+   -help                 - display available options (--help-hidden for more)
+   ...
+   -max-file-size=<size> - Maximum file size to accept
+ 
      
+ 
+ 
      And we can test that our parse works correctly now (the test program just
+ prints out the max-file-size argument value):
      
+ 
+ 
      + $ ./test
+ MFS: 0
+ $ ./test -max-file-size=123MB
+ MFS: 128974848
+ $ ./test -max-file-size=3G
+ MFS: 3221225472
+ $ ./test -max-file-size=dog
+ -max-file-size option: 'dog' value invalid for file size argument!
+ 
      
+ 
+ 
      It looks like it works.  The error message that we get is nice and helpful,
+ and we seem to accept reasonable file sizes.  This wraps up the "custom parser"
+ tutorial.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Exploiting external storage
+ 
      
+ 
+ 
      
+   
      Several of the LLVM libraries define static cl::opt instances that
+   will automatically be included in any program that links with that library.
+   This is a feature. However, sometimes it is necessary to know the value of the
+   command line option outside of the library. In these cases the library does or
+   should provide an external storage location that is accessible to users of the
+   library. Examples of this include the llvm::DebugFlag exported by the
+   lib/Support/Debug.cpp file and the llvm::TimePassesIsEnabled
+   flag exported by the lib/VMCore/Pass.cpp file.
      
+ 
+ 
      TODO: complete this section
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Dynamically adding command line options
+ 
      
+ 
+ 
      
+ 
+ 
      TODO: fill in this section
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Chris Lattner
      
+   LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/CompilerDriver.html
diff -c /dev/null llvm-www/releases/1.4/docs/CompilerDriver.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/CompilerDriver.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,823 ----
+ 
+ 
+ 
+   
+   The LLVM Compiler Driver (llvmc)
+   
+   
+   
+ 
+ 
+ 
      The LLVM Compiler Driver (llvmc)
      
+ 
      NOTE: This document is a work in progress!
      
+ 
        
+   
      1. Abstract
        2. 
+   
      2. Introduction
+     
          
+       
        1. Purpose
          2. 
+       
        2. Operation
          3. 
+       
        3. Phases
          4. 
+       
        4. Actions
          5. 
+     
        
+   
        3. 
+   
      3. Configuration
+     
          
+       
        1. Overview
          2. 
+       
        2. Configuration Files
          3. 
+       
        3. Syntax
          4. 
+       
        4. Substitutions
          5. 
+       
        5. Sample Config File
          6. 
+     
        
+   
      4. Glossary
+ 
      
+ 
      
+ 
      Written by Reid Spencer
+ 
      
+ 
      
+ 
+ 
+ 
       Abstract
      
+ 
+ 
      
+   
      This document describes the requirements, design, and configuration of the
+   LLVM compiler driver, llvmc.  The compiler driver knows about LLVM's 
+   tool set and can be configured to know about a variety of compilers for 
+   source languages.  It uses this knowledge to execute the tools necessary 
+   to accomplish general compilation, optimization, and linking tasks. The main 
+   purpose of llvmc is to provide a simple and consistent interface to 
+   all compilation tasks. This reduces the burden on the end user who can just 
+   learn to use llvmc instead of the entire LLVM tool set and all the
+   source language compilers compatible with LLVM.
      
+ 
      
+ 
+ 
       Introduction
      
+ 
+ 
      
+   
      The llvmc tool is a configurable compiler 
+   driver. As such, it isn't a compiler, optimizer, 
+   or a linker itself but it drives (invokes) other software that perform those 
+   tasks. If you are familiar with the GNU Compiler Collection's gcc 
+   tool, llvmc is very similar.
      
+   
      The following introductory sections will help you understand why this tool
+   is necessary and what it does.
      
+ 
      
+ 
+ 
+ 
      Purpose
      
+ 
      
+   
      llvmc was invented to make compilation of user programs with 
+   LLVM-based tools easier. To accomplish this, llvmc strives to:
      
+   
        
+     
      • Be the single point of access to most of the LLVM tool set.
        • 
+     
      • Hide the complexities of the LLVM tools through a single interface.
        • 
+     
      • Provide a consistent interface for compiling all languages.
        • 
+   
      
+   
      Additionally, llvmc makes it easier to write a compiler for use
+   with LLVM, because it:
      
+   
        
+     
      • Makes integration of existing non-LLVM tools simple.
        • 
+     
      • Extends the capabilities of minimal compiler tools by optimizing their
+     output.
        • 
+     
      • Reduces the number of interfaces a compiler writer must know about
+     before a working compiler can be completed (essentially only the VMCore
+     interfaces need to be understood).
        • 
+     
      • Supports source language translator invocation via both dynamically
+     loadable shared objects and invocation of an executable.
        • 
+   
      
+ 
      
+ 
+ 
+ 
      Operation
      
+ 
      
+   
      At a high level, llvmc operation is very simple.  The basic action
+   taken by llvmc is to simply invoke some tool or set of tools to fill 
+   the user's request for compilation. Every execution of llvmctakes the 
+   following sequence of steps:
      
+   
      
+     
      Collect Command Line Options
      
+     
      The command line options provide the marching orders to llvmc 
+     on what actions it should perform. This is the request the user is making 
+     of llvmc and it is interpreted first. See the llvmc
+     manual page for details on the
+     options.
      
+     
      Read Configuration Files
      
+     
      Based on the options and the suffixes of the filenames presented, a set 
+     of configuration files are read to configure the actions llvmc will 
+     take.  Configuration files are provided by either LLVM or the 
+     compiler tools that llvmc invokes. These files determine what 
+     actions llvmc will take in response to the user's request. See 
+     the section on configuration for more details.
+     
      
+     
      Determine Phases To Execute
      
+     
      Based on the command line options and configuration files,
+     llvmc determines the compilation phases that
+     must be executed by the user's request. This is the primary work of
+     llvmc.
      
+     
      Determine Actions To Execute
      
+     
      Each phase to be executed can result in the
+     invocation of one or more actions. An action is
+     either a whole program or a function in a dynamically linked shared library. 
+     In this step, llvmc determines the sequence of actions that must be 
+     executed. Actions will always be executed in a deterministic order.
      
+     
      Execute Actions
      
+     
      The actions necessary to support the user's
+     original request are executed sequentially and deterministically. All 
+     actions result in either the invocation of a whole program to perform the 
+     action or the loading of a dynamically linkable shared library and invocation 
+     of a standard interface function within that library.
       
+     
      Termination
      
+     
      If any action fails (returns a non-zero result code), llvmc
+     also fails and returns the result code from the failing action. If
+     everything succeeds, llvmc will return a zero result code.
      
+   
      
+   
      llvmc's operation must be simple, regular and predictable. 
+   Developers need to be able to rely on it to take a consistent approach to
+   compilation. For example, the invocation:
      
+   
+     llvmc -O2 x.c y.c z.c -o xyz
+   
      must produce exactly the same results as:
      
+   
      
+     llvmc -O2 x.c -o x.o
+     llvmc -O2 y.c -o y.o
+     llvmc -O2 z.c -o z.o
+     llvmc -O2 x.o y.o z.o -o xyz
      
+   
      To accomplish this, llvmc uses a very simple goal oriented
+   procedure to do its work. The overall goal is to produce a functioning
+   executable. To accomplish this, llvmc always attempts to execute a 
+   series of compilation phases in the same sequence. 
+   However, the user's options to llvmc can cause the sequence of phases 
+   to start in the middle or finish early.
      
+ 
      
+ 
+ 
+ 
      Phases 
      
+ 
      
+   
      llvmc breaks every compilation task into the following five 
+   distinct phases:
      
+   
      Preprocessing
      Not all languages support preprocessing; 
+     but for those that do, this phase can be invoked. This phase is for 
+     languages that provide combining, filtering, or otherwise altering with the 
+     source language input before the translator parses it. Although C and C++ 
+     are the most common users of this phase, other languages may provide their 
+     own preprocessor (whether its the C pre-processor or not).
      
+   
      
+   
      Translation
      The translation phase converts the source 
+     language input into something that LLVM can interpret and use for 
+     downstream phases. The translation is essentially from "non-LLVM form" to
+     "LLVM form".
      
+   
      
+   
      Optimization
      Once an LLVM Module has been obtained from 
+     the translation phase, the program enters the optimization phase. This phase 
+     attempts to optimize all of the input provided on the command line according 
+     to the options provided.
      
+   
      
+   
      Linking
      The inputs are combined to form a complete
+     program.
      
+   
      
+   
      The following table shows the inputs, outputs, and command line options
+   applicable to each phase.
      
+   
+     
+       
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+       
+     
+     
+       
+       
+       
+       
+     
+     
+       
+       
+       
+       
+     
+   
      PhaseInputsOutputsOptions
      Preprocessing
      • Source Language File
      • Source Language File
      
+           
      -E
      
+           
      Stops the compilation after preprocessing
      
+       
      Translation
        
+           
      • Source Language File
        • 
+       
        
+           
      • LLVM Assembly
        • 
+           
      • LLVM Bytecode
        • 
+           
      • LLVM C++ IR
        • 
+       
      
+           
      -c
      
+           
      Stops the compilation after translation so that optimization and 
+           linking are not done.
      
+           
      -S
      
+           
      Stops the compilation before object code is written so that only
+           assembly code remains.
      
+       
      Optimization
        
+           
      • LLVM Assembly
        • 
+           
      • LLVM Bytecode
        • 
+       
        
+           
      • LLVM Bytecode
        • 
+       
      
+           
      -Ox
+           
      This group of options controls the amount of optimization 
+           performed.
      
+       
      Linking
        
+           
      • LLVM Bytecode
        • 
+           
      • Native Object Code
        • 
+           
      • LLVM Library
        • 
+           
      • Native Library
        • 
+       
        
+           
      • LLVM Bytecode Executable
        • 
+           
      • Native Executable
        • 
+       
      
+           
      -L
      Specifies a path for library search.
      
+           
      -l
      Specifies a library to link in.
      
+       
      
+ 
      
+ 
+ 
+ 
      Actions
      
+ 
      
+   
      An action, with regard to llvmc is a basic operation that it takes
+   in order to fulfill the user's request. Each phase of compilation will invoke
+   zero or more actions in order to accomplish that phase.
      
+   
      Actions come in two forms:
      
+   
        
+     
      • Invokable Executables
        • 
+     
      • Functions in a shared library
        • 
+   
      
+ 
      
+ 
+ 
+ 
      Configuration
      
+ 
+ 
      
+   
      This section of the document describes the configuration files used by
+   llvmc.  Configuration information is relatively static for a 
+   given release of LLVM and a compiler tool. However, the details may 
+   change from release to release of either.  Users are encouraged to simply use 
+   the various options of the llvmc command and ignore the configuration 
+   of the tool. These configuration files are for compiler writers and LLVM 
+   developers. Those wishing to simply use llvmc don't need to understand 
+   this section but it may be instructive on how the tool works.
      
+ 
      
+ 
+ 
+ 
      Overview
      
+ 
      
+ 
      llvmc is highly configurable both on the command line and in 
+ configuration files. The options it understands are generic, consistent and 
+ simple by design.  Furthermore, the llvmc options apply to the 
+ compilation of any LLVM enabled programming language. To be enabled as a 
+ supported source language compiler, a compiler writer must provide a 
+ configuration file that tells llvmc how to invoke the compiler 
+ and what its capabilities are. The purpose of the configuration files then 
+ is to allow compiler writers to specify to llvmc how the compiler 
+ should be invoked. Users may but are not advised to alter the compiler's 
+ llvmc configuration.
      
+ 
+ 
      Because llvmc just invokes other programs, it must deal with the
+ available command line options for those programs regardless of whether they
+ were written for LLVM or not. Furthermore, not all compiler tools will
+ have the same capabilities. Some compiler tools will simply generate LLVM assembly
+ code, others will be able to generate fully optimized byte code. In general,
+ llvmc doesn't make any assumptions about the capabilities or command 
+ line options of a sub-tool. It simply uses the details found in the 
+ configuration files and leaves it to the compiler writer to specify the 
+ configuration correctly.
      
+ 
+ 
      This approach means that new compiler tools can be up and working very
+ quickly. As a first cut, a tool can simply compile its source to raw
+ (unoptimized) bytecode or LLVM assembly and llvmc can be configured 
+ to pick up the slack (translate LLVM assembly to bytecode, optimize the 
+ bytecode, generate native assembly, link, etc.).   In fact, the compiler tools 
+ need not use any LLVM libraries, and it could be written in any language 
+ (instead of C++).  The configuration data will allow the full range of 
+ optimization, assembly, and linking capabilities that LLVM provides to be added 
+ to these kinds of tools.  Enabling the rapid development of front-ends is one 
+ of the primary goals of llvmc.
      
+ 
+ 
      As a compiler tool matures, it may utilize the LLVM libraries and tools 
+ to more efficiently produce optimized bytecode directly in a single compilation 
+ and optimization program. In these cases, multiple tools would not be needed 
+ and the configuration data for the compiler would change.
      
+ 
+ 
      Configuring llvmc to the needs and capabilities of a source language 
+ compiler is relatively straight-forward.  A compiler writer must provide a 
+ definition of what to do for each of the five compilation phases for each of 
+ the optimization levels. The specification consists simply of prototypical 
+ command lines into which llvmc can substitute command line
+ arguments and file names. Note that any given phase can be completely blank if
+ the source language's compiler combines multiple phases into a single program.
+ For example, quite often pre-processing, translation, and optimization are
+ combined into a single program. The specification for such a compiler would have
+ blank entries for pre-processing and translation but a full command line for
+ optimization.
      
+ 
      
+ 
+ 
+ 
      Configuration Files
      
+ 
      File Contents
      
+ 
      
+   
      Each configuration file provides the details for a single source language
+   that is to be compiled.  This configuration information tells llvmc 
+   how to invoke the language's pre-processor, translator, optimizer, assembler
+   and linker. Note that a given source language needn't provide all these tools
+   as many of them exist in llvm currently.
      
+ 
      
+ 
+ 
+ 
      Directory Search
      
+ 
      
+   
      llvmc always looks for files of a specific name. It uses the
+   first file with the name its looking for by searching directories in the
+   following order:
      
+   
        
+     
      1. Any directory specified by the -config-dir option will be
+     checked first.
        2. 
+     
      2. If the environment variable LLVM_CONFIG_DIR is set, and it contains
+     the name of a valid directory, that directory will be searched next.
        3. 
+     
      3. If the user's home directory (typically /home/user contains 
+     a sub-directory named .llvm and that directory contains a 
+     sub-directory named etc then that directory will be tried 
+     next.
        4. 
+     
      4. If the LLVM installation directory (typically /usr/local/llvm
+     contains a sub-directory named etc then that directory will be
+     tried last.
        5. 
+     
      5. A standard "system" directory will be searched next. This is typically
+     /etc/llvm on UNIX™ and C:\WINNT on Microsoft
+     Windows™.
        6. 
+     
      6. If the configuration file sought still can't be found, llvmc
+     will print an error message and exit.
        7. 
+   
      
+   
      The first file found in this search will be used. Other files with the 
+   same name will be ignored even if they exist in one of the subsequent search
+   locations.
      
+ 
      
+ 
+ 
      File Names
      
+ 
      
+   
      In the directories searched, each configuration file is given a specific
+   name to foster faster lookup (so llvmc doesn't have to do directory searches).
+   The name of a given language specific configuration file is simply the same 
+   as the suffix used to identify files containing source in that language. 
+   For example, a configuration file for C++ source might be named 
+   cpp, C, or cxx. For languages that support multiple
+   file suffixes, multiple (probably identical) files (or symbolic links) will
+   need to be provided.
      
+ 
      
+ 
+ 
      What Gets Read
      
+ 
      
+   
      Which configuration files are read depends on the command line options and 
+   the suffixes of the file names provided on llvmc's command line. Note
+   that the -x LANGUAGE option alters the language that llvmc
+   uses for the subsequent files on the command line.  Only the configuration 
+   files actually needed to complete llvmc's task are read. Other 
+   language specific files will be ignored.
      
+ 
      
+ 
+ 
+ 
      Syntax
      
+ 
      
+   
      The syntax of the configuration files is very simple and somewhat
+   compatible with Java's property files. Here are the syntax rules:
      
+   
        
+     
      • The file encoding is ASCII.
        • 
+     
      • The file is line oriented. There should be one configuration definition 
+     per line. Lines are terminated by the newline (0x0A) and/or carriage return
+     characters (0x0D)
        • 
+     
      • A backslash (\) before a newline causes the newline to be
+     ignored. This is useful for line continuation of long definitions. A
+     backslash anywhere else is recognized as a backslash.
        • 
+     
      • A configuration item consists of a name, an = and a value.
        • 
+     
      • A name consists of a sequence of identifiers separated by period.
        • 
+     
      • An identifier consists of specific keywords made up of only lower case
+     and upper case letters (e.g. lang.name).
        • 
+     
      • Values come in four flavors: booleans, integers, commands and 
+     strings.
        • 
+     
      • Valid "false" boolean values are false False FALSE no No NO
+       off Off and OFF.
        • 
+     
      • Valid "true" boolean values are true True TRUE yes Yes YES
+       on On and ON.
        • 
+     
      • Integers are simply sequences of digits.
        • 
+     
      • Commands start with a program name and are followed by a sequence of
+     words that are passed to that program as command line arguments. Program
+     arguments that begin and end with the % sign will have their value
+     substituted. Program names beginning with / are considered to be
+     absolute. Otherwise the PATH will be applied to find the program to
+     execute.
        • 
+     
      • Strings are composed of multiple sequences of characters from the
+     character class [-A-Za-z0-9_:%+/\\|,] separated by white
+     space.
        • 
+     
      • White space on a line is folded. Multiple blanks or tabs will be
+     reduced to a single blank.
        • 
+     
      • White space before the configuration item's name is ignored.
        • 
+     
      • White space on either side of the = is ignored.
        • 
+     
      • White space in a string value is used to separate the individual
+     components of the string value but otherwise ignored.
        • 
+     
      • Comments are introduced by the # character. Everything after a
+     # and before the end of line is ignored.
        • 
+   
      
+ 
      
+ 
+ 
+ 
      Configuration Items
      
+ 
      
+   
      The table below provides definitions of the allowed configuration items
+   that may appear in a configuration file. Every item has a default value and
+   does not need to appear in the configuration file. Missing items will have the 
+   default value. Each identifier may appear as all lower case, first letter
+   capitalized or all upper case.
      
+   
+     
+       
+         
+         
+         
+         
+       
+       
+       
+         
+         
+         
+         
+       
+       
+       
+         
+         
+         
+         
+       
+       
+         
+         
+         
+         
+       
+       
+         
+         
+         
+         
+       
+       
+         
+         
+         
+         
+       
+       
+         
+         
+         
+         
+       
+       
+         
+         
+         
+         
+       
+       
+       
+         
+         
+         
+         
+       
+       
+         
+         
+         
+         
+       
+       
+       
+         
+         
+         
+         
+       
+       
+         
+         
+         
+         
+       
+       
+         
+         
+         
+         
+       
+       
+       
+         
+         
+         
+         
+       
+       
+         
+         
+         
+         
+       
+       
+         
+         
+         
+         
+       
+       
+         
+         
+         
+         
+       
+       
+       
+         
+         
+         
+         
+       
+     
+   
      NameValue TypeDescriptionDefault
      LLVMC ITEMS
      versionstringProvides the version string for the contents of this
+           configuration file. What is accepted as a legal configuration file
+           will change over time and this item tells llvmc which version
+           should be expected.b
      LANG ITEMS
      lang.namestringProvides the common name for a language definition. 
+           For example "C++", "Pascal", "FORTRAN", etc.blank
      lang.opt1stringSpecifies the parameters to give the optimizer when
+           -O1 is specified on the llvmc command line.-simplifycfg -instcombine -mem2reg
      lang.opt2stringSpecifies the parameters to give the optimizer when
+           -O2 is specified on the llvmc command line.TBD
      lang.opt3stringSpecifies the parameters to give the optimizer when
+           -O3 is specified on the llvmc command line.TBD
      lang.opt4stringSpecifies the parameters to give the optimizer when
+           -O4 is specified on the llvmc command line.TBD
      lang.opt5stringSpecifies the parameters to give the optimizer when 
+           -O5 is specified on the llvmc command line.TBD
      PREPROCESSOR ITEMS
      preprocessor.commandcommandThis provides the command prototype that will be used
+           to run the preprocessor.  This is generally only used with the 
+           -E option.<blank>
      preprocessor.requiredbooleanThis item specifies whether the pre-processing phase
+           is required by the language. If the value is true, then the
+           preprocessor.command value must not be blank. With this option,
+           llvmc will always run the preprocessor as it assumes that the
+           translation and optimization phases don't know how to pre-process their
+           input.false
      TRANSLATOR ITEMS
      translator.commandcommandThis provides the command prototype that will be used 
+           to run the translator. Valid substitutions are %in% for the 
+           input file and %out% for the output file.<blank>
      translator.outputbytecode or assemblyThis item specifies the kind of output the language's 
+           translator generates.bytecode
      translator.preprocessesbooleanIndicates that the translator also preprocesses. If
+           this is true, then llvmc will skip the pre-processing phase
+           whenever the final phase is not pre-processing.false
      OPTIMIZER ITEMS
      optimizer.commandcommandThis provides the command prototype that will be used 
+           to run the optimizer. Valid substitutions are %in% for the 
+           input file and %out% for the output file.<blank>
      optimizer.outputbytecode or assemblyThis item specifies the kind of output the language's 
+           optimizer generates. Valid values are "assembly" and "bytecode"bytecode
      optimizer.preprocessesbooleanIndicates that the optimizer also preprocesses. If
+           this is true, then llvmc will skip the pre-processing phase
+           whenever the final phase is optimization or later.false
      optimizer.translatesbooleanIndicates that the optimizer also translates. If
+           this is true, then llvmc will skip the translation phase
+           whenever the final phase is optimization or later.false
      ASSEMBLER ITEMS
      assembler.commandcommandThis provides the command prototype that will be used 
+           to run the assembler. Valid substitutions are %in% for the 
+           input file and %out% for the output file.<blank>
      
+ 
      
+ 
+ 
+ 
      Substitutions
      
+ 
      
+   
      On any configuration item that ends in command, you must
+   specify substitution tokens.  Substitution tokens begin and end with a percent
+   sign (%) and are replaced by the corresponding text. Any substitution
+   token may be given on any command line but some are more useful than
+   others. In particular each command should have both an %in%
+   and an %out% substitution. The table below provides definitions of
+   each of the allowed substitution tokens.
      
+   
+     
+       
+         
+         
+       
+       
+         
+         
+       
+         
+         
+       
+       
+         
+         
+       
+       
+         
+         
+       
+       
+         
+         
+       
+       
+         
+         
+       
+       
+         
+         
+       
+       
+         
+         
+       
+     
+   
      Substitution TokenReplacement Description
      %args%Replaced with all the tool-specific arguments given
+           to llvmc via the -T set of options. This just allows
+           you to place these arguments in the correct place on the command line.
+           If the %args% option does not appear on your command line, 
+           then you are explicitly disallowing the -T option for your 
+           tool.
+         
      %force%Replaced with the -f option if it was
+           specified on the llvmc command line. This is intended to tell
+           the compiler tool to force the overwrite of output files. 
+         
      %in%Replaced with the full path of the input file. You
+           needn't worry about the cascading of file names. llvmc will
+           create temporary files and ensure that the output of one phase is the
+           input to the next phase.
      %opt%Replaced with the optimization options for the
+           tool. If the tool understands the -O options then that will
+           be passed. Otherwise, the lang.optN series of configuration
+           items will specify which arguments are to be given.
      %out%Replaced with the full path of the output file.
+           Note that this is not necessarily the output file specified with the
+           -o option on llvmc's command line. It might be a
+           temporary file that will be passed to a subsequent phase's input.
+         
      %stats%If your command accepts the -stats option,
+           use this substitution token. If the user requested -stats 
+           from the llvmc command line then this token will be replaced
+           with -stats, otherwise it will be ignored.
+         
      %target%Replaced with the name of the target "machine" for 
+           which code should be generated. The value used here is taken from the
+           llvmc option -march.
+         
      %time%If your command accepts the -time-passes 
+           option, use this substitution token. If the user requested 
+           -time-passes from the llvmc command line then this 
+           token will be replaced with -time-passes, otherwise it will 
+           be ignored.
+         
      
+ 
      
+ 
+ 
+ 
      Sample Config File
      
+ 
      
+   
      Since an example is always instructive, here's how the Stacker language
+   configuration file looks.
      
+   
      
+ # Stacker Configuration File For llvmc
+ 
+ ##########################################################
+ # Language definitions
+ ##########################################################
+   lang.name=Stacker 
+   lang.opt1=-simplifycfg -instcombine -mem2reg
+   lang.opt2=-simplifycfg -instcombine -mem2reg -load-vn \
+     -gcse -dse -scalarrepl -sccp 
+   lang.opt3=-simplifycfg -instcombine -mem2reg -load-vn \
+     -gcse -dse -scalarrepl -sccp -branch-combine -adce \
+     -globaldce -inline -licm 
+   lang.opt4=-simplifycfg -instcombine -mem2reg -load-vn \
+     -gcse -dse -scalarrepl -sccp -ipconstprop \
+     -branch-combine -adce -globaldce -inline -licm 
+   lang.opt5=-simplifycfg -instcombine -mem2reg --load-vn \
+     -gcse -dse scalarrepl -sccp -ipconstprop \
+     -branch-combine -adce -globaldce -inline -licm \
+     -block-placement
+ 
+ ##########################################################
+ # Pre-processor definitions
+ ##########################################################
+ 
+   # Stacker doesn't have a preprocessor but the following
+   # allows the -E option to be supported
+   preprocessor.command=cp %in% %out%
+   preprocessor.required=false
+ 
+ ##########################################################
+ # Translator definitions
+ ##########################################################
+ 
+   # To compile stacker source, we just run the stacker
+   # compiler with a default stack size of 2048 entries.
+   translator.command=stkrc -s 2048 %in% -o %out% %time% \
+     %stats% %force% %args%
+ 
+   # stkrc doesn't preprocess but we set this to true so
+   # that we don't run the cp command by default.
+   translator.preprocesses=true
+ 
+   # The translator is required to run.
+   translator.required=true
+ 
+   # stkrc doesn't handle the -On options
+   translator.output=bytecode
+ 
+ ##########################################################
+ # Optimizer definitions
+ ##########################################################
+   
+   # For optimization, we use the LLVM "opt" program
+   optimizer.command=opt %in% -o %out% %opt% %time% %stats% \
+     %force% %args%
+ 
+   optimizer.required = true
+ 
+   # opt doesn't translate
+   optimizer.translates = no
+ 
+   # opt doesn't preprocess
+   optimizer.preprocesses=no
+ 
+   # opt produces bytecode
+   optimizer.output = bc
+ 
+ ##########################################################
+ # Assembler definitions
+ ##########################################################
+   assembler.command=llc %in% -o %out% %target% %time% %stats%
+ 
      
+ 
       
+ 
+ 
+ 
      Glossary
      
+ 
+ 
      
+   
      This document uses precise terms in reference to the various artifacts and
+   concepts related to compilation. The terms used throughout this document are
+   defined below.
      
+   
      
+     
      assembly
       
+     
      A compilation phase in which LLVM bytecode or 
+     LLVM assembly code is assembled to a native code format (either target 
+     specific aseembly language or the platform's native object file format).
+     
      
+ 
+     
      compiler
      
+     
      Refers to any program that can be invoked by llvmc to accomplish 
+     the work of one or more compilation phases.
      
+ 
+     
      driver
      
+     
      Refers to llvmc itself.
      
+ 
+     
      linking
      
+     
      A compilation phase in which LLVM bytecode files 
+     and (optionally) native system libraries are combined to form a complete 
+     executable program.
      
+ 
+     
      optimization
      
+     
      A compilation phase in which LLVM bytecode is 
+     optimized.
      
+ 
+     
      phase
      
+     
      Refers to any one of the five compilation phases that that 
+     llvmc supports. The five phases are:
+     preprocessing, 
+     translation,
+     optimization,
+     assembly,
+     linking.
      
+ 
+     
      source language
      
+     
      Any common programming language (e.g. C, C++, Java, Stacker, ML,
+     FORTRAN).  These languages are distinguished from any of the lower level
+     languages (such as LLVM or native assembly), by the fact that a 
+     translation phase 
+     is required before LLVM can be applied.
       
+ 
+     
      tool
      
+     
      Refers to any program in the LLVM tool set.
      
+ 
+     
      translation
      
+     
      A compilation phase in which 
+     source language code is translated into 
+     either LLVM assembly language or LLVM bytecode.
      
+   
      
+ 
      
+ 
+ 
      
+ 
       Valid CSS!Valid HTML 4.01!Reid Spencer
      
+ The LLVM Compiler Infrastructure
      
+ Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/CompilerWriterInfo.html
diff -c /dev/null llvm-www/releases/1.4/docs/CompilerWriterInfo.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/CompilerWriterInfo.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,246 ----
+ 
+ 
+ 
+   
+   Architecture/platform information for compiler writers
+   
+ 
+ 
+ 
      
+   Architecture/platform information for compiler writers
+ 
      
+ 
+ 
      
+   
      Note: This document is a work-in-progress.  Additions and clarifications
+   are welcome.
      
+ 
      
+ 
+ 
        
+   
      1. Hardware
+   
          
+     
        1. ARM
          2. 
+     
        2. MIPS
          3. 
+     
        3. PowerPC
          4. 
+     
        4. SPARC
          5. 
+     
        5. X86
          6. 
+     
        6. Other lists
          7. 
+   
        2. 
+   
      2. Application Binary Interface (ABI)
+   
          
+     
        1. Linux
          2. 
+     
        2. OS X
          3. 
+   
        3. 
+   
      3. Binary File Formats
+   
          
+     
        1. ...
          2. 
+   
        4. 
+ 
      
+ 
+ 
      
+   
      Compiled by Misha Brukman
      
+ 
      
+ 
+ 
+ 
      Hardware
      
+ 
+ 
+ 
+ 
      ARM
      
+ 
+ 
+ 
      ARM - Official manuals and docs
      
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      MIPS
      
+ 
+ 
+ 
      MIPS - Official manuals and docs
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
+ 
+ 
      PowerPC
      
+ 
+ 
+ 
      IBM - Official manuals and docs
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
+ 
+ 
      Other documents, collections, notes
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
+ 
+ 
      SPARC
      
+ 
+ 
+ 
      Official manuals and docs
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
+ 
+ 
      X86
      
+ 
+ 
+ 
      AMD - Official manuals and docs
      
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      Intel - Official manuals and docs
      
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      Other x86-specific information
      
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      Other relevant lists
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
+ 
+ 
      ABI
      
+ 
+ 
+ 
+ 
      Linux
      
+ 
+ 
      
+ 
        
+ 
      1. PowerPC 64-bit ELF ABI
+ Supplement
        2. 
+ 
      
+ 
      
+ 
+ 
+ 
      OS X
      
+ 
+ 
      
+ 
        
+ 
      1. Mach-O
+ Runtime Architecture
        2. 
+ 
      2. Notes on Mach-O
+ ABI
        3. 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      Binary File Formats
      
+ 
+ 
+ 
+ 
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Misha Brukman
      
+   LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/ExtendingLLVM.html
diff -c /dev/null llvm-www/releases/1.4/docs/ExtendingLLVM.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/ExtendingLLVM.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,293 ----
+ 
+ 
+ 
+   Extending LLVM: Adding instructions, intrinsics, types, etc.
+   
+ 
+ 
+ 
+ 
+ 
      
+   Extending LLVM: Adding instructions, intrinsics, types, etc.
+ 
      
+ 
+ 
        
+   
      1. Introduction and Warning
        2. 
+   
      2. Adding a new intrinsic function
        3. 
+   
      3. Adding a new instruction
        4. 
+   
      4. Adding a new type
+   
          
+     
        1. Adding a new fundamental type
          2. 
+     
        2. Adding a new derived type
          3. 
+   
        5. 
+ 
      
+ 
+ 
          
+   
      Written by Misha Brukman and
+   Brad Jones
      
+ 
      
+ 
+ 
+ 
      
+   Introduction and Warning
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      During the course of using LLVM, you may wish to customize it for your
+ research project or for experimentation. At this point, you may realize that
+ you need to add something to LLVM, whether it be a new fundamental type, a new
+ intrinsic function, or a whole new instruction.
      
+ 
+ 
      When you come to this realization, stop and think. Do you really need to
+ extend LLVM? Is it a new fundamental capability that LLVM does not support at
+ its current incarnation or can it be synthesized from already pre-existing LLVM
+ elements? If you are not sure, ask on the LLVM-dev list. The
+ reason is that extending LLVM will get involved as you need to update all the
+ different passes that you intend to use with your extension, and there are
+ many LLVM analyses and transformations, so it may be quite a bit of
+ work.
      
+ 
+ 
      Adding an intrinsic function is easier than adding
+ an instruction, and is transparent to optimization passes which treat it as an
+ unanalyzable function.  If your added functionality can be expressed as a
+ function call, an intrinsic function is the method of choice for LLVM
+ extension.
      
+ 
+ 
      Before you invest a significant amount of effort into a non-trivial
+ extension, ask on the list if what you are
+ looking to do can be done with already-existing infrastructure, or if maybe
+ someone else is already working on it. You will save yourself a lot of time and
+ effort by doing so.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Adding a new intrinsic function
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Adding a new intrinsic function to LLVM is much easier than adding a new
+ instruction.  Almost all extensions to LLVM should start as an intrinsic
+ function and then be turned into an instruction if warranted.
      
+ 
+ 
        
+ 
      1. llvm/docs/LangRef.html:
+     Document the intrinsic.  Decide whether it is code generator specific and
+     what the restrictions are.  Talk to other people about it so that you are
+     sure it's a good idea.
        2. 
+ 
+ 
      2. llvm/include/llvm/Intrinsics.h:
+     add an enum in the llvm::Intrinsic namespace
        3. 
+ 
+ 
      3. llvm/lib/CodeGen/IntrinsicLowering.cpp:
+     implement the lowering for this intrinsic
        4. 
+ 
+ 
      4. llvm/lib/VMCore/Verifier.cpp:
+     Add code to check the invariants of the intrinsic are respected.
        5. 
+ 
+ 
      5. llvm/lib/VMCore/Function.cpp (Function::getIntrinsicID()):
+     Identify the new intrinsic function, returning the enum for the intrinsic
+     that you added.
        6. 
+ 
+ 
      6. llvm/lib/Analysis/BasicAliasAnalysis.cpp: If the new intrinsic does
+     not access memory or does not write to memory, add it to the relevant list
+     of functions.
        7. 
+ 
+ 
      7. llvm/lib/Transforms/Utils/Local.cpp: If it is possible to
+     constant-propagate your intrinsic, add support to it in the
+     canConstantFoldCallTo and ConstantFoldCall functions.
        8. 
+ 
+ 
      8. Test your intrinsic
        9. 
+ 
+ 
      9. llvm/test/Regression/*: add your test cases to the test suite
        10. 
+ 
      
+ 
+ 
      If this intrinsic requires code generator support (i.e., it cannot be
+ lowered), you should also add support to the code generator in question.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Adding a new instruction
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      WARNING: adding instructions changes the bytecode
+ format, and it will take some effort to maintain compatibility with
+ the previous version. Only add an instruction if it is absolutely
+ necessary.
      
+ 
+ 
        
+ 
+ 
      1. llvm/include/llvm/Instruction.def:
+     add a number for your instruction and an enum name
        2. 
+ 
+ 
      2. llvm/include/llvm/Instructions.h:
+     add a definition for the class that will represent your instruction
        3. 
+ 
+ 
      3. llvm/include/llvm/Support/InstVisitor.h:
+     add a prototype for a visitor to your new instruction type
        4. 
+ 
+ 
      4. llvm/lib/AsmParser/Lexer.l:
+     add a new token to parse your instruction from assembly text file
        5. 
+ 
+ 
      5. llvm/lib/AsmParser/llvmAsmParser.y:
+     add the grammar on how your instruction can be read and what it will
+     construct as a result
        6. 
+ 
+ 
      6. llvm/lib/Bytecode/Reader/Reader.cpp:
+     add a case for your instruction and how it will be parsed from bytecode
        7. 
+ 
+ 
      7. llvm/lib/VMCore/Instruction.cpp:
+     add a case for how your instruction will be printed out to assembly
        8. 
+ 
+ 
      8. llvm/lib/VMCore/Instructions.cpp:
+     implement the class you defined in
+     llvm/include/llvm/Instructions.h
        9. 
+ 
+ 
      9. Test your instruction
        10. 
+ 
+ 
      10. llvm/lib/Target/*: 
+     Add support for your instruction to code generators, or add a lowering
+     pass.
        11. 
+ 
+ 
      11. llvm/test/Regression/*: add your test cases to the test suite.
        12. 
+ 
+ 
      
+ 
+ 
      Also, you need to implement (or modify) any analyses or passes that you want
+ to understand this new instruction.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Adding a new type
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      WARNING: adding new types changes the bytecode
+ format, and will break compatibility with currently-existing LLVM
+ installations. Only add new types if it is absolutely necessary.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Adding a fundamental type
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
+ 
      1. llvm/include/llvm/Type.def:
+     add enum for the type
        2. 
+ 
+ 
      2. llvm/include/llvm/Type.h:
+     add ID number for the new type; add static Type* for this type
        3. 
+ 
+ 
      3. llvm/lib/VMCore/Type.cpp:
+     add mapping from TypeID => Type*;
+     initialize the static Type*
        4. 
+ 
+ 
      4. llvm/lib/AsmReader/Lexer.l:
+     add ability to parse in the type from text assembly
        5. 
+ 
+ 
      5. llvm/lib/AsmReader/llvmAsmParser.y:
+     add a token for that type
        6. 
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Adding a derived type
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
      1. llvm/include/llvm/Type.def:
+     add enum for the type
        2. 
+ 
+ 
      2. llvm/include/llvm/Type.h:
+     add ID number for the new type; add a forward declaration of the type
+     also
        3. 
+ 
+ 
      3. llvm/include/llvm/DerivedType.h:
+     add new class to represent new class in the hierarchy; add forward 
+     declaration to the TypeMap value type
        4. 
+ 
+ 
      4. llvm/lib/VMCore/Type.cpp:
+     add support for derived type to: 
+ 
        
+ 
        + std::string getTypeDescription(const Type &Ty,
+   std::vector<const Type*> &TypeStack)
+ bool TypesEqual(const Type *Ty, const Type *Ty2,
+   std::map<const Type*, const Type*> & EqTypes)
+ 
        
+ 
        
+     add necessary member functions for type, and factory methods
        5. 
+ 
+ 
      5. llvm/lib/AsmReader/Lexer.l:
+     add ability to parse in the type from text assembly
        6. 
+ 
+ 
      6. llvm/lib/ByteCode/Writer/Writer.cpp:
+     modify void BytecodeWriter::outputType(const Type *T) to serialize
+     your type
        7. 
+ 
+ 
      7. llvm/lib/ByteCode/Reader/Reader.cpp:
+     modify const Type *BytecodeReader::ParseType() to read your data
+     type
        8.  
+ 
+ 
      8. llvm/lib/VMCore/AsmWriter.cpp:
+     modify
+ 
        
+ 
        + void calcTypeName(const Type *Ty,
+                   std::vector<const Type*> &TypeStack,
+                   std::map<const Type*,std::string> &TypeNames,
+                   std::string & Result)
+ 
        
+ 
        
+     to output the new derived type
+ 
        9.   
+  
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Misha Brukman
      
+   The LLVM Compiler Infrastructure
+   
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/FAQ.html
diff -c /dev/null llvm-www/releases/1.4/docs/FAQ.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/FAQ.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,561 ----
+ 
+ 
+ 
+   LLVM: Frequently Asked Questions
+   
+ 
+ 
+ 
+ 
      
+   LLVM: Frequently Asked Questions
+ 
      
+ 
+ 
        
+   
      1. License
+   
          
+   
        1. Why are the LLVM source code and the front-end distributed under different
+   licenses?
          2. 
+   
        2. Does the University of Illinois Open Source License really qualify as an
+   "open source" license?
          3. 
+   
        3. Can I modify LLVM source code and redistribute the modified source?
          4. 
+   
        4. Can I modify LLVM source code and redistribute binaries or other tools
+   based on it, without redistributing the source?
          5. 
+   
        2. 
+ 
+   
      2. Source code
+   
          
+   
        1. In what language is LLVM written?
          2. 
+   
        2. How portable is the LLVM source code?
          3. 
+   
        3. 
+ 
+   
      3. Build Problems
+   
          
+   
        1. When I run configure, it finds the wrong C compiler.
          2. 
+   
        2. I compile the code, and I get some error about /localhome.
          3. 
+   
        3. The configure script finds the right C compiler, but it uses the
+   LLVM linker from a previous build.  What do I do?
          4. 
+   
        4. When creating a dynamic library, I get a strange GLIBC error.
          5. 
+   
        5. I've updated my source tree from CVS, and now my build is trying to use a
+   file/directory that doesn't exist.
          6. 
+   
        6. I've modified a Makefile in my source tree, but my build tree keeps using
+   the old version.  What do I do?
          7. 
+   
        7. I've upgraded to a new version of LLVM, and I get strange build
+   errors.
          8. 
+   
        8. I've built LLVM and am testing it, but the tests freeze.
          9. 
+   
        9. Why do test results differ when I perform different types of builds?
          10. 
+   
        10. Compiling LLVM with GCC 3.3.2 fails, what should I do?
          11. 
+   
        11. When I use the test suite, all of the C Backend tests fail.  What is
+       wrong?
          12. 
+   
        12. After CVS update, rebuilding gives the error "No rule to make
+   target".
          13. 
+   
        4. 
+ 
+   
      4. Using the GCC Front End
+   
          
+     
        1. 
+     When I compile software that uses a configure script, the configure script
+     thinks my system has all of the header files and libraries it is testing
+     for.  How do I get configure to work correctly?
+     
          2. 
+ 
+     
        2. 
+     When I compile code using the LLVM GCC front end, it complains that it
+     cannot find libcrtend.a.
+     
          3. 
+   
        
+   
        5. 
+ 
+   
      5. Questions about code generated by the GCC front-end
+   
          
+      
        1. What is this __main() call that gets inserted into
+          main()?
          2. 
+      
        2. Where did all of my code go??
          3. 
+      
        3. What is this llvm.global_ctors and
+           _GLOBAL__I__tmp_webcompile... stuff that happens when I
+           #include <iostream>?
          4. 
+   
        
+   
        6. 
+ 
      
+ 
+ 
      
+   
      Written by The LLVM Team
      
+ 
      
+ 
+ 
+ 
+ 
      
+   License
+ 
      
+ 
+ 
+ 
      
+ 
      Why are the LLVM source code and the front-end distributed under different
+ licenses?
      
+ 
      
+ 	
+ 
      
+ 
      The C/C++ front-ends are based on GCC and must be distributed under the GPL.
+ Our aim is to distribute LLVM source code under a much less restrictive
+ license, in particular one that does not compel users who distribute tools based
+ on modifying the source to redistribute the modified source code as well.
      
+ 
      
+ 
+ 
      
+ 
      Does the University of Illinois Open Source License really qualify as an
+ "open source" license?
      
+ 
      
+ 
+ 
      
+ 
      Yes, the license is certified by the Open
+ Source Initiative (OSI).
      
+ 
      
+ 
+ 
      
+ 
      Can I modify LLVM source code and redistribute the modified source?
      
+ 
      
+ 
+ 
      
+ 
      Yes.  The modified source distribution must retain the copyright notice and
+ follow the three bulletted conditions listed in the LLVM license.
      
+ 
      
+ 
+ 
      
+ 
      Can I modify LLVM source code and redistribute binaries or other tools based
+ on it, without redistributing the source?
      
+ 
      
+ 
+ 
      
+ 
      Yes, this is why we distribute LLVM under a less restrictive license than
+ GPL, as explained in the first question above.
      
+ 
      
+ 
+ 
+ 
      
+   Source Code
+ 
      
+ 
+ 
+ 
      
+ 
      In what language is LLVM written?
      
+ 
      
+ 
+ 
      
+ 
      All of the LLVM tools and libraries are written in C++ with extensive use of
+ the STL.
      
+ 
      
+ 
+ 
      
+ 
      How portable is the LLVM source code?
      
+ 
      
+ 
+ 
      
+ 
      The LLVM source code should be portable to most modern UNIX-like operating
+ systems.  Most of the code is written in standard C++ with operating system
+ services abstracted to a support library.  The tools required to build and test
+ LLVM have been ported to a plethora of platforms.
      
+ 
+ 
      Some porting problems may exist in the following areas:
      
+ 
+ 
        
+ 
+   
      • The GCC front end code is not as portable as the LLVM suite, so it may not
+   compile as well on unsupported platforms.
        • 
+ 
+   
      • The LLVM build system relies heavily on UNIX shell tools, like the Bourne
+   Shell and sed.  Porting to systems without these tools (MacOS 9, Plan 9) will
+   require more effort.
        • 
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Build Problems
+ 
      
+ 
+ 
+ 
      
+ 
      When I run configure, it finds the wrong C compiler.
      
+ 
      
+ 
+ 
      
+ 
+ 
      The configure script attempts to locate first gcc and then
+ cc, unless it finds compiler paths set in CC and CXX
+ for the C and C++ compiler, respectively.
      
+ 
+ 
      If configure finds the wrong compiler, either adjust your
+ PATH environment variable or set CC and CXX
+ explicitly.
      
+ 
+ 
      
+ 
+ 
      
+ 
      I compile the code, and I get some error about /localhome.
      
+ 
      
+ 
+ 
      
+ 
+ 
      There are several possible causes for this.  The first is that you didn't set
+ a pathname properly when using configure, and it defaulted to a
+ pathname that we use on our research machines.
      
+ 
+ 
      Another possibility is that we hardcoded a path in our Makefiles.  If you see
+ this, please email the LLVM bug mailing list with the name of the offending
+ Makefile and a description of what is wrong with it.
      
+ 
+ 
      
+ 
+ 
      
+ 
      The configure script finds the right C compiler, but it uses the
+ LLVM linker from a previous build.  What do I do?
      
+ 
      
+ 
+ 
      
+ 
      The configure script uses the PATH to find executables, so
+ if it's grabbing the wrong linker/assembler/etc, there are two ways to fix
+ it:
      
+ 
+ 
        
+ 		
+   
      1. Adjust your PATH environment variable so that the correct
+   program appears first in the PATH.  This may work, but may not be
+   convenient when you want them first in your path for other
+   work.
        2. 
+ 
+   
      2. Run configure with an alternative PATH that is
+   correct. In a Borne compatible shell, the syntax would be:
        
+ 		
+       
        PATH=[the path without the bad program] ./configure ...
        
+ 
+       
        This is still somewhat inconvenient, but it allows configure
+       to do its work without having to adjust your PATH
+       permanently.
        3. 
+ 	
+ 
      
+ 
+ 
      
+ 
+ 
      
+ 
      When creating a dynamic library, I get a strange GLIBC error.
      
+ 
      
+ 
+ 
      
+ 
      Under some operating systems (i.e. Linux), libtool does not work correctly if
+ GCC was compiled with the --disable-shared option.  To work around this, install
+ your own version of GCC that has shared libraries enabled by default.
      
+ 
      
+ 
+ 
      
+ 
      I've updated my source tree from CVS, and now my build is trying to use a
+ file/directory that doesn't exist.
      
+ 
      
+ 
+ 
      
+ 
      You need to re-run configure in your object directory.  When new Makefiles
+ are added to the source tree, they have to be copied over to the object tree in
+ order to be used by the build.
      
+ 
      
+ 
+ 
      
+ 
      I've modified a Makefile in my source tree, but my build tree keeps using the
+ old version.  What do I do?
      
+ 
      
+ 
+ 
      
+ 
+ 
      If the Makefile already exists in your object tree, you
+ can just run the following command in the top level directory of your object
+ tree:
      
+ 
+ 
      ./config.status <relative path to Makefile>
      
+ 
+ 
      If the Makefile is new, you will have to modify the configure script to copy
+ it over.
      
+ 
+ 
      
+ 
+ 
      
+ 
      I've upgraded to a new version of LLVM, and I get strange build errors.
      
+ 
      
+ 
+ 
      
+ 
+ 
      Sometimes, changes to the LLVM source code alters how the build system works.
+ Changes in libtool, autoconf, or header file dependencies are especially prone
+ to this sort of problem.
      
+ 
+ 
      The best thing to try is to remove the old files and re-build.  In most
+ cases, this takes care of the problem.  To do this, just type make
+ clean and then make in the directory that fails to build.
      
+ 
+ 
      
+ 
+ 
      
+ 
      I've built LLVM and am testing it, but the tests freeze.
      
+ 
      
+ 
+ 
      
+ 
+ 
      This is most likely occurring because you built a profile or release
+ (optimized) build of LLVM and have not specified the same information on the
+ gmake command line.
      
+ 
+ 
      For example, if you built LLVM with the command:
      
+ 
+ 
      gmake ENABLE_PROFILING=1
+ 
+ 
      ...then you must run the tests with the following commands:
      
+ 
+ 
      cd llvm/test
      gmake  ENABLE_PROFILING=1
      
+ 
+ 
      
+ 
+ 
      
+ 
      Why do test results differ when I perform different types of builds?
      
+ 
      
+ 
+ 
      
+ 
+ 
      The LLVM test suite is dependent upon several features of the LLVM tools and
+ libraries.
      
+ 
+ 
      First, the debugging assertions in code are not enabled in optimized or
+ profiling builds.  Hence, tests that used to fail may pass.
      
+ 	
+ 
      Second, some tests may rely upon debugging options or behavior that is only
+ available in the debug build.  These tests will fail in an optimized or profile
+ build.
      
+ 
+ 
      
+ 
+ 
      
+ 
      Compiling LLVM with GCC 3.3.2 fails, what should I do?
      
+ 
      
+ 
+ 
      
+ 
      This is a bug in GCC, and 
+    affects projects other than LLVM.  Try upgrading or downgrading your GCC.
      
+ 
      
+ 
+ 
      
+ 
      
+ When I use the test suite, all of the C Backend tests fail.  What is
+ wrong?
+ 
      
+ 
      
+ 
+ 
      
+ 
      
+ If you build LLVM and the C Backend tests fail in llvm/test/Programs,
+ then chances are good that the directory pointed to by the LLVM_LIB_SEARCH_PATH
+ environment variable does not contain the libcrtend.a library.
+ 
      
+ 
+ 
      
+ To fix it, verify that LLVM_LIB_SEARCH_PATH points to the correct directory
+ and that libcrtend.a is inside.  For pre-built LLVM GCC front ends, this
+ should be the absolute path to
+ cfrontend/<platform>/llvm-gcc/bytecode-libs.  If you've
+ built your own LLVM GCC front end, then ensure that you've built and installed
+ the libraries in llvm/runtime and have LLVM_LIB_SEARCH_PATH pointing
+ to the LLVMGCCDIR/bytecode-libs subdirectory.
+ 
      
+ 
      
+ 
+ 
      
+ 
      After CVS update, rebuilding gives the error "No rule to make target".
      
+ 
      
+ 
+ 
      
+ 
      If the error is of the form:
      
+ 
+ 
      
+ 
+ gmake[2]: *** No rule to make target `/path/to/somefile', needed by
+ `/path/to/another/file.d'.
      
+ Stop.
+       
+ 
      
+ 
+ 
      This may occur anytime files are moved within the CVS repository or removed
+ entirely.  In this case, the best solution is to erase all .d files,
+ which list dependencies for source files, and rebuild:
      
+ 
+ 
      
+ 
      + % cd $LLVM_OBJ_DIR
+ % rm -f `find . -name \*\.d` 
+ % gmake 
+ 
      
+ 
      
+ 
+ 
      In other cases, it may be necessary to run make clean before
+ rebuilding.
      
+ 
      
+ 
+ 
+ 
      
+   Using the GCC Front End
+ 
      
+ 
+ 
      
+ 
      
+ When I compile software that uses a configure script, the configure script
+ thinks my system has all of the header files and libraries it is testing for.
+ How do I get configure to work correctly?
+ 
      
+ 
      
+ 
+ 
      
+ 
      
+ The configure script is getting things wrong because the LLVM linker allows
+ symbols to be undefined at link time (so that they can be resolved during JIT
+ or translation to the C back end).  That is why configure thinks your system
+ "has everything."
+ 
      
+ 
      
+ To work around this, perform the following steps:
+ 
      
+ 
+ 
        
+   
      1. 
+   Make sure the CC and CXX environment variables contains the full path to the
+   LLVM GCC front end.
+   
        2. 
+ 
+   
      2. 
+   Make sure that the regular C compiler is first in your PATH.
+   
        3. 
+ 
+   
      3. 
+   Add the string "-Wl,-native" to your CFLAGS environment variable.
+   
        4. 
+ 
      
+ 
+ 
      
+ This will allow the gccld linker to create a native code executable instead of
+ a shell script that runs the JIT.  Creating native code requires standard
+ linkage, which in turn will allow the configure script to find out if code is
+ not linking on your system because the feature isn't available on your system.
+ 
      
+ 
      
+ 
+ 
      
+ 
      
+ When I compile code using the LLVM GCC front end, it complains that it cannot
+ find libcrtend.a.
+ 
      
+ 
      
+ 
+ 
      
+ 
      
+ In order to find libcrtend.a, you must have the directory in which it lives in
+ your LLVM_LIB_SEARCH_PATH environment variable.  For the binary distribution of
+ the LLVM GCC front end, this will be the full path of the bytecode-libs
+ directory inside of the LLVM GCC distribution.
+ 
      
+ 
      
+ 
+ 
+ 
+ 
      
+   Questions about code generated by the GCC front-end
+ 
      
+ 
+ 
      
+ What is this __main() call that gets inserted into main()?
+ 
      
+ 
+ 
      
+ 
      
+ The __main call is inserted by the C/C++ compiler in order to guarantee
+ that static constructors and destructors are called when the program starts up
+ and shuts down.  In C, you can create static constructors and destructors by
+ using GCC extensions, and in C++ you can do so by creating a global variable
+ whose class has a ctor or dtor.
+ 
      
+ 
+ 
      
+ The actual implementation of __main lives in the
+ llvm/runtime/GCCLibraries/crtend/ directory in the source-base, and is
+ linked in automatically when you link the program.
+ 
      
+ 
      
+ 
+ 
+ 
+ 
      
+ Where did all of my code go??
+ 
      
+ 
+ 
      
+ 
      
+ If you are using the LLVM demo page, you may often wonder what happened to all
+ of the code that you typed in.  Remember that the demo script is running the
+ code through the LLVM optimizers, so if your code doesn't actually do anything
+ useful, it might all be deleted.
+ 
      
+ 
+ 
      
+ To prevent this, make sure that the code is actually needed.  For example, if
+ you are computing some expression, return the value from the function instead of
+ leaving it in a local variable.  If you really want to constrain the optimizer,
+ you can read from and assign to volatile global variables.
+ 
      
+ 
      
+ 
+ 
+ 
+ 
      
+ 
       What is this llvm.global_ctors and
+ _GLOBAL__I__tmp_webcompile... stuff that happens when I #include
+ <iostream>?
      
+ 
      
+ 
+ 
      
+ 
+ 
      If you #include the <iostream> header into a C++ translation unit, the
+ file will probably use the std::cin/std::cout/... global
+ objects.  However, C++ does not guarantee an order of initialization between
+ static objects in different translation units, so if a static ctor/dtor in your
+ .cpp file used std::cout, for example, the object would not necessarily
+ be automatically initialized before your use.
      
+ 
+ 
      To make std::cout and friends work correctly in these scenarios, the
+ STL that we use declares a static object that gets created in every translation
+ unit that includes <iostream>.  This object has a static
+ constructor and destructor that initializes and destroys the global iostream
+ objects before they could possibly be used in the file.  The code that you see
+ in the .ll file corresponds to the constructor and destructor registration code.
+ 
      
+ 
+ 
      If you would like to make it easier to understand the LLVM code
+ generated by the compiler in the demo page, consider using printf()
+ instead of iostreams to print values.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/GarbageCollection.html
diff -c /dev/null llvm-www/releases/1.4/docs/GarbageCollection.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/GarbageCollection.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,533 ----
+ 
+ 
+ 
+   Accurate Garbage Collection with LLVM
+   
+ 
+ 
+ 
+ 
      
+   Accurate Garbage Collection with LLVM
+ 
      
+ 
+ 
        
+   
      1. Introduction
+     
+   
        2. 
+ 
+   
      2. Interfaces for user programs
+     
+   
        3. 
+ 
+   
      3. Implementing a garbage collector
+     
+   
        4. 
+   
      4. GC implementations available
+     
+   
        5. 
+ 
+ 
+ 
      
+ 
+ 
      
+   
      Written by Chris Lattner
      
+ 
      
+ 
+ 
+ 
      
+   Introduction
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Garbage collection is a widely used technique that frees the programmer from
+ having to know the life-times of heap objects, making software easier to produce
+ and maintain.  Many programming languages rely on garbage collection for
+ automatic memory management.  There are two primary forms of garbage collection:
+ conservative and accurate.
      
+ 
+ 
      Conservative garbage collection often does not require any special support
+ from either the language or the compiler: it can handle non-type-safe
+ programming languages (such as C/C++) and does not require any special
+ information from the compiler.  The [LINK] Boehm collector is an example of a
+ state-of-the-art conservative collector.
      
+ 
+ 
      Accurate garbage collection requires the ability to identify all pointers in
+ the program at run-time (which requires that the source-language be type-safe in
+ most cases).  Identifying pointers at run-time requires compiler support to
+ locate all places that hold live pointer variables at run-time, including the
+ processor stack and registers.
      
+ 
+ 
      
+ Conservative garbage collection is attractive because it does not require any
+ special compiler support, but it does have problems.  In particular, because the
+ conservative garbage collector cannot know that a particular word in the
+ machine is a pointer, it cannot move live objects in the heap (preventing the
+ use of compacting and generational GC algorithms) and it can occasionally suffer
+ from memory leaks due to integer values that happen to point to objects in the
+ program.  In addition, some aggressive compiler transformations can break
+ conservative garbage collectors (though these seem rare in practice).
+ 
      
+ 
+ 
      
+ Accurate garbage collectors do not suffer from any of these problems, but they
+ can suffer from degraded scalar optimization of the program.  In particular,
+ because the runtime must be able to identify and update all pointers active in
+ the program, some optimizations are less effective.  In practice, however, the
+ locality and performance benefits of using aggressive garbage allocation
+ techniques dominates any low-level losses.
+ 
      
+ 
+ 
      
+ This document describes the mechanisms and interfaces provided by LLVM to
+ support accurate garbage collection.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   GC features provided and algorithms supported
+ 
      
+ 
+ 
      
+ 
+ 
      
+ LLVM provides support for a broad class of garbage collection algorithms,
+ including compacting semi-space collectors, mark-sweep collectors, generational
+ collectors, and even reference counting implementations.  It includes support
+ for read and write barriers, and associating meta-data with stack objects (used for tagless garbage
+ collection).  All LLVM code generators support garbage collection, including the
+ C backend.
+ 
      
+ 
+ 
      
+ We hope that the primitive support built into LLVM is sufficient to support a
+ broad class of garbage collected languages, including Scheme, ML, scripting
+ languages, Java, C#, etc.  That said, the implemented garbage collectors may
+ need to be extended to support language-specific features such as finalization,
+ weak references, or other features.  As these needs are identified and
+ implemented, they should be added to this specification.
+ 
      
+ 
+ 
      
+ LLVM does not currently support garbage collection of multi-threaded programs or
+ GC-safe points other than function calls, but these will be added in the future
+ as there is interest.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Interfaces for user programs
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      This section describes the interfaces provided by LLVM and by the garbage
+ collector run-time that should be used by user programs.  As such, this is the
+ interface that front-end authors should generate code for.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Identifying GC roots on the stack: llvm.gcroot
+ 
      
+ 
+ 
      
+ 
+ 
      
+   void %llvm.gcroot(<ty>** %ptrloc, <ty2>* %metadata)
+ 
      
+ 
+ 
      
+ The llvm.gcroot intrinsic is used to inform LLVM of a pointer variable
+ on the stack.  The first argument contains the address of the variable on the
+ stack, and the second contains a pointer to metadata that should be associated
+ with the pointer (which must be a constant or global value address).  At
+ runtime, the llvm.gcroot intrinsic stores a null pointer into the
+ specified location to initialize the pointer.
      
+ 
+ 
      
+ Consider the following fragment of Java code:
+ 
      
+ 
+ 
      +        {
+          Object X;   // A null-initialized reference to an object
+          ...
+        }
+ 
      
+ 
+ 
      
+ This block (which may be located in the middle of a function or in a loop nest),
+ could be compiled to this LLVM code:
+ 
      
+ 
+ 
      + Entry:
+    ;; In the entry block for the function, allocate the
+    ;; stack space for X, which is an LLVM pointer.
+    %X = alloca %Object*
+    ...
+ 
+    ;; "CodeBlock" is the block corresponding to the start
+    ;;  of the scope above.
+ CodeBlock:
+    ;; Initialize the object, telling LLVM that it is now live.
+    ;; Java has type-tags on objects, so it doesn't need any
+    ;; metadata.
+    call void %llvm.gcroot(%Object** %X, sbyte* null)
+    ...
+ 
+    ;; As the pointer goes out of scope, store a null value into
+    ;; it, to indicate that the value is no longer live.
+    store %Object* null, %Object** %X
+    ...
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Allocating memory from the GC
+ 
      
+ 
+ 
      
+ 
+ 
      
+   sbyte *%llvm_gc_allocate(unsigned %Size)
+ 
      
+ 
+ 
      The llvm_gc_allocate function is a global function defined by the
+ garbage collector implementation to allocate memory.  It returns a
+ zeroed-out block of memory of the appropriate size.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Reading and writing references to the heap
+ 
      
+ 
+ 
      
+ 
+ 
      
+   sbyte *%llvm.gcread(sbyte *, sbyte **)
      
+   void %llvm.gcwrite(sbyte*, sbyte*, sbyte**)
+ 
      
+ 
+ 
      Several of the more interesting garbage collectors (e.g., generational
+ collectors) need to be informed when the mutator (the program that needs garbage
+ collection) reads or writes object references into the heap.  In the case of a
+ generational collector, it needs to keep track of which "old" generation objects
+ have references stored into them.  The amount of code that typically needs to be
+ executed is usually quite small (and not on the critical path of any 
+ computation), so the overall performance impact of the inserted code is 
+ tolerable.
      
+ 
+ 
      To support garbage collectors that use read or write barriers, LLVM provides
+ the llvm.gcread and llvm.gcwrite intrinsics.  The first
+ intrinsic has exactly the same semantics as a non-volatile LLVM load and the
+ second has the same semantics as a non-volatile LLVM store, with the
+ additions that they also take a pointer to the start of the memory
+ object as an argument.  At code generation
+ time, these intrinsics are replaced with calls into the garbage collector
+ (llvm_gc_read and llvm_gc_write respectively), which are then
+ inlined into the code.
+ 
      
+ 
+ 
      
+ If you are writing a front-end for a garbage collected language, every load or
+ store of a reference from or to the heap should use these intrinsics instead of
+ normal LLVM loads/stores.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Garbage collector startup and initialization
+ 
      
+ 
+ 
      
+ 
+ 
      
+   void %llvm_gc_initialize(unsigned %InitialHeapSize)
+ 
      
+ 
+ 
      
+ The llvm_gc_initialize function should be called once before any other
+ garbage collection functions are called.  This gives the garbage collector the
+ chance to initialize itself and allocate the heap spaces.  The initial heap size
+ to allocate should be specified as an argument.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Explicit invocation of the garbage collector
+ 
      
+ 
+ 
      
+ 
+ 
      
+   void %llvm_gc_collect()
+ 
      
+ 
+ 
      
+ The llvm_gc_collect function is exported by the garbage collector
+ implementations to provide a full collection, even when the heap is not
+ exhausted.  This can be used by end-user code as a hint, and may be ignored by
+ the garbage collector.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Implementing a garbage collector
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      
+ Implementing a garbage collector for LLVM is fairly straight-forward.  The LLVM
+ garbage collectors are provided in a form that makes them easy to link into the
+ language-specific runtime that a language front-end would use.  They require
+ functionality from the language-specific runtime to get information about where pointers are located in heap objects.
+ 
      
+ 
+ 
      The
+ implementation must include the llvm_gc_allocate and llvm_gc_collect functions, and it must implement
+ the read/write barrier functions as well.  To
+ do this, it will probably have to trace through the roots
+ from the stack and understand the GC descriptors
+ for heap objects.  Luckily, there are some example
+ implementations available.
+ 
      
+ 
      
+ 
+ 
+ 
+ 
      
+   Implementing llvm_gc_read and llvm_gc_write
+ 
      
+ 
+ 
      
+   
      
+     void *llvm_gc_read(void*, void **)
      
+     void llvm_gc_write(void*, void *, void**)
+  
      
+ 
+ 
      
+ These functions must be implemented in every garbage collector, even if
+ they do not need read/write barriers.  In this case, just load or store the
+ pointer, then return.
+ 
      
+ 
+ 
      
+ If an actual read or write barrier is needed, it should be straight-forward to
+ implement it.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Callback functions used to implement the garbage collector
+ 
      
+ 
+ 
      
+ 
      
+ Garbage collector implementations make use of call-back functions that are
+ implemented by other parts of the LLVM system.
+ 
      
+ 
      
+ 
+ 
+ 
      
+   Tracing GC pointers from the program stack
+ 
      
+ 
+ 
      
+   
      
+      void llvm_cg_walk_gcroots(void (*FP)(void **Root, void *Meta));
+   
      
+ 
+ 
      
+ The llvm_cg_walk_gcroots function is a function provided by the code
+ generator that iterates through all of the GC roots on the stack, calling the
+ specified function pointer with each record.  For each GC root, the address of
+ the pointer and the meta-data (from the llvm.gcroot intrinsic) are provided.
+ 
      
+ 
      
+ 
+ 
+ 
      
+   Tracing GC pointers from static roots
+ 
      
+ 
+ 
      
+ TODO
+ 
      
+ 
+ 
+ 
+ 
      
+   Tracing GC pointers from heap objects
+ 
      
+ 
+ 
      
+ 
      
+ The three most common ways to keep track of where pointers live in heap objects
+ are (listed in order of space overhead required):
      
+ 
+ 
        
+ 
      1. In languages with polymorphic objects, pointers from an object header are
+ usually used to identify the GC pointers in the heap object.  This is common for
+ object-oriented languages like Self, Smalltalk, Java, or C#.
        2. 
+ 
+ 
      2. If heap objects are not polymorphic, often the "shape" of the heap can be
+ determined from the roots of the heap or from some other meta-data [Appel89, Goldberg91, Tolmach94].  In this case, the garbage collector can
+ propagate the information around from meta data stored with the roots.  This
+ often eliminates the need to have a header on objects in the heap.  This is
+ common in the ML family.
        3. 
+ 
+ 
      3. If all heap objects have pointers in the same locations, or pointers can be
+ distinguished just by looking at them (e.g., the low order bit is clear), no
+ book-keeping is needed at all.  This is common for Lisp-like languages.
        4. 
+ 
      
+ 
+ 
      The LLVM garbage collectors are capable of supporting all of these styles of
+ language, including ones that mix various implementations.  To do this, it
+ allows the source-language to associate meta-data with the stack roots, and the heap tracing routines can propagate the
+ information.  In addition, LLVM allows the front-end to extract GC information
+ from in any form from a specific object pointer (this supports situations #1 and
+ #3).
+ 
      
+ 
+ 
      Making this efficient
      
+ 
+ 
+ 
+ 
      
+ 
+ 
+ 
+ 
+ 
      
+   GC implementations available
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      
+ To make this more concrete, the currently implemented LLVM garbage collectors
+ all live in the llvm/runtime/GC/* directories in the LLVM source-base.
+ If you are interested in implementing an algorithm, there are many interesting
+ possibilities (mark/sweep, a generational collector, a reference counting
+ collector, etc), or you could choose to improve one of the existing algorithms.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   SemiSpace - A simple copying garbage collector
+ 
      
+ 
+ 
      
+ 
      
+ SemiSpace is a very simple copying collector.  When it starts up, it allocates
+ two blocks of memory for the heap.  It uses a simple bump-pointer allocator to
+ allocate memory from the first block until it runs out of space.  When it runs
+ out of space, it traces through all of the roots of the program, copying blocks
+ to the other half of the memory space.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Possible Improvements
+ 
      
+ 
+ 
      
+ 
+ 
      
+ If a collection cycle happens and the heap is not compacted very much (say less
+ than 25% of the allocated memory was freed), the memory regions should be
+ doubled in size.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   References
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      [Appel89] Runtime Tags Aren't Necessary. Andrew
+ W. Appel. Lisp and Symbolic Computation 19(7):703-705, July 1989.
      
+ 
+ 
      [Goldberg91] Tag-free garbage collection for
+ strongly typed programming languages.  Benjamin Goldberg. ACM SIGPLAN
+ PLDI'91.
      
+ 
+ 
      [Tolmach94] Tag-free garbage collection using
+ explicit type parameters.  Andrew Tolmach.  Proceedings of the 1994 ACM
+ conference on LISP and functional programming.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Chris Lattner
      
+   LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/GettingStarted.html
diff -c /dev/null llvm-www/releases/1.4/docs/GettingStarted.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/GettingStarted.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,1509 ----
+ 
+ 
+ 
+   
+   Getting Started with LLVM System
+   
+ 
+ 
+ 
+ 
      
+   Getting Started with the LLVM System  
+ 
      
+ 
+ 
+ 
+ 
      
+   
      Written by: 
+     John Criswell, 
+     Chris Lattner,
+     Misha Brukman, 
+     Vikram Adve, and
+     Guochun Shi.
+   
      
+ 
      
+ 
+ 
+ 
+ 
      
+   Overview
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Welcome to LLVM! In order to get started, you first need to know some
+ basic information.
      
+ 
+ 
      First, LLVM comes in two pieces. The first piece is the LLVM suite. This
+ contains all of the tools, libraries, and header files needed to use the low
+ level virtual machine.  It contains an assembler, disassembler, bytecode
+ analyzer, and bytecode optimizer.  It also contains a test suite that can be
+ used to test the LLVM tools and the GCC front end.
      
+ 
+ 
      The second piece is the GCC front end.  This component provides a version of
+ GCC that compiles C and C++ code into LLVM bytecode.  Currently, the GCC front
+ end is a modified version of GCC 3.4 (we track the GCC 3.4 development).  Once
+ compiled into LLVM bytecode, a program can be manipulated with the LLVM tools
+ from the LLVM suite.
      
+ 
+ 
      
+ There is a third, optional piece called llvm-test.  It is a suite of programs
+ with a testing harness that can be used to further test LLVM's functionality
+ and performance.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Getting Started Quickly (A Summary)
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Here's the short story for getting up and running quickly with LLVM:
      
+ 
+ 
        
+   
      1. Read the documentation.
        2. 
+   
      2. Read the documentation.
        3. 
+   
      3. Remember that you were warned twice about reading the documentation.
        4. 
+   
      4. Install the GCC front end:
+     
          
+       
        1. cd where-you-want-the-C-front-end-to-live
+       
        2. gunzip --stdout cfrontend.platform.tar.gz | tar -xvf -
+       
        3. cd cfrontend/platform
          
+           ./fixheaders          
+     
        5. 
+ 
+   
      5. Get the Source Code
+   
          
+     
        • With the distributed files:
+     
            
+       
          1. cd where-you-want-llvm-to-live
+       
          2. gunzip --stdout llvm-version.tar.gz | tar -xvf -
+       
          3. cd llvm
            4. 
+     
          • 
+ 
+     
        • With anonymous CVS access (or use a mirror):
+     
            
+       
          1. cd where-you-want-llvm-to-live
            2. 
+       
          2. cvs -d
+           :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm login
            3. 
+       
          3. Hit the return key when prompted for the password.
+       
          4. cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm 
+           co llvm
            5. 
+       
          5. cd llvm
            6. 
+       
          6. cvs up -P -d
            7. 
+     
          • 
+   
        6. 
+ 
+   
      6. Get the Test Suite Source Code (optional)
+   
          
+     
        • With the distributed files:
+     
            
+       
          1. cd where-you-want-llvm-to-live
+       
          2. cd llvm/projects
+       
          3. gunzip --stdout llvm-test-version.tar.gz | tar -xvf -
+       
          4. cd ..
            5. 
+     
          • 
+ 
+     
        • With anonymous CVS access (or use a mirror):
+     
            
+       
          1. cd where-you-want-llvm-to-live
            2. 
+       
          2. cd llvm/projects
+       
          3. cvs -d
+           :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm login
            4. 
+       
          4. Hit the return key when prompted for the password.
+       
          5. cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm 
+           co llvm-test
            6. 
+       
          6. cd llvm-test
            7. 
+       
          7. cvs up -P -d
            8. 
+       
          8. cd ..
            9. 
+     
          • 
+   
        7. 
+ 
+ 
+   
      7. Configure the LLVM Build Environment
+   
          
+     
        1. Change directory to where you want to store the LLVM object
+         files and run configure to configure the Makefiles and
+         header files for the default platform. Useful options include:
+       
            
+         
          • --with-llvmgccdir=directory
+             
            Specify the full pathname of where the LLVM GCC frontend is
+             installed.
            • 
+         
          • --enable-spec2000=directory
+             
            Enable the SPEC2000 benchmarks for testing.  The SPEC2000
+             benchmarks should be available in
+             directory.
            • 
+       
          
+   
        8. 
+ 
+   
      8. Build the LLVM Suite:
+   
          
+       
        1. Set your LLVM_LIB_SEARCH_PATH environment variable.
          2. 
+       
        2. gmake -k |& tee gnumake.out
+          # this is csh or tcsh syntax
          3. 
+       
        3. If you get an "internal compiler error (ICE)" see below.
          4. 
+   
        
+ 
+ 
      
+ 
+ 
      Consult the Getting Started with LLVM section for
+ detailed information on configuring and compiling LLVM.  See Setting Up Your Environment for tips that simplify
+ working with the GCC front end and LLVM tools.  Go to Program
+ Layout to learn about the layout of the source code tree.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Requirements
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Before you begin to use the LLVM system, review the requirements given below.
+ This may save you some trouble by knowing ahead of time what hardware and
+ software you will need.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Hardware
+ 
      
+ 
+ 
      
+ 
+ 
      LLVM is known to work on the following platforms:
      
+ 
+ 
+ 
+   
+   
+   
+ 
+ 
+   
+   
+   
+ 
+ 
+   
+   
+   
+ 
+ 
+   
+   
+   
+ 
+ 
+   
+   
+   
+ 
+ 
+   
+   
+   
+ 
+ 
      OSArchCompilers
      Linuxx861GCC
      SolarisV9 (Ultrasparc)GCC
      FreeBSDx861GCC
      MacOS X2PowerPCGCC
      Cygwin/Win32x861GCC
      
+ 
+ 
      LLVM has partial support for the following platforms:
      
+ 
+ 
+ 
+   
+   
+   
+ 
+ 
+   
+   
+   
+ 
+   
+   
+   
+ 
+ 
+   
+   
+   
+ 
+ 
      OSArchCompilers
      Windowsx861Visual Studio .NET4,5, MinGW
      AIX3,4PowerPCGCC
      Linux3,5PowerPCGCC
      
+ 
+ 
      
+ Notes:
      
+ 1 Code generation supported for Pentium processors and up
      
+ 2 Code generation supported for 32-bit ABI only
      
+ 3 No native code generation
      
+ 4 Build is not complete: one or more tools don't link
      
+ 5 The GCC-based C/C++ frontend does not build
      
+ 
      
+ 
+ 
      Note that you will need about 1-3 GB of space for a full LLVM build in Debug
+ mode, depending on the system (because of all the debug info), and the libraries
+ appear in more than one of the tools that get linked, so there is some
+ duplication.  If you do not need many of the tools and you are space-conscious,
+ you can disable them individually in llvm/tools/Makefile.  The Release
+ build requires considerably less space.
      
+ 
+ 
      The LLVM suite may compile on other platforms, but it is not
+ guaranteed to do so.  If compilation is successful, the LLVM utilities should be
+ able to assemble, disassemble, analyze, and optimize LLVM bytecode.  Code
+ generation should work as well, although the generated native code may not work
+ on your platform.
      
+ 
+ 
      The GCC front end is not very portable at the moment.  If you want to get it
+ to work on another platform, you can download a copy of the source and try to compile it on your platform.
      
+ 
+ 
      
+ 
+ 
+ 
      Software
      
+ 
      
+   
      Compiling LLVM requires that you have several software packages 
+   installed. The table below lists those required packages. The Package column
+   is the usual name for the software package that LLVM depends on. The Version
+   column provides "known to work" versions of the package. The Notes column
+   describes how LLVM uses the package and provides other details.
      
+   
+     
+ 
+     
+       
+       
+       
+     
+ 
+     
+       
+       
+       
+     
+ 
+     
+       
+       
+       
+     
+ 
+     
+       
+       
+       
+     
+ 
+     
+       
+       
+       
+     
+ 
+     
+       
+       
+       
+     
+ 
+     
+       
+       
+       
+     
+ 
+     
+       
+       
+     
+ 
+     
+       
+       
+       
+     
+ 
+     
+       
+       
+       
+     
+ 
+     
+       
+       
+       
+     
+ 
+     
+       
+       
+       
+     
+ 
+     
+       
+       
+       
+     
+ 
+   
      PackageVersionNotes
      GNU Make3.79, 3.79.1Makefile/build processor
      GCC3.4.2C/C++ compiler (Note 3)
      Flex2.5.4LEX compiler
      Bison1.35YACC compiler
      DejaGnu1.4.2Automated test suite (Note 2)
      tcl8.3, 8.4Automated test suite (Note 2)
      expect5.38.0Automated test suite (Note 2)
      GNU M4
+       1.4Macro processor for configuration (Note 1)
      GNU Autoconf2.59Configuration script builder (Note 1)
      GNU Automake1.9.2aclocal macro generator (Note 1)
      perl≥5.6.0Nightly tester, utilities
      libtool1.5.10Shared library manager (Note 1)
      CVS≥1.11CVS access to LLVM (Note 4)
      
+ 
+   
      Notes:
      
+   
        
+     
      1. If you want to make changes to the configure scripts, 
+       you will need GNU autoconf (2.59), and consequently, GNU M4 (version 1.4 
+       or higher). You will also need automake (1.9.2). We only use aclocal 
+       from that package.
        2. 
+     
      2. Only needed if you want to run the automated test 
+       suite in the test directory.
        3. 
+     
+     
      3. Only the C and C++ languages are needed so there's no
+       need to build the other languages for LLVM's purposes. See 
+       below for specific version info.
+     
        4. 
+     
      4. You only need CVS if you intend to build from the 
+       latest LLVM sources. If you're working from a release distribution, you
+       don't need CVS.
        5. 
+   
      
+   
      Additionally, your compilation host is expected to have the usual 
+   plethora of Unix utilities. Specifically:
      
+   
        
+     
      • ar - archive library builder
        • 
+     
      • bzip2* - bzip2 command for distribution generation
        • 
+     
      • bunzip2* - bunzip2 command for distribution checking
        • 
+     
      • chmod - change permissions on a file
        • 
+     
      • cat - output concatenation utility
        • 
+     
      • cp - copy files
        • 
+     
      • date - print the current date/time 
        • 
+     
      • echo - print to standard output
        • 
+     
      • egrep - extended regular expression search utility
        • 
+     
      • etags - C/C++ tag file creator for vim/emacs
        • 
+     
      • find - find files/dirs in a file system
        • 
+     
      • grep - regular expression search utility
        • 
+     
      • gzip* - gzip command for distribution generation
        • 
+     
      • gunzip* - gunzip command for distribution checking
        • 
+     
      • install - install directories/files 
        • 
+     
      • mkdir - create a directory
        • 
+     
      • mv - move (rename) files
        • 
+     
      • ranlib - symbol table builder for archive libraries
        • 
+     
      • rm - remove (delete) files and directories
        • 
+     
      • sed - stream editor for transforming output
        • 
+     
      • sh - Bourne shell for make build scripts
        • 
+     
      • tar - tape archive for distribution generation
        • 
+     
      • test - test things in file system
        • 
+     
      • unzip* - unzip command for distribution checking
        • 
+     
      • zip* - zip command for distribution generation
        • 
+   
      
+ 
      
+ 
+ 
+ 
      
+   Broken versions of GCC
+ 
      
+ 
+ 
      
+ 
+ 
      LLVM is very demanding of the host C++ compiler, and as such tends to expose
+ bugs in the compiler.  In particular, several versions of GCC crash when trying
+ to compile LLVM.  We routinely use GCC 3.3.3 and GCC 3.4.0 and have had success
+ with them.  Other versions of GCC will probably work as well.  GCC versions listed
+ here are known to not work.  If you are using one of these versions, please try
+ to upgrade your GCC to something more recent.  If you run into a problem with a
+ version of GCC not listed here, please let
+ us know.  Please use the "gcc -v" command to find out which version
+ of GCC you are using.
+ 
      
+ 
+ 
      GCC versions prior to 3.0: GCC 2.96.x and before had several
+ problems in the STL that effectively prevent it from compiling LLVM.
+ 
      
+ 
+ 
      GCC 3.2.2: This version of GCC fails to compile LLVM.
      
+ 
+ 
      GCC 3.3.2: This version of GCC suffered from a serious bug which causes it to crash in
+ the "convert_from_eh_region_ranges_1" GCC function.
      
+ 
      
+ 
+ 
+ 
+ 
+ 
      
+   Getting Started with LLVM
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      The remainder of this guide is meant to get you up and running with
+ LLVM and to give you some basic information about the LLVM environment.
      
+ 
+ 
      The later sections of this guide describe the general layout of the the LLVM source tree, a simple example using the LLVM tool chain, and links to find more information about LLVM or to get
+ help via e-mail.
      
+ 
      
+ 
+ 
+ 
      
+   Terminology and Notation
+ 
      
+ 
+ 
      
+ 
+ 
      Throughout this manual, the following names are used to denote paths
+ specific to the local system and working environment.  These are not
+ environment variables you need to set but just strings used in the rest
+ of this document below.  In any of the examples below, simply replace
+ each of these names with the appropriate pathname on your local system.
+ All these paths are absolute:
      
+ 
+ 
      
+     
      SRC_ROOT
+     
      
+     This is the top level directory of the LLVM source tree.
+     
      
+ 
+     
      OBJ_ROOT
+     
      
+     This is the top level directory of the LLVM object tree (i.e. the
+     tree where object files and compiled programs will be placed.  It
+     can be the same as SRC_ROOT).
+     
      
+ 
+     
      LLVMGCCDIR
+     
      
+     This is the where the LLVM GCC Front End is installed.
+     
      
+     For the pre-built GCC front end binaries, the LLVMGCCDIR is
+     cfrontend/platform/llvm-gcc.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Setting Up Your Environment
+ 
      
+ 
+ 
      
+ 
+ 
      
+ In order to compile and use LLVM, you will need to set some environment
+ variables.  There are also some shell aliases which you may find useful.
+ You can set these on the command line, or better yet, set them in your
+ .cshrc or .profile.
+ 
+ 
      
+     
      LLVM_LIB_SEARCH_PATH=LLVMGCCDIR/bytecode-libs
+     
      
+     This environment variable helps the LLVM GCC front end find bytecode
+     libraries that it will need for compilation.
+     
      
+ 
+     
      alias llvmgcc LLVMGCCDIR/bin/gcc
+     
      alias llvmg++ LLVMGCCDIR/bin/g++
+     
      
+     These aliases allow you to use the LLVM C and C++ front ends without putting
+     them in your PATH or typing in their complete pathnames.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Unpacking the LLVM Archives
+ 
      
+ 
+ 
      
+ 
+ 
      
+ If you have the LLVM distribution, you will need to unpack it before you
+ can begin to compile it.  LLVM is distributed as a set of two files: the LLVM
+ suite and the LLVM GCC front end compiled for your platform.  There is an
+ additional test suite that is optional.  Each file is a TAR archive that is
+ compressed with the gzip program.
+ 
      
+ 
+ 
       The files are as follows:
+ 
      
+   
      llvm-1.4.tar.gz
      
+   
      This is the source code for the LLVM libraries and tools.
      
+ 
+   
      llvm-test-1.4.tar.gz
      
+   
      This is the source code for the LLVM test suite.
      
+ 
+   
      cfrontend-1.4.source.tar.gz
      
+   
      This is the source release of the GCC front end.
      
+ 
+   
      cfrontend-1.4.sparc-sun-solaris2.8.tar.gz
      
+   
      This is the binary release of the GCC front end for Solaris/Sparc.
+   
      
+ 
+   
      cfrontend-1.4.i686-redhat-linux-gnu.tar.gz
      
+   
      This is the binary release of the GCC front end for Linux/x86.
      
+ 
+   
      cfrontend-1.4.i386-unknown-freebsd5.1.tar.gz
      
+   
      This is the binary release of the GCC front end for FreeBSD/x86.
      
+ 
+   
      cfrontend-1.4.powerpc-apple-darwin7.6.0.tar.gz
      
+   
      This is the binary release of the GCC front end for MacOS X/PPC.
      
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Checkout LLVM from CVS
+ 
      
+ 
+ 
      
+ 
+ 
      If you have access to our CVS repository, you can get a fresh copy of
+ the entire source code.  All you need to do is check it out from CVS as
+ follows:
      
+ 
+ 
        
+ 
      • cd where-you-want-llvm-to-live
+   
      • cvs -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm login
+   
      • Hit the return key when prompted for the password.
+   
      • cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co
+       llvm
+ 
      
+ 
+ 
      This will create an 'llvm' directory in the current
+ directory and fully populate it with the LLVM source code, Makefiles,
+ test directories, and local copies of documentation files.
      
+ 
+ 
      If you want to get a specific release (as opposed to the most recent
+ revision), you can specify a label.  The following releases have the following
+ label:
      
+ 
+ 
        
+ 
      • Release 1.4: RELEASE_14
        • 
+ 
      • Release 1.3: RELEASE_13
        • 
+ 
      • Release 1.2: RELEASE_12
        • 
+ 
      • Release 1.1: RELEASE_11
        • 
+ 
      • Release 1.0: RELEASE_1
        • 
+ 
      
+ 
+ 
      If you would like to get the LLVM test suite (a separate package as of 1.4),
+ you get it from the CVS repository:
      
+ 
      +   cd llvm/projects
+   cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co llvm-test
+ 
      
+ 
      By placing it in the llvm/projects, it will be automatically
+ configured by the LLVM configure script as well as automatically updated when
+ you run cvs update.
      
+ 
+ 
      If you would like to get the GCC front end source code, you can also get it
+ from the CVS repository:
      
+ 
+ 
      +   cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co llvm-gcc
+ 
      
+ 
+ 
      Please note that you must follow these 
+ instructions to successfully build the LLVM GCC front-end.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   LLVM CVS Mirrors
+ 
      
+ 
+ 
      
+ 
+ 
      If the main CVS server is overloaded or inaccessible, you can try one of
+ these user-hosted mirrors:
      
+ 
+ 
+ 
      
+ 
+ 
+ 
      
+   Install the GCC Front End
+ 
      
+ 
+ 
      
+ 
+ 
      Before configuring and compiling the LLVM suite, you need to extract the LLVM
+ GCC front end from the binary distribution.  It is used for building the
+ bytecode libraries later used by the GCC front end for linking programs, and its
+ location must be specified when the LLVM suite is configured.
      
+ 
+ 
      To install the GCC front end, do the following:
      
+ 
+ 
        
+   
      1. cd where-you-want-the-front-end-to-live
        2. 
+   
      2. gunzip --stdout cfrontend-version.platform.tar.gz | tar -xvf
+       -
        3. 
+ 
      
+ 
+ 
      Next, you will need to fix your system header files:
      
+ 
+ 
      cd cfrontend/platform
      
+    ./fixheaders
      
+ 
+ 
      The binary versions of the GCC front end may not suit all of your needs.  For
+ example, the binary distribution may include an old version of a system header
+ file, not "fix" a header file that needs to be fixed for GCC, or it may be
+ linked with libraries not available on your system.
      
+ 
+ 
      In cases like these, you may want to try building the GCC front end from source. This is
+ not for the faint of heart, so be forewarned.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Local LLVM Configuration
+ 
      
+ 
+ 
      
+ 
+ 
      Once checked out from the CVS repository, the LLVM suite source code must be
+ configured via the configure script.  This script sets variables in the
+ various *.in files, most notably llvm/Makefile.config and 
+ llvm/include/Config/config.h.  It also populates OBJ_ROOT with 
+ the Makefiles needed to begin building LLVM.
      
+ 
+ 
      The following environment variables are used by the configure
+ script to configure the build system:
      
+ 
+ 
+   
+   
+     
+     
+   
+   
+     
+     
+   
+ 
      VariablePurpose
      CCTells configure which C compiler to use.  By default,
+         configure will look for the first GCC C compiler in
+         PATH.  Use this variable to override
+         configure's default behavior.
      CXXTells configure which C++ compiler to use.  By default,
+        configure will look for the first GCC C++ compiler in
+        PATH.  Use this variable to override
+        configure's default behavior.
      
+ 
+ 
      The following options can be used to set or enable LLVM specific options:
      
+ 
+ 
      
+   
      --with-llvmgccdir=LLVMGCCDIR
      
+   
      
+     Path to the location where the LLVM GCC front end binaries and
+     associated libraries were installed.  This must be specified as an
+     absolute pathname.
+     
      
+   
      
+   
      --with-tclinclude
      
+   
      Path to the tcl include directory under which the tclsh can be
+   found. Use this if you have multiple tcl installations on your machine and you
+   want to use a specific one (8.x) for LLVM. LLVM only uses tcl for running the
+   dejagnu based test suite in llvm/test. If you don't specify this
+   option, the LLVM configure script will search for tcl 8.4 and 8.3 releases.
+   
      
+   
      
+   
      --enable-optimized
      
+   
      
+     Enables optimized compilation by default (debugging symbols are removed
+     and GCC optimization flags are enabled).  The default is to use an
+     unoptimized build (also known as a debug build).
+     
      
+   
      
+   
      --enable-jit
      
+   
      
+     Compile the Just In Time (JIT) compiler functionality.  This is not
+     available
+     on all platforms.  The default is dependent on platform, so it is best
+     to explicitly enable it if you want it.
+     
      
+   
      
+   
      --enable-doxygen
      
+   
      Look for the doxygen program and enable construction of doxygen based
+   documentation from the source code. This is disabled by default because 
+   generating the documentation can take a long time and producess 100s of 
+   megabytes of output.
      
+ 
      
+ 
+ 
      To configure LLVM, follow these steps:
      
+ 
+ 
        
+     
      1. Change directory into the object root directory:
+     
        
+     cd OBJ_ROOT
+     
        
+ 
+     
      2. Run the configure script located in the LLVM source tree:
+     
        
+     SRC_ROOT/configure --prefix=/install/path [other options]
+     
        
+ 
      
+ 
+ 
      In addition to running configure, you must set the
+ LLVM_LIB_SEARCH_PATH environment variable in your startup shell 
+ scripts.  This environment variable is used to locate "system" libraries like
+ "-lc" and "-lm" when linking.  This variable should be set to
+ the absolute path of the bytecode-libs subdirectory of the GCC front
+ end, or LLVMGCCDIR/bytecode-libs.  For example, one might set
+ LLVM_LIB_SEARCH_PATH to
+ /home/vadve/lattner/local/x86/llvm-gcc/bytecode-libs for the x86
+ version of the GCC front end on our research machines.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Compiling the LLVM Suite Source Code
+ 
      
+ 
+ 
      
+ 
+ 
      Once you have configured LLVM, you can build it.  There are three types of
+ builds:
      
+ 
+ 
      
+     
      Debug Builds
+     
      
+     These builds are the default when one types gmake (unless the
+     --enable-optimized option was used during configuration).  The
+     build system will compile the tools and libraries with debugging
+     information.
+     
      
+ 
+     
      Release (Optimized) Builds
+     
      
+     These builds are enabled with the --enable-optimized option to
+     configure or by specifying ENABLE_OPTIMIZED=1 on the
+     gmake command line.  For these builds, the build system will
+     compile the tools and libraries with GCC optimizations enabled and strip
+     debugging information from the libraries and executables it generates. 
+     
      
+ 
+     
      Profile Builds
+     
      
+     These builds are for use with profiling.  They compile profiling
+     information into the code for use with programs like gprof.
+     Profile builds must be started by specifying ENABLE_PROFILING=1
+     on the gmake command line.
+ 
      
+ 
+ 
      Once you have LLVM configured, you can build it by entering the
+ OBJ_ROOT directory and issuing the following command:
      
+ 
+ 
      gmake
      
+ 
+ 
      If the build fails, please check here to see if you
+ are using a version of GCC that is known not to compile LLVM.
      
+ 
+ 
      
+ If you have multiple processors in your machine, you may wish to use some of
+ the parallel build options provided by GNU Make.  For example, you could use the
+ command:
      
+ 
+ 
      gmake -j2
      
+ 
+ 
      There are several special targets which are useful when working with the LLVM
+ source code:
      
+ 
+ 
      
+   
      gmake clean
+   
      
+   Removes all files generated by the build.  This includes object files,
+   generated C/C++ files, libraries, and executables.
+   
      
+ 
+   
      gmake dist-clean
+   
      
+   Removes everything that gmake clean does, but also removes files
+   generated by configure.  It attempts to return the source tree to the
+   original state in which it was shipped.
+   
      
+ 
+   
      gmake install
+   
      
+   Installs LLVM header files, libraries, tools, and documentation in a
+   hierarchy 
+   under $PREFIX, specified with ./configure --prefix=[dir], which 
+   defaults to /usr/local.
+   
      
+   
+   
      gmake -C runtime install-bytecode
+   
      
+   Assuming you built LLVM into $OBJDIR, when this command is run, it will 
+   install bytecode libraries into the GCC front end's bytecode library 
+   directory.  If you need to update your bytecode libraries,
+   this is the target to use once you've built them.
+   
      
+ 
      
+ 
+ 
      Please see the Makefile Guide for further
+ details on these make targets and descriptions of other targets
+ available.
      
+ 
+ 
      It is also possible to override default values from configure by
+ declaring variables on the command line.  The following are some examples:
      
+ 
+ 
      
+   
      gmake ENABLE_OPTIMIZED=1
+   
      
+   Perform a Release (Optimized) build.
+   
      
+ 
+   
      gmake ENABLE_PROFILING=1
+   
      
+   Perform a Profiling build.
+   
      
+ 
+   
      gmake VERBOSE=1
+   
      
+   Print what gmake is doing on standard output.
+   
      
+ 
+   
      gmake TOOL_VERBOSE=1
      
+   
      Ask each tool invoked by the makefiles to print out what it is doing on 
+   the standard output. This also implies VERBOSE=1.
+   
      
+ 
      
+ 
+ 
      Every directory in the LLVM object tree includes a Makefile to build
+ it and any subdirectories that it contains.  Entering any directory inside the
+ LLVM object tree and typing gmake should rebuild anything in or below
+ that directory that is out of date.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The Location of LLVM Object Files
+ 
      
+ 
+ 
      
+ 
+ 
      The LLVM build system is capable of sharing a single LLVM source tree among
+ several LLVM builds.  Hence, it is possible to build LLVM for several different
+ platforms or configurations using the same source tree.
      
+ 
+ 
      This is accomplished in the typical autoconf manner:
      
+ 
+ 
        
+   
      • Change directory to where the LLVM object files should live:
        
+ 
+       
        cd OBJ_ROOT
        • 
+ 
+   
      • Run the configure script found in the LLVM source
+       directory:
        
+ 
+       
        SRC_ROOT/configure
        • 
+ 
      
+ 
+ 
      The LLVM build will place files underneath OBJ_ROOT in directories
+ named after the build type:
      
+ 
+ 
      
+   
      Debug Builds
+   
      
+   
      
+     
      Tools
+     
      OBJ_ROOT/Debug/bin
+     
      Libraries
+     
      OBJ_ROOT/Debug/lib
+   
      
+   
      
+ 
+   
      Release Builds
+   
      
+   
      
+     
      Tools
+     
      OBJ_ROOT/Release/bin
+     
      Libraries
+     
      OBJ_ROOT/Release/lib
+   
      
+   
      
+ 
+   
      Profile Builds
+   
      
+   
      
+     
      Tools
+     
      OBJ_ROOT/Profile/bin
+     
      Libraries
+     
      OBJ_ROOT/Profile/lib
+   
      
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Optional Configuration Items
+ 
      
+ 
+ 
      
+ 
+ 
      
+ If you're running on a linux system that supports the "
+   binfmt_misc"
+ module, and you have root access on the system, you can set your system up to
+ execute LLVM bytecode files directly.  To do this, use commands like this (the
+ first command may not be required if you are already using the module):
      
+ 
+ 
      +    $ mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
+    $ echo ':llvm:M::llvm::/path/to/lli:' > /proc/sys/fs/binfmt_misc/register
+    $ chmod u+x hello.bc                (if needed)
+    $ ./hello.bc
+ 
      
+ 
+ 
      
+ This allows you to execute LLVM bytecode files directly.  Thanks to Jack
+ Cummings for pointing this out!
+ 
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Program Layout
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      One useful source of information about the LLVM source base is the LLVM doxygen documentation available at http://llvm.cs.uiuc.edu/doxygen/.
+ The following is a brief introduction to code layout:
      
+ 
+ 
      
+ 
+ 
+ 
      CVS directories
      
+ 
      
+ 
      Every directory checked out of CVS will contain a CVS directory; for
+ the most part these can just be ignored.
      
+ 
      
+ 
+ 
+ 
      llvm/examples
      
+ 
      
+   
      This directory contains some simple examples of how to use the LLVM IR and
+   JIT.
      
+ 
      
+ 
+ 
+ 
      llvm/include
      
+ 
      
+ 
+ 
      This directory contains public header files exported from the LLVM
+ library. The three main subdirectories of this directory are:
      
+ 
+ 
      
+   
      llvm/include/llvm
      
+   
      This directory contains all of the LLVM specific header files.  This 
+   directory also has subdirectories for different portions of LLVM: 
+   Analysis, CodeGen, Target, Transforms, 
+   etc...
      
+ 
+   
      llvm/include/llvm/Support
      
+   
      This directory contains generic support libraries that are provided with 
+   LLVM but not necessarily specific to LLVM. For example, some C++ STL utilities 
+   and a Command Line option processing library store their header files here.
+   
      
+ 
+   
      llvm/include/llvm/Config
      
+   
      This directory contains header files configured by the configure 
+   script.  They wrap "standard" UNIX and C header files.  Source code can 
+   include these header files which automatically take care of the conditional 
+   #includes that the configure script generates.
      
+ 
      
+ 
      
+ 
+ 
+ 
      llvm/lib
      
+ 
      
+ 
+ 
      This directory contains most of the source files of the LLVM system. In LLVM,
+ almost all code exists in libraries, making it very easy to share code among the
+ different tools.
      
+ 
+ 
      
+   
      llvm/lib/VMCore/
      
+   
       This directory holds the core LLVM source files that implement core 
+   classes like Instruction and BasicBlock.
      
+ 
+   
      llvm/lib/AsmParser/
      
+   
      This directory holds the source code for the LLVM assembly language parser 
+   library.
      
+ 
+   
      llvm/lib/ByteCode/
      
+   
      This directory holds code for reading and write LLVM bytecode.
      
+ 
+   
      llvm/lib/Analysis/
      This directory contains a variety of
+   different program analyses, such as Dominator Information, Call Graphs,
+   Induction Variables, Interval Identification, Natural Loop Identification,
+   etc.
      
+ 
+   
      llvm/lib/Transforms/
      
+   
       This directory contains the source code for the LLVM to LLVM program 
+   transformations, such as Aggressive Dead Code Elimination, Sparse Conditional 
+   Constant Propagation, Inlining, Loop Invariant Code Motion, Dead Global 
+   Elimination, and many others.
      
+ 
+   
      llvm/lib/Target/
      
+   
       This directory contains files that describe various target architectures
+   for code generation.  For example, the llvm/lib/Target/SparcV9 
+   directory holds the Sparc machine description while
+   llvm/lib/Target/CBackend implements the LLVM-to-C converter
      
+     
+   
      llvm/lib/CodeGen/
      
+   
       This directory contains the major parts of the code generator: Instruction 
+   Selector, Instruction Scheduling, and Register Allocation.
      
+ 
+   
      llvm/lib/Debugger/
      
+   
       This directory contains the source level debugger library that makes 
+   it possible to instrument LLVM programs so that a debugger could identify 
+   source code locations at which the program is executing.
      
+ 
+   
      llvm/lib/ExecutionEngine/
      
+   
       This directory contains libraries for executing LLVM bytecode directly 
+   at runtime in both interpreted and JIT compiled fashions.
      
+ 
+   
      llvm/lib/Support/
      
+   
       This directory contains the source code that corresponds to the header 
+   files located in llvm/include/Support/.
      
+ 
+   
      llvm/lib/System/
      
+   
      This directory contains the operating system abstraction layer that
+   shields LLVM from platform-specific coding.
      
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      llvm/projects
      
+ 
      
+   
      This directory contains projects that are not strictly part of LLVM but are
+   shipped with LLVM. This is also the directory where you should create your own
+   LLVM-based projects. See llvm/projects/sample for an example of how
+   to set up your own project. See llvm/projects/Stacker for a fully 
+   functional example of a compiler front end.
      
+ 
      
+ 
+ 
+ 
      llvm/runtime
      
+ 
      
+ 
+ 
      This directory contains libraries which are compiled into LLVM bytecode and
+ used when linking programs with the GCC front end.  Most of these libraries are
+ skeleton versions of real libraries; for example, libc is a stripped down
+ version of glibc.
      
+ 
+ 
      Unlike the rest of the LLVM suite, this directory needs the LLVM GCC front
+ end to compile.
      
+ 
+ 
      
+ 
+ 
+ 
      llvm/test
      
+ 
      
+   
      This directory contains feature and regression tests and other basic sanity
+   checks on the LLVM infrastructure. These are intended to run quickly and cover
+   a lot of territory without being exhaustive.
      
+ 
      
+ 
+ 
+ 
      llvm-test
      
+ 
      
+   
      This is not a directory in the normal llvm module; it is a separate CVS
+   module that must be checked out (usually to projects/llvm-test). This
+   module contains a comprehensive correctness, performance, and benchmarking
+   test
+   suite for LLVM. It is a separate CVS module because not every LLVM user is
+   interested in downloading or building such a comprehensive test. For further
+   details on this test suite, please see the 
+   Testing Guide document.
      
+ 
      
+ 
+ 
+ 
      llvm/tools
      
+ 
      
+ 
+ 
      The tools directory contains the executables built out of the
+ libraries above, which form the main part of the user interface.  You can
+ always get help for a tool by typing tool_name --help.  The
+ following is a brief introduction to the most important tools.  More detailed
+ information is in the Command Guide.
      
+ 
+ 
      
+   
      analyze
      
+   
      analyze is used to run a specific
+   analysis on an input LLVM bytecode file and print out the results.  It is
+   primarily useful for debugging analyses, or familiarizing yourself with
+   what an analysis does.
      
+ 
+   
      bugpoint
      
+   
      bugpoint is used to debug
+   optimization passes or code generation backends by narrowing down the
+   given test case to the minimum number of passes and/or instructions that
+   still cause a problem, whether it is a crash or miscompilation. See HowToSubmitABug.html for more information
+   on using bugpoint.
      
+ 
+   
      llvmc
      
+   
      The LLVM Compiler Driver. This program can
+   be configured to utilize both LLVM and non-LLVM compilation tools to enable
+   pre-processing, translation, optimization, assembly, and linking of programs
+   all from one command line. llvmc also takes care of processing the
+   dependent libraries found in bytecode. This reduces the need to get the
+   traditional -l<name> options right on the command line. Please
+   note that this tool is new in 1.4 and considered experimental. It will be
+   fully supported in 1.5.
      
+ 
+   
      llvm-ar
      
+   
      The archiver produces an archive containing
+   the given LLVM bytecode files, optionally with an index for faster
+   lookup.
      
+   
+   
      llvm-as
      
+   
      The assembler transforms the human readable LLVM assembly to LLVM 
+   bytecode.
      
+ 
+   
      llvm-dis
      
+   
      The disassembler transforms the LLVM bytecode to human readable 
+   LLVM assembly.
      
+ 
+   
      llvm-ld
      
+   
      llvm-ld is very similar to gccld and provides a general purpose
+   and extensible linker for LLVM. This is the linker invoked by llvmc.
+   It allows optimization modules to be loaded so that language specific
+   optimizations can be applied at link time. Please note that this tool is new
+   in LLVM 1.4 and still considered experimental. It will be fully supported in
+   LLVM 1.5.
      
+ 
+   
      llvm-link
      
+   
      llvm-link, not surprisingly, links multiple LLVM modules into 
+   a single program.
      
+   
+   
      lli
      
+   
      lli is the LLVM interpreter, which
+   can directly execute LLVM bytecode (although very slowly...). In addition
+   to a simple interpreter, lli also has a tracing mode (entered by
+   specifying -trace on the command line). Finally, for
+   architectures that support it (currently x86, Sparc, and PowerPC), by default,
+   lli will function as a Just-In-Time compiler (if the
+   functionality was compiled in), and will execute the code much
+   faster than the interpreter.
      
+ 
+   
      llc
      
+   
       llc is the LLVM backend compiler, which
+   translates LLVM bytecode to a SPARC or x86 assembly file, or to C code (with
+   the -march=c option).
      
+ 
+   
      llvmgcc
      
+   
      llvmgcc is a GCC-based C frontend
+   that has been retargeted to emit LLVM code as the machine code output.  It
+   works just like any other GCC compiler, taking the typical -c, -S, -E,
+   -o options that are typically used.  The source code for the
+   llvmgcc tool is currently not included in the LLVM CVS tree
+   because it is quite large and not very interesting.
+   
      
+     
      
+       
      gccas
      
+       
      This tool is invoked by the llvmgcc frontend as the 
+       "assembler" part of the compiler.  This tool actually assembles LLVM 
+       assembly to LLVM bytecode, performs a variety of optimizations, and 
+       outputs LLVM bytecode.  Thus when you invoke 
+       llvmgcc -c x.c -o x.o, you are causing gccas to be 
+       run, which writes the x.o file (which is an LLVM bytecode file 
+       that can be disassembled or manipulated just like any other bytecode 
+       file).  The command line interface to gccas is designed to be 
+       as close as possible to the system `as' utility so that 
+       the gcc frontend itself did not have to be modified to interface to 
+       a "weird" assembler.
      
+ 
+       
      gccld
      
+       
      gccld links together several LLVM bytecode files into one 
+       bytecode file and does some optimization.  It is the linker invoked by 
+       the GCC frontend when multiple .o files need to be linked together.  
+       Like gccas, the command line interface of gccld is 
+       designed to match the system linker, to aid interfacing with the GCC 
+       frontend.
      
+     
      
+   
      
+   
      
+ 
+   
      opt
      
+   
      opt reads LLVM bytecode, applies a
+   series of LLVM to LLVM transformations (which are specified on the command
+   line), and then outputs the resultant bytecode.  The 'opt --help'
+   command is a good way to get a list of the program transformations
+   available in LLVM.
      
+ 
      
+ 
      
+ 
+ 
+ 
      llvm/utils
      
+ 
      
+ 
+ 
      This directory contains utilities for working with LLVM source code, and some
+ of the utilities are actually required as part of the build process because they
+ are code generators for parts of LLVM infrastructure.
      
+ 
+ 
      
+   
      Burg/ 
      Burg is an instruction selector
+   generator -- it builds trees on which it then performs pattern-matching to
+   select instructions according to the patterns the user has specified. Burg
+   is currently used in the Sparc V9 backend.
      
+ 
+   
      codegen-diff 
      codegen-diff is a script
+   that finds differences between code that LLC generates and code that LLI
+   generates. This is a useful tool if you are debugging one of them,
+   assuming that the other generates correct output. For the full user
+   manual, run `perldoc codegen-diff'.
      
+ 
+   
      cvsupdate 
      cvsupdate is a script that will
+   update your CVS tree, but produce a much cleaner and more organized output
+   than simply running `cvs -z3 up -dP' will. For example, it will group
+   together all the new and updated files and modified files in separate
+   sections, so you can see at a glance what has changed. If you are at the
+   top of your LLVM CVS tree, running utils/cvsupdate is the
+   preferred way of updating the tree.
      
+ 
+   
      emacs/ 
      The emacs directory contains
+   syntax-highlighting files which will work with Emacs and XEmacs editors,
+   providing syntax highlighting support for LLVM assembly files and TableGen
+   description files. For information on how to use the syntax files, consult
+   the README file in that directory.
      
+ 
+   
      getsrcs.sh 
      The getsrcs.sh script finds
+   and outputs all non-generated source files, which is useful if one wishes
+   to do a lot of development across directories and does not want to
+   individually find each file. One way to use it is to run, for example:
+   xemacs `utils/getsources.sh` from the top of your LLVM source
+   tree.
      
+   
+   
      llvmgrep
      
+   
      This little tool performs an "egrep -H -n" on each source file in LLVM and
+   passes to it a regular expression provided on llvmgrep's command
+   line. This is a very efficient way of searching the source base for a
+   particular regular expression.
      
+ 
+   
      makellvm 
      The makellvm script compiles all
+   files in the current directory and then compiles and links the tool that
+   is the first argument. For example, assuming you are in the directory
+   llvm/lib/Target/Sparc, if makellvm is in your path,
+   simply running makellvm llc will make a build of the current
+   directory, switch to directory llvm/tools/llc and build it,
+   causing a re-linking of LLC.
      
+ 
+   
      NightlyTest.pl and
+   NightlyTestTemplate.html 
      These files are used in a
+   cron script to generate nightly status reports of the functionality of
+   tools, and the results can be seen by following the appropriate link on
+   the LLVM homepage.
      
+ 
+   
      TableGen/ 
      The TableGen directory contains
+   the tool used to generate register descriptions, instruction set
+   descriptions, and even assemblers from common TableGen description
+   files.
      
+ 
+   
      vim/ 
      The vim directory contains
+   syntax-highlighting files which will work with the VIM editor, providing
+   syntax highlighting support for LLVM assembly files and TableGen
+   description files. For information on how to use the syntax files, consult
+   the README file in that directory.
      
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      llvm/win32
      
+ 
      
+   
      This directory contains build scripts and project files for use with 
+   Visual C++. This allows developers on Windows to build LLVM without the need
+   for Cygwin. The contents of this directory should be considered experimental
+   at this time.
+   
      
+ 
      
+ 
+ 
      
+   An Example Using the LLVM Tool Chain
+ 
      
+ 
+ 
+ 
      
+ 
+ 
        
+   
      1. First, create a simple C file, name it 'hello.c':
+        
        +    #include <stdio.h>
+    int main() {
+      printf("hello world\n");
+      return 0;
+    }
+        
        2. 
+ 
+   
      2. Next, compile the C file into a LLVM bytecode file:
        
+       
        % llvmgcc hello.c -o hello
        
+ 
+       
        Note that you should have already built the tools and they have to be
+       in your path, at least gccas and gccld.
        
+ 
+       
        This will create two result files: hello and
+       hello.bc. The hello.bc is the LLVM bytecode that
+       corresponds the the compiled program and the library facilities that it
+       required.  hello is a simple shell script that runs the bytecode
+       file with lli, making the result directly executable.  Note that
+       all LLVM optimizations are enabled by default, so there is no need for a 
+       "-O3" switch.
        3. 
+ 
+   
      3. Run the program. To make sure the program ran, execute one of the
+       following commands:
        
+       
+       
        % ./hello
        
+  
+       
        or
        
+ 
+       
        % lli hello.bc
        4. 
+ 
+   
      4. Use the llvm-dis utility to take a look at the LLVM assembly
+       code:
        
+ 
+       
        % llvm-dis < hello.bc | less
        5. 
+ 
+   
      5. Compile the program to native assembly using the LLC code
+       generator:
        
+ 
+       
        % llc hello.bc -o hello.s
        
+ 
+   
      6. Assemble the native assembly language file into a program:
        
+ 
+       
        Solaris:% /opt/SUNWspro/bin/cc -xarch=v9 hello.s -o hello.native
        
+       
        Others:% gcc hello.s -o hello.native
        
+ 
+   
      7. Execute the native code program:
        
+ 
+       
        % ./hello.native
        8. 
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Common Problems
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      If you are having problems building or using LLVM, or if you have any other
+ general questions about LLVM, please consult the Frequently
+ Asked Questions page.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Links
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      This document is just an introduction to how to use LLVM to do
+ some simple things... there are many more interesting and complicated things
+ that you can do that aren't documented here (but we'll gladly accept a patch
+ if you want to write something up!).  For more information about LLVM, check
+ out:
      
+ 
+ 
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Chris Lattner
      
+   Reid Spencer
      
+   The LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 


Index: llvm-www/releases/1.4/docs/HowToSubmitABug.html
diff -c /dev/null llvm-www/releases/1.4/docs/HowToSubmitABug.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/HowToSubmitABug.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,356 ----
+ 
+ 
+ 
+   How to submit an LLVM bug report
+   
+ 
+ 
+ 
+ 
      
+   How to submit an LLVM bug report
+ 
      
+ 
+ 
+ 
+   
+ 
+ 
+ 
      
+ 
        
+   
      1. Introduction - Got bugs?
        2. 
+   
      2. Crashing Bugs
+     
        3. 
+   
      3. Miscompilations
        4. 
+   
      4. Incorrect code generation (JIT and LLC)
        5. 
+ 
      
+ 
      
+   
      Written by Chris Lattner and
+                 Misha Brukman
      
+ 
      
+       		
+   Debugging
+ 
      
+ 
+ 
+ 
      
+   Introduction - Got bugs?
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      If you're working with LLVM and run into a bug, we definitely want to know
+ about it.  This document describes what you can do to increase the odds of
+ getting it fixed quickly.
      
+ 
+ 
      Basically you have to do two things at a minimum.  First, decide whether the
+ bug crashes the compiler (or an LLVM pass), or if the
+ compiler is miscompiling the program.  Based on
+ what type of bug it is, follow the instructions in the linked section to narrow
+ down the bug so that the person who fixes it will be able to find the problem
+ more easily.
      
+ 
+ 
      Once you have a reduced test-case, go to the LLVM Bug Tracking
+ System, select the category in which the bug falls, and fill out the form
+ with the necessary details.  The bug description should contain the following
+ information:
      
+ 
+ 
        
+   
      • All information necessary to reproduce the problem.
        • 
+   
      • The reduced test-case that triggers the bug.
        • 
+   
      • The location where you obtained LLVM (if not from our CVS
+   repository).
        • 
+ 
      
+ 
+ 
      Thanks for helping us make LLVM better!
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Crashing Bugs
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      More often than not, bugs in the compiler cause it to crash - often due to an
+ assertion failure of some sort.  If you are running opt or
+ analyze directly, and something crashes, jump to the section on
+ bugs in LLVM passes.  Otherwise, the most important
+ piece of the puzzle is to figure out if it is the GCC-based front-end that is
+ buggy or if it's one of the LLVM tools that has problems.
      
+ 
+ 
      To figure out which program is crashing (the front-end,
+ gccas, or gccld), run the
+ llvm-gcc command line as you were when the crash occurred, but
+ add a -v option to the command line.  The compiler will print out a
+ bunch of stuff, and should end with telling you that one of
+ cc1/cc1plus, gccas, or
+ gccld crashed.
      
+ 
+ 
        
+ 
+   
      • If cc1 or cc1plus crashed, you found a
+   problem with the front-end.
+   Jump ahead to the section on front-end bugs.
        • 
+ 
+   
      • If gccas crashed, you found a bug in one
+   of the passes in gccas.
        • 
+ 
+   
      • If gccld crashed, you found a bug in one
+   of the passes in gccld.
        • 
+ 
+   
      • Otherwise, something really weird happened. Email the list with what you
+   have at this point.
        • 
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Front-end bugs
+ 
      
+ 
+ 
      
+ 
+ 
      If the problem is in the front-end, you should re-run the same
+ llvm-gcc command that resulted in the crash, but add the
+ -save-temps option.  The compiler will crash again, but it will leave
+ behind a foo.i file (containing preprocessed C source code) and
+ possibly foo.s (containing LLVM assembly code), for each
+ compiled foo.c file. Send us the foo.i file,
+ along with a brief description of the error it caused.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   GCCAS bugs
+ 
      
+ 
+ 
      
+ 
+ 
      If you find that a bug crashes in the gccas stage of
+ compilation, compile your test-case to a .s file with the
+ -save-temps option to llvm-gcc. Then run:
      
+ 
+ 
      
+ 
      gccas -debug-pass=Arguments < /dev/null -o - > /dev/null
      
+ 
      
+ 
+ 
      ... which will print a list of arguments, indicating the list of passes that
+ gccas runs.  Once you have the input file and the list of
+ passes, go to the section on debugging bugs in LLVM
+ passes.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   GCCLD bugs
+ 
      
+ 
+ 
      
+ 
+ 
      If you find that a bug crashes in the gccld stage of
+ compilation, gather all of the .o bytecode files and libraries that are
+ being linked together (the "llvm-gcc -v" output should include
+ the full list of objects linked).  Then run:
      
+ 
+ 
      
+ 
      llvm-as < /dev/null > null.bc
      
+ gccld -debug-pass=Arguments null.bc      
+ 
      
+ 
      
+ 
+ 
      ... which will print a list of arguments, indicating the list of passes that
+ gccld runs.  Once you have the input files and the list of
+ passes, go to the section on debugging bugs in LLVM
+ passes.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Bugs in LLVM passes
+ 
      
+ 
+ 
      
+ 
+ 
      At this point, you should have some number of LLVM assembly files or bytecode
+ files and a list of passes which crash when run on the specified input.  In
+ order to reduce the list of passes (which is probably large) and the input to
+ something tractable, use the bugpoint tool as follows:
      
+ 
+ 
      
+ 
      bugpoint <input files> <list of passes>
      
+ 
      
+ 
+ 
      bugpoint will print a bunch of output as it reduces the
+ test-case, but it should eventually print something like this:
      
+ 
+ 
      
+ 
      
+ ...
      
+ Emitted bytecode to 'bugpoint-reduced-simplified.bc'
      
+ 
      
+ *** You can reproduce the problem with: opt bugpoint-reduced-simplified.bc -licm
      
+ 
      
+ 
      
+ 
+ 
      Once you complete this, please send the LLVM bytecode file and the command
+ line to reproduce the problem to the llvmbugs mailing list.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Miscompilations
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      A miscompilation occurs when a pass does not correctly transform a program,
+ thus producing errors that are only noticed during execution. This is different
+ from producing invalid LLVM code (i.e., code not in SSA form, using values
+ before defining them, etc.) which the verifier will check for after a pass
+ finishes its run.
      
+ 
+ 
      If it looks like the LLVM compiler is miscompiling a program, the very first
+ thing to check is to make sure it is not using undefined behavior.  In
+ particular, check to see if the program valgrinds clean, passes purify, or some
+ other memory checker tool.  Many of the "LLVM bugs" that we have chased down
+ ended up being bugs in the program being compiled, not LLVM.
      
+ 
+ 
      Once you determine that the program itself is not buggy, you should choose 
+ which code generator you wish to compile the program with (e.g. C backend, the 
+ JIT, or LLC) and optionally a series of LLVM passes to run.  For example:
      
+ 
+ 
      
+ 
      
+ bugpoint -run-cbe [... optzn passes ...] file-to-test.bc --args -- [program arguments]
      
+ 
      
+ 
+ 
      bugpoint will try to narrow down your list of passes to the one pass
+ that causes an error, and simplify the bytecode file as much as it can to assist
+ you. It will print a message letting you know how to reproduce the resulting
+ error.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Incorrect code generation
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Similarly to debugging incorrect compilation by mis-behaving passes, you can
+ debug incorrect code generation by either LLC or the JIT, using
+ bugpoint. The process bugpoint follows in this case is to try
+ to narrow the code down to a function that is miscompiled by one or the other
+ method, but since for correctness, the entire program must be run,
+ bugpoint will compile the code it deems to not be affected with the C
+ Backend, and then link in the shared object it generates.
      
+ 
+ 
      To debug the JIT:
      
+ 
+ 
      
+ 
      + bugpoint -run-jit -output=[correct output file] [bytecode file]  \
+          --tool-args -- [arguments to pass to lli]               \
+          --args -- [program arguments]
+ 
      
+ 
      
+ 
+ 
      Similarly, to debug the LLC, one would run:
      
+ 
+ 
      
+ 
      + bugpoint -run-llc -output=[correct output file] [bytecode file]  \
+          --tool-args -- [arguments to pass to llc]               \
+          --args -- [program arguments]
+ 
      
+ 
      
+ 
+ 
      Special note: if you are debugging MultiSource or SPEC tests that
+ already exist in the llvm/test hierarchy, there is an easier way to
+ debug the JIT, LLC, and CBE, using the pre-written Makefile targets, which
+ will pass the program options specified in the Makefiles:
      
+ 
+ 
      
+ 
      
+ cd llvm/test/../../program
      
+ make bugpoint-jit
+ 
      
+ 
      
+ 
+ 
      At the end of a successful bugpoint run, you will be presented
+ with two bytecode files: a safe file which can be compiled with the C
+ backend and the test file which either LLC or the JIT
+ mis-codegenerates, and thus causes the error.
      
+ 
+ 
      To reproduce the error that bugpoint found, it is sufficient to do
+ the following:
      
+ 
+ 
        
+ 
+ 
      1. Regenerate the shared object from the safe bytecode file:
        
+ 
+ 
        
+ 
        
+ llc -march=c safe.bc -o safe.c
        
+ gcc -shared safe.c -o safe.so
+ 
        
+ 
        2. 
+ 
+ 
      2. If debugging LLC, compile test bytecode native and link with the shared
+     object:
        
+ 
+ 
        
+ 
        
+ llc test.bc -o test.s -f
        
+ gcc test.s safe.so -o test.llc
        
+ ./test.llc [program options]
+ 
        
+ 
        3. 
+     
+ 
      3. If debugging the JIT, load the shared object and supply the test
+     bytecode:
        
+ 
+ 
        
+ 
        lli -load=safe.so test.bc [program options]
        
+ 
        4.   
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Chris Lattner
      
+   The LLVM Compiler Infrastructure
+   
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/LLVMVsTheWorld.html
diff -c /dev/null llvm-www/releases/1.4/docs/LLVMVsTheWorld.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/LLVMVsTheWorld.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,180 ----
+ 
+ 
+ 
+   
+   LLVM vs. the World - Comparing Compilers to Compilers
+ 
+ 
+ 
+ 
+ 
      
+   LLVM vs. the World - Comparing Compilers to Compilers
+ 
      
+ 
+ 
        
+   
      1. Introduction
        2. 
+   
      2. General Applicability
        3. 
+   
      3. Type System
        4. 
+   
      4. Control-flow and Data-flow Information
        5. 
+   
      5. Registers
        6. 
+   
      6. Programmer Interface
        7. 
+   
      7. Machine Code Emission
        8. 
+ 
      
+ 
+ 
      
+   
      Written by Brian R. Gaeke
      
+ 
      
+ 
+ 
+ 
      
+   Introduction
+ 
      
+ 
+ 
+ 
      
+ 
      Whether you are a stranger to LLVM or not, and whether you are considering
+ using it for your projects or not, you may find it useful to understand how we
+ compare ourselves to other well-known compilers. The following list of points
+ should help you understand -- from our point of view -- some of the important
+ ways in which we see LLVM as different from other selected compilers and
+ code generation systems.
      
+ 
+ 
      At the moment, we only compare ourselves below to GCC and GNU lightning, but we will try
+ to revise and expand it as our knowledge and experience permit. Contributions are
+ welcome.
      
+ 
      
+ 
+ 
+ 
      
+   General Applicability
+ 
      
+ 
+ 
+ 
      
+ 
      GNU lightning: Only currently usable for dynamic runtime emission of binary
+ machine code to memory. Supports one backend at a time.
      
+ 
+ 
      LLVM: Supports compilation of C and C++ (with more languages coming soon),
+ strong SSA-based optimization at compile-time, link-time, run-time, and
+ off-line, and multiple platform backends with Just-in-Time and ahead-of-time
+ compilation frameworks. (See our document on Lifelong
+ Code Optimization for more.)
      
+ 
+ 
      GCC: Many relatively mature platform backends support assembly-language code
+ generation from many source languages. No run-time compilation
+ support.
      
+ 
      
+ 
+ 
+ 
      
+   Type System
+ 
      
+ 
+ 
+ 
      
+ 
      GNU lightning: C integer types and "void *" are supported. No type checking
+ is performed. Explicit type casts are not typically necessary unless the
+ underlying machine-specific types are distinct (e.g., sign- or zero-extension is
+ apparently necessary, but casting "int" to "void *" would not be.)
+ Floating-point support may not work on all platforms (it does not appear to be
+ documented in the latest release).
      
+ 
+ 
      LLVM: Compositional type system based on C types, supporting structures,
+ opaque types, and C integer and floating point types. Explicit cast instructions
+ are required to transform a value from one type to another.
      
+ 
+ 
      GCC: Union of high-level types including those used in Pascal, C, C++, Ada,
+ Java, and FORTRAN.
      
+ 
      
+ 
+ 
+ 
      
+   Control-flow and Data-flow Information
+ 
      
+ 
+ 
+ 
      
+ 
      GNU lightning: No data-flow information encoded in the generated program. No
+ support for calculating CFG or def-use chains over generated programs.
      
+ 
+ 
      LLVM: Scalar values in Static Single-Assignment form; def-use chains and CFG
+ always implicitly available and automatically kept up to date.
      
+ 
+ 
      GCC: Trees and RTL do not directly encode data-flow info; but def-use chains
+ and CFGs can be calculated on the side. They are not automatically kept up to
+ date.
      
+ 
      
+ 
+ 
+ 
      
+   Registers
+ 
      
+ 
+ 
+ 
      
+ 
      GNU lightning: Very small fixed register set -- it takes the least common
+ denominator of supported platforms; basically it inherits its tiny register set
+ from IA-32, unnecessarily crippling targets like PowerPC with a large register
+ set.
      
+ 
+ 
      LLVM: An infinite register set, reduced to a particular platform's finite
+ register set by register allocator.
      
+ 
+ 
      GCC: Trees and RTL provide an arbitrarily large set of values.  Reduced to a
+ particular platform's finite register set by register allocator.
      
+ 
      
+ 
+ 
+ 
      
+   Programmer Interface
+ 
      
+ 
+ 
+ 
      
+ 
      GNU lightning: Library interface based on C preprocessor macros that emit
+ binary code for a particular instruction to memory. No support for manipulating
+ code before emission.
      
+ 
+ 
      LLVM: Library interface based on classes representing platform-independent
+ intermediate code (Instruction) and platform-dependent code (MachineInstr) which
+ can be manipulated arbitrarily and then emitted to memory.
      
+ 
+ 
      GCC: Internal header file interface (tree.h) to abstract syntax trees,
+ representing roughly the union of all possible supported source-language
+ constructs; also, an internal header file interface (rtl.h, rtl.def) to a
+ low-level IR called RTL which represents roughly the union of all possible
+ target machine instructions.
      
+ 
      
+ 
+ 
+ 
      
+   Machine Code Emission
+ 
      
+ 
+ 
+ 
      
+ 
      GNU lightning: Only supports binary machine code emission to memory.
      
+ 
+ 
      LLVM: Supports writing out assembly language to a file, and binary machine
+ code to memory, from the same back-end.
      
+ 
+ 
      GCC: Supports writing out assembly language to a file. No support for
+ emitting machine code to memory.
      
+ 
      
+ 
+ 
+ 
+ 
      
+ 
      
+   
      Brian R. Gaeke
      
+   The LLVM Compiler Infrastructure
+   
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/LangRef.html
diff -c /dev/null llvm-www/releases/1.4/docs/LangRef.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/LangRef.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,2920 ----
+ 
+ 
+ 
+   LLVM Assembly Language Reference Manual
+   
+   
+   
+   
+ 
+ 
+ 
+ 
+ 
       LLVM Language Reference Manual 
      
+ 
        
+   
      1. Abstract
        2. 
+   
      2. Introduction
        3. 
+   
      3. Identifiers
        4. 
+   
      4. High Level Structure
+     
          
+       
        1. Module Structure
          2. 
+       
        2. Linkage Types
          3. 
+       
        3. Global Variables
          4. 
+       
        4. Function Structure
          5. 
+     
        
+   
        5. 
+   
      5. Type System
+     
          
+       
        1. Primitive Types 	
+         
            
+           
          1. Type Classifications
            2. 
+         
          
+       
          2. 
+       
        2. Derived Types
+         
            
+           
          1. Array Type
            2. 
+           
          2. Function Type
            3. 
+           
          3. Pointer Type
            4. 
+           
          4. Structure Type
            5. 
+           
          5. Packed Type
            6. 
+         
          
+       
          3. 
+     
        
+   
        6. 
+   
      6. Constants
+     
          
+       
        1. Simple Constants
+       
        2. Aggregate Constants
+       
        3. Global Variable and Function Addresses
+       
        4. Undefined Values
+       
        5. Constant Expressions
+     
        
+   
        7. 
+   
      7. Instruction Reference
+     
          
+       
        1. Terminator Instructions
+         
            
+           
          1. 'ret' Instruction
            2. 
+           
          2. 'br' Instruction
            3. 
+           
          3. 'switch' Instruction
            4. 
+           
          4. 'invoke' Instruction
            5. 
+           
          5. 'unwind'  Instruction
            6. 
+           
          6. 'unreachable' Instruction
            7. 
+         
          
+       
          2. 
+       
        2. Binary Operations
+         
            
+           
          1. 'add' Instruction
            2. 
+           
          2. 'sub' Instruction
            3. 
+           
          3. 'mul' Instruction
            4. 
+           
          4. 'div' Instruction
            5. 
+           
          5. 'rem' Instruction
            6. 
+           
          6. 'setcc' Instructions
            7. 
+         
          
+       
          3. 
+       
        3. Bitwise Binary Operations
+         
            
+           
          1. 'and' Instruction
            2. 
+           
          2. 'or'  Instruction
            3. 
+           
          3. 'xor' Instruction
            4. 
+           
          4. 'shl' Instruction
            5. 
+           
          5. 'shr' Instruction
            6. 
+         
          
+       
          4. 
+       
        4. Memory Access Operations
+         
            
+           
          1. 'malloc'   Instruction
            2. 
+           
          2. 'free'     Instruction
            3. 
+           
          3. 'alloca'   Instruction
            4. 
+ 	 
          4. 'load'     Instruction
            5. 
+ 	 
          5. 'store'    Instruction
            6. 
+ 	 
          6. 'getelementptr' Instruction
            7. 
+         
          
+       
          5. 
+       
        5. Other Operations
+         
            
+           
          1. 'phi'   Instruction
            2. 
+           
          2. 'cast .. to' Instruction
            3. 
+           
          3. 'select' Instruction
            4. 
+           
          4. 'call'  Instruction
            5. 
+           
          5. 'vanext' Instruction
            6. 
+           
          6. 'vaarg'  Instruction
            7. 
+         
          
+       
          6. 
+     
        
+   
        8. 
+   
      8. Intrinsic Functions
+     
          
+       
        1. Variable Argument Handling Intrinsics
+         
            
+           
          1. 'llvm.va_start' Intrinsic
            2. 
+           
          2. 'llvm.va_end'   Intrinsic
            3. 
+           
          3. 'llvm.va_copy'  Intrinsic
            4. 
+         
          
+       
          2. 
+       
        2. Accurate Garbage Collection Intrinsics
+         
            
+           
          1. 'llvm.gcroot' Intrinsic
            2. 
+           
          2. 'llvm.gcread' Intrinsic
            3. 
+           
          3. 'llvm.gcwrite' Intrinsic
            4. 
+         
          
+       
          3. 
+       
        3. Code Generator Intrinsics
+         
            
+           
          1. 'llvm.returnaddress' Intrinsic
            2. 
+           
          2. 'llvm.frameaddress'   Intrinsic
            3. 
+         
          
+       
          4. 
+       
        4. Operating System Intrinsics
+         
            
+           
          1. 'llvm.readport' Intrinsic
            2. 
+           
          2. 'llvm.writeport' Intrinsic
            3. 
+           
          3. 'llvm.readio'   Intrinsic
            4. 
+           
          4. 'llvm.writeio'   Intrinsic
            5. 
+         
          
+       
        5. Standard C Library Intrinsics
+         
            
+           
          1. 'llvm.memcpy' Intrinsic
            2. 
+           
          2. 'llvm.memmove' Intrinsic
            3. 
+           
          3. 'llvm.memset' Intrinsic
            4. 
+           
          4. 'llvm.isunordered' Intrinsic
            5. 
+         
          
+       
          6. 
+       
        6. Debugger intrinsics
          7. 
+     
        
+   
        9. 
+ 
      
+ 
+ 
      
+   
      Written by Chris Lattner
+             and Vikram Adve
      
+ 
      
+ 
+ 
+ 
       Abstract 
      
+ 
+ 
+ 
      
+ 
      This document is a reference manual for the LLVM assembly language. 
+ LLVM is an SSA based representation that provides type safety,
+ low-level operations, flexibility, and the capability of representing
+ 'all' high-level languages cleanly.  It is the common code
+ representation used throughout all phases of the LLVM compilation
+ strategy.
      
+ 
      
+ 
+ 
+ 
       Introduction 
      
+ 
+ 
+ 
      
+ 
+ 
      The LLVM code representation is designed to be used in three
+ different forms: as an in-memory compiler IR, as an on-disk bytecode
+ representation (suitable for fast loading by a Just-In-Time compiler),
+ and as a human readable assembly language representation.  This allows
+ LLVM to provide a powerful intermediate representation for efficient
+ compiler transformations and analysis, while providing a natural means
+ to debug and visualize the transformations.  The three different forms
+ of LLVM are all equivalent.  This document describes the human readable
+ representation and notation.
      
+ 
+ 
      The LLVM representation aims to be a light-weight and low-level
+ while being expressive, typed, and extensible at the same time.  It
+ aims to be a "universal IR" of sorts, by being at a low enough level
+ that high-level ideas may be cleanly mapped to it (similar to how
+ microprocessors are "universal IR's", allowing many source languages to
+ be mapped to them).  By providing type information, LLVM can be used as
+ the target of optimizations: for example, through pointer analysis, it
+ can be proven that a C automatic variable is never accessed outside of
+ the current function... allowing it to be promoted to a simple SSA
+ value instead of a memory location.
      
+ 
+ 
      
+ 
+ 
+ 
       Well-Formedness 
      
+ 
+ 
      
+ 
+ 
      It is important to note that this document describes 'well formed'
+ LLVM assembly language.  There is a difference between what the parser
+ accepts and what is considered 'well formed'.  For example, the
+ following instruction is syntactically okay, but not well formed:
      
+ 
+ 
      +   %x = add int 1, %x
+ 
      
+ 
+ 
      ...because the definition of %x does not dominate all of
+ its uses. The LLVM infrastructure provides a verification pass that may
+ be used to verify that an LLVM module is well formed.  This pass is
+ automatically run by the parser after parsing input assembly, and by
+ the optimizer before it outputs bytecode.  The violations pointed out
+ by the verifier pass indicate bugs in transformation passes or input to
+ the parser.
      
+ 
+  
      
+ 
+ 
+ 
       Identifiers 
      
+ 
+ 
+ 
      
+ 
+ 
      LLVM uses three different forms of identifiers, for different
+ purposes:
      
+ 
+ 
        
+   
      1. Named values are represented as a string of characters with a '%' prefix.
+   For example, %foo, %DivisionByZero, %a.really.long.identifier.  The actual
+   regular expression used is '%[a-zA-Z$._][a-zA-Z$._0-9]*'.
+   Identifiers which require other characters in their names can be surrounded
+   with quotes.  In this way, anything except a " character can be used
+   in a name.
        2. 
+ 
+   
      2. Unnamed values are represented as an unsigned numeric value with a '%'
+   prefix.  For example, %12, %2, %44.
        3. 
+ 
+   
      3. Constants, which are described in a section about
+   constants, below.
        4. 
+ 
      
+ 
+ 
      LLVM requires that values start with a '%' sign for two reasons: Compilers
+ don't need to worry about name clashes with reserved words, and the set of
+ reserved words may be expanded in the future without penalty.  Additionally,
+ unnamed identifiers allow a compiler to quickly come up with a temporary
+ variable without having to avoid symbol table conflicts.
      
+ 
+ 
      Reserved words in LLVM are very similar to reserved words in other
+ languages. There are keywords for different opcodes ('add', 'cast', 'ret', etc...), for primitive type names ('void', 'uint', etc...),
+ and others.  These reserved words cannot conflict with variable names, because
+ none of them start with a '%' character.
      
+ 
+ 
      Here is an example of LLVM code to multiply the integer variable
+ '%X' by 8:
      
+ 
+ 
      The easy way:
      
+ 
+ 
      +   %result = mul uint %X, 8
+ 
      
+ 
+ 
      After strength reduction:
      
+ 
+ 
      +   %result = shl uint %X, ubyte 3
+ 
      
+ 
+ 
      And the hard way:
      
+ 
+ 
      +   add uint %X, %X           ; yields {uint}:%0
+   add uint %0, %0           ; yields {uint}:%1
+   %result = add uint %1, %1
+ 
      
+ 
+ 
      This last way of multiplying %X by 8 illustrates several
+ important lexical features of LLVM:
      
+ 
+ 
        
+ 
+   
      1. Comments are delimited with a ';' and go until the end of
+   line.
        2. 
+ 
+   
      2. Unnamed temporaries are created when the result of a computation is not
+   assigned to a named value.
        3. 
+ 
+   
      3. Unnamed temporaries are numbered sequentially
        4. 
+ 
+ 
      
+ 
+ 
      ...and it also show a convention that we follow in this document.  When
+ demonstrating instructions, we will follow an instruction with a comment that
+ defines the type and name of value produced.  Comments are shown in italic
+ text.
      
+ 
+ 
      
+ 
+ 
+ 
       High Level Structure 
      
+ 
+ 
+ 
+ 
       Module Structure
+ 
      
+ 
+ 
      
+ 
+ 
      LLVM programs are composed of "Module"s, each of which is a
+ translation unit of the input programs.  Each module consists of
+ functions, global variables, and symbol table entries.  Modules may be
+ combined together with the LLVM linker, which merges function (and
+ global variable) definitions, resolves forward declarations, and merges
+ symbol table entries. Here is an example of the "hello world" module:
      
+ 
+ 
      ; Declare the string constant as a global constant...
+ %.LC0 = internal constant [13 x sbyte] c"hello world\0A\00"          ; [13 x sbyte]*
+ 
+ ; External declaration of the puts function
+ declare int %puts(sbyte*)                                            ; int(sbyte*)* 
+ 
+ ; Definition of main function
+ int %main() {                                                        ; int()* 
+         ; Convert [13x sbyte]* to sbyte *...
+         %cast210 = getelementptr [13 x sbyte]* %.LC0, long 0, long 0 ; sbyte*
+ 
+         ; Call puts function to write out the string to stdout...
+         call int %puts(sbyte* %cast210)                              ; int
+         ret int 0
      }
      
+ 
+ 
      This example is made up of a global variable
+ named ".LC0", an external declaration of the "puts"
+ function, and a function definition
+ for "main".
      
+ 
+ 
      In general, a module is made up of a list of global values,
+ where both functions and global variables are global values.  Global values are
+ represented by a pointer to a memory location (in this case, a pointer to an
+ array of char, and a pointer to a function), and have one of the following linkage types.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Linkage Types
+ 
      
+ 
+ 
      
+ 
+ 
      
+ All Global Variables and Functions have one of the following types of linkage:
+ 
      
+ 
+ 
      
+ 
+   
      internal 
      
+ 
+   
      Global values with internal linkage are only directly accessible by
+   objects in the current module.  In particular, linking code into a module with
+   an internal global value may cause the internal to be renamed as necessary to
+   avoid collisions.  Because the symbol is internal to the module, all
+   references can be updated.  This corresponds to the notion of the
+   'static' keyword in C, or the idea of "anonymous namespaces" in C++.
+   
      
+ 
+   
      linkonce: 
      
+ 
+   
      "linkonce" linkage is similar to internal linkage, with
+   the twist that linking together two modules defining the same
+   linkonce globals will cause one of the globals to be discarded.  This
+   is typically used to implement inline functions.  Unreferenced
+   linkonce globals are allowed to be discarded.
+   
      
+ 
+   
      weak: 
      
+ 
+   
      "weak" linkage is exactly the same as linkonce linkage,
+   except that unreferenced weak globals may not be discarded.  This is
+   used to implement constructs in C such as "int X;" at global scope.
+   
      
+ 
+   
      appending: 
      
+ 
+   
      "appending" linkage may only be applied to global variables of
+   pointer to array type.  When two global variables with appending linkage are
+   linked together, the two global arrays are appended together.  This is the
+   LLVM, typesafe, equivalent of having the system linker append together
+   "sections" with identical names when .o files are linked.
+   
      
+ 
+   
      externally visible:
      
+ 
+   
      If none of the above identifiers are used, the global is externally
+   visible, meaning that it participates in linkage and can be used to resolve
+   external symbol references.
+   
      
+ 
      
+ 
+ 
      For example, since the ".LC0"
+ variable is defined to be internal, if another module defined a ".LC0"
+ variable and was linked with this one, one of the two would be renamed,
+ preventing a collision.  Since "main" and "puts" are
+ external (i.e., lacking any linkage declarations), they are accessible
+ outside of the current module.  It is illegal for a function declaration
+ to have any linkage type other than "externally visible".
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Global Variables
+ 
      
+ 
+ 
      
+ 
+ 
      Global variables define regions of memory allocated at compilation
+ time instead of run-time.  Global variables may optionally be
+ initialized.  A variable may be defined as a global "constant", which
+ indicates that the contents of the variable will never be modified
+ (enabling better optimization, allowing the global data to be placed in the
+ read-only section of an executable, etc).
      
+ 
+ 
      As SSA values, global variables define pointer values that are in
+ scope (i.e. they dominate) all basic blocks in the program.  Global
+ variables always define a pointer to their "content" type because they
+ describe a region of memory, and all memory objects in LLVM are
+ accessed through pointers.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Functions
+ 
      
+ 
+ 
      
+ 
+ 
      LLVM function definitions are composed of a (possibly empty) argument list,
+ an opening curly brace, a list of basic blocks, and a closing curly brace.  LLVM
+ function declarations are defined with the "declare" keyword, a
+ function name, and a function signature.
      
+ 
+ 
      A function definition contains a list of basic blocks, forming the CFG for
+ the function.  Each basic block may optionally start with a label (giving the
+ basic block a symbol table entry), contains a list of instructions, and ends
+ with a terminator instruction (such as a branch or
+ function return).
      
+ 
+ 
      The first basic block in program is special in two ways: it is immediately
+ executed on entrance to the function, and it is not allowed to have predecessor
+ basic blocks (i.e. there can not be any branches to the entry block of a
+ function).  Because the block can have no predecessors, it also cannot have any
+ PHI nodes.
      
+ 
+ 
      LLVM functions are identified by their name and type signature.  Hence, two
+ functions with the same name but different parameter lists or return values are
+ considered different functions, and LLVM will resolves references to each
+ appropriately.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
+ 
       Type System 
      
+ 
+ 
+ 
      
+ 
+ 
      The LLVM type system is one of the most important features of the
+ intermediate representation.  Being typed enables a number of
+ optimizations to be performed on the IR directly, without having to do
+ extra analyses on the side before the transformation.  A strong type
+ system makes it easier to read the generated code and enables novel
+ analyses and transformations that are not feasible to perform on normal
+ three address code representations.
      
+ 
+ 
      
+ 
+ 
+ 
       Primitive Types 
      
+ 
      
+ 
      The primitive types are the fundamental building blocks of the LLVM
+ system. The current set of primitive types are as follows:
      
+ 
+ 
+   
+     
+     
+   
+ 
      
+       
+         
+         
+         
+         
+         
+         
+         
+         
+         
+         
+       
      TypeDescription
      voidNo value
      ubyteUnsigned 8 bit value
      ushortUnsigned 16 bit value
      uintUnsigned 32 bit value
      ulongUnsigned 64 bit value
      float32 bit floating point value
      labelBranch destination
      
+           		
+       
+         
+           
+           
+           
+           
+           
+           
+           
+         
+       
      TypeDescription
      boolTrue or False value
      sbyteSigned 8 bit value
      shortSigned 16 bit value
      intSigned 32 bit value
      longSigned 64 bit value
      double64 bit floating point value
      
+     
      
+ 
      
+ 
+ 
+ 
       Type
+ Classifications 
      
+ 
      
+ 
      These different primitive types fall into a few useful
+ classifications:
      
+ 
+ 
+   
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+     
+       
+       
+     
+   
+ 
      ClassificationTypes
      signedsbyte, short, int, long, float, double
      unsignedubyte, ushort, uint, ulong
      integerubyte, sbyte, ushort, short, uint, int, ulong, long
      integralbool, ubyte, sbyte, ushort, short, uint, int, ulong, long
+       
      floating pointfloat, double
      first classbool, ubyte, sbyte, ushort, short, uint, int, ulong, long,
       
+       float, double, pointer, 
+       packed
      
+ 
+ 
      The first class types are perhaps the
+ most important.  Values of these types are the only ones which can be
+ produced by instructions, passed as arguments, or used as operands to
+ instructions.  This means that all structures and arrays must be
+ manipulated either by pointer or by component.
      
+ 
      
+ 
+ 
+ 
       Derived Types 
      
+ 
+ 
      
+ 
+ 
      The real power in LLVM comes from the derived types in the system. 
+ This is what allows a programmer to represent arrays, functions,
+ pointers, and other useful types.  Note that these derived types may be
+ recursive: For example, it is possible to have a two dimensional array.
      
+ 
+ 
      
+ 
+ 
+ 
       Array Type 
      
+ 
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      The array type is a very simple derived type that arranges elements
+ sequentially in memory.  The array type requires a size (number of
+ elements) and an underlying data type.
      
+ 
+ 
      Syntax:
      
+ 
+ 
      +   [<# elements> x <elementtype>]
+ 
      
+ 
+ 
      The number of elements is a constant integer value, elementtype may
+ be any type with a size.
      
+ 
+ 
      Examples:
      
+ 
+   
+     
+     
+   
+ 
      
+       [40 x int ]
      
+       [41 x int ]
      
+       [40 x uint]
      
+           		
+       Array of 40 integer values.
      
+       Array of 41 integer values.
      
+       Array of 40 unsigned integer values.
      
+     
      
+ 
      Here are some examples of multidimensional arrays:
      
+ 
+   
+     
+     
+   
+ 
      
+       [3 x [4 x int]]
      
+       [12 x [10 x float]]
      
+       [2 x [3 x [4 x uint]]]
      
+           		
+       3x4 array integer values.
      
+       12x10 array of single precision floating point values.
      
+       2x3x4 array of unsigned integer values.
      
+     
      
+ 
      
+ 
+ 
+ 
       Function Type 
      
+ 
      
+ 
      Overview:
      
+ 
      The function type can be thought of as a function signature.  It
+ consists of a return type and a list of formal parameter types. 
+ Function types are usually used to build virtual function tables
+ (which are structures of pointers to functions), for indirect function
+ calls, and when defining a function.
      
+ 
      
+ The return type of a function type cannot be an aggregate type.
+ 
      
+ 
      Syntax:
      
+ 
        <returntype> (<parameter list>)
      
+ 
      Where '<parameter list>' is a comma-separated list of type
+ specifiers.  Optionally, the parameter list may include a type ...,
+ which indicates that the function takes a variable number of arguments.
+ Variable argument functions can access their arguments with the variable argument handling intrinsic functions.
      
+ 
      Examples:
      
+ 
+   
+     
+     
+   
+ 
      
+       int (int) 
      
+       float (int, int *) *
      
+       int (sbyte *, ...)
      
+           		
+       function taking an int, returning an int
      
+       Pointer to a function that takes an
+       int and a pointer to int,
+       returning float.
      
+       A vararg function that takes at least one pointer 
+       to sbyte (signed char in C), which returns an integer.  This is 
+       the signature for printf in LLVM.
      
+     
      
+ 
+ 
      
+ 
+ 
       Structure Type 
      
+ 
      
+ 
      Overview:
      
+ 
      The structure type is used to represent a collection of data members
+ together in memory.  The packing of the field types is defined to match
+ the ABI of the underlying processor.  The elements of a structure may
+ be any type that has a size.
      
+ 
      Structures are accessed using 'load
+ and 'store' by getting a pointer to a
+ field with the 'getelementptr'
+ instruction.
      
+ 
      Syntax:
      
+ 
        { <type list> }
      
+ 
      Examples:
      
+ 
+   
+     
+     
+   
+ 
      
+       { int, int, int }
      
+       { float, int (int) * }
      
+           		
+       a triple of three int values
      
+       A pair, where the first element is a float and the second element 
+       is a pointer to a function 
+       that takes an int, returning an int.
      
+     
      
+ 
      
+ 
+ 
+ 
       Pointer Type 
      
+ 
      
+ 
      Overview:
      
+ 
      As in many languages, the pointer type represents a pointer or
+ reference to another object, which must live in memory.
      
+ 
      Syntax:
      
+ 
        <type> *
      
+ 
      Examples:
      
+ 
+   
+     
+     
+   
+ 
      
+       [4x int]*
      
+       int (int *) *
      
+           		
+       A pointer to array of
+       four int values
      
+       A pointer to a function that takes an int, returning an
+       int.
      
+     
      
+ 
      
+ 
+ 
+ 
       Packed Type 
      
+ 
      
+ 
      Overview:
      
+ 
      A packed type is a simple derived type that represents a vector
+ of elements.  Packed types are used when multiple primitive data 
+ are operated in parallel using a single instruction (SIMD). 
+ A packed type requires a size (number of
+ elements) and an underlying primitive data type.  Packed types are
+ considered first class.
      
+ 
      Syntax:
      
+ 
        < <# elements> x <elementtype> >
      
+ 
      The number of elements is a constant integer value, elementtype may
+ be any integral or floating point type.
      
+ 
      Examples:
      
+ 
+   
+     
+     
+   
+ 
      
+       <4 x int>
      
+       <8 x float>
      
+       <2 x uint>
      
+           		
+       Packed vector of 4 integer values.
      
+       Packed vector of 8 floating-point values.
      
+       Packed vector of 2 unsigned integer values.
      
+     
      
+ 
      
+ 
+ 
+ 
       Constants 
      
+ 
+ 
+ 
      
+ 
+ 
      LLVM has several different basic types of constants.  This section describes
+ them all and their syntax.
      
+ 
+ 
      
+ 
+ 
+ 
      Simple Constants
      
+ 
+ 
      
+ 
+ 
      
+   
      Boolean constants
      
+ 
+   
      The two strings 'true' and 'false' are both valid
+   constants of the bool type.
+   
      
+ 
+   
      Integer constants
      
+ 
+   
      Standard integers (such as '4') are constants of the integer type.  Negative numbers may be used with signed
+   integer types.
+   
      
+ 
+   
      Floating point constants
      
+ 
+   
      Floating point constants use standard decimal notation (e.g. 123.421),
+   exponential notation (e.g. 1.23421e+2), or a more precise hexadecimal
+   notation.  Floating point constants have an optional hexadecimal
+   notation (see below).  Floating point constants must have a floating point type. 
      
+ 
+   
      Null pointer constants
      
+ 
+   
      The identifier 'null' is recognized as a null pointer constant
+   and must be of pointer type.
      
+ 
+ 
      
+ 
+ 
      The one non-intuitive notation for constants is the optional hexadecimal form
+ of floating point constants.  For example, the form 'double
+ 0x432ff973cafa8000' is equivalent to (but harder to read than) 'double
+ 4.5e+15'.  The only time hexadecimal floating point constants are required
+ (and the only time that they are generated by the disassembler) is when a 
+ floating point constant must be emitted but it cannot be represented as a 
+ decimal floating point number.  For example, NaN's, infinities, and other 
+ special values are represented in their IEEE hexadecimal format so that 
+ assembly and disassembly do not cause any bits to change in the constants.
      
+ 
+ 
      
+ 
+ 
+ 
      Aggregate Constants
+ 
      
+ 
+ 
      
+ 
+ 
      
+   
      Structure constants
      
+ 
+   
      Structure constants are represented with notation similar to structure
+   type definitions (a comma separated list of elements, surrounded by braces
+   ({})).  For example: "{ int 4, float 17.0 }".  Structure
+   constants must have structure type, and the number and
+   types of elements must match those specified by the type.
+   
      
+ 
+   
      Array constants
      
+ 
+   
      Array constants are represented with notation similar to array type
+   definitions (a comma separated list of elements, surrounded by square brackets
+   ([])).  For example: "[ int 42, int 11, int 74 ]".  Array
+   constants must have array type, and the number and
+   types of elements must match those specified by the type.
+   
      
+ 
+   
      Packed constants
      
+ 
+   
      Packed constants are represented with notation similar to packed type
+   definitions (a comma separated list of elements, surrounded by
+   less-than/greater-than's (<>)).  For example: "< int 42,
+   int 11, int 74, int 100 >".  Packed constants must have packed type, and the number and types of elements must
+   match those specified by the type.
+   
      
+ 
+   
      Zero initialization
      
+ 
+   
      The string 'zeroinitializer' can be used to zero initialize a
+   value to zero of any type, including scalar and aggregate types.
+   This is often used to avoid having to print large zero initializers (e.g. for
+   large arrays), and is always exactly equivalent to using explicit zero
+   initializers.
+   
      
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Global Variable and Function Addresses
+ 
      
+ 
+ 
      
+ 
+ 
      The addresses of global variables and functions are always implicitly valid (link-time)
+ constants.  These constants are explicitly referenced when the identifier for the global is used and always have pointer type. For example, the following is a legal LLVM
+ file:
      
+ 
+ 
      +   %X = global int 17
+   %Y = global int 42
+   %Z = global [2 x int*] [ int* %X, int* %Y ]
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      Undefined Values
      
+ 
      
+   
      The string 'undef' is recognized as a type-less constant that has 
+   no specific value.  Undefined values may be of any type, and be used anywhere 
+   a constant is permitted.
      
+ 
+   
      Undefined values indicate to the compiler that the program is well defined
+   no matter what value is used, giving the compiler more freedom to optimize.
+   
      
+ 
      
+ 
+ 
+ 
      Constant Expressions
+ 
      
+ 
+ 
      
+ 
+ 
      Constant expressions are used to allow expressions involving other constants
+ to be used as constants.  Constant expressions may be of any first class type, and may involve any LLVM operation
+ that does not have side effects (e.g. load and call are not supported).  The
+ following is the syntax for constant expressions:
      
+ 
+ 
      
+   
      cast ( CST to TYPE )
      
+ 
+   
      Cast a constant to another type.
      
+ 
+   
      getelementptr ( CSTPTR, IDX0, IDX1, ... )
      
+ 
+   
      Perform the getelementptr operation on
+   constants.  As with the getelementptr
+   instruction, the index list may have zero or more indexes, which are required
+   to make sense for the type of "CSTPTR".
      
+ 
+   
      OPCODE ( LHS, RHS )
      
+ 
+   
      Perform the specified operation of the LHS and RHS constants. OPCODE may 
+   be any of the binary or bitwise
+   binary operations.  The constraints on operands are the same as those for
+   the corresponding instruction (e.g. no bitwise operations on floating point
+   are allowed).
      
+ 
      
+ 
      
+ 
+ 
+ 
       Instruction Reference 
      
+ 
+ 
+ 
      
+ 
+ 
      The LLVM instruction set consists of several different
+ classifications of instructions: terminator
+ instructions, binary instructions, memory instructions, and other
+ instructions.
      
+ 
+ 
      
+ 
+ 
+ 
       Terminator
+ Instructions 
      
+ 
+ 
      
+ 
+ 
      As mentioned previously, every
+ basic block in a program ends with a "Terminator" instruction, which
+ indicates which block should be executed after the current block is
+ finished. These terminator instructions typically yield a 'void'
+ value: they produce control flow, not values (the one exception being
+ the 'invoke' instruction).
      
+ 
      There are six different terminator instructions: the 'ret' instruction, the 'br'
+ instruction, the 'switch' instruction,
+ the 'invoke' instruction, the 'unwind' instruction, and the 'unreachable' instruction.
      
+ 
+ 
      
+ 
+ 
+ 
       'ret'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        ret <type> <value>       ; Return a value from a non-void function
+   ret void                 ; Return from void function
+ 
      
+ 
      Overview:
      
+ 
      The 'ret' instruction is used to return control flow (and a
+ value) from a function, back to the caller.
      
+ 
      There are two forms of the 'ret' instruction: one that
+ returns a value and then causes control flow, and one that just causes
+ control flow to occur.
      
+ 
      Arguments:
      
+ 
      The 'ret' instruction may return any 'first class' type.  Notice that a function is
+ not well formed if there exists a 'ret'
+ instruction inside of the function that returns a value that does not
+ match the return type of the function.
      
+ 
      Semantics:
      
+ 
      When the 'ret' instruction is executed, control flow
+ returns back to the calling function's context.  If the caller is a "call" instruction, execution continues at
+ the instruction after the call.  If the caller was an "invoke" instruction, execution continues
+ at the beginning "normal" of the destination block.  If the instruction
+ returns a value, that value shall set the call or invoke instruction's
+ return value.
      
+ 
      Example:
      
+ 
        ret int 5                       ; Return an integer value of 5
+   ret void                        ; Return from a void function
+ 
      
+ 
      
+ 
+ 
       'br' Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        br bool <cond>, label <iftrue>, label <iffalse>
        br label <dest>          ; Unconditional branch
+ 
      
+ 
      Overview:
      
+ 
      The 'br' instruction is used to cause control flow to
+ transfer to a different basic block in the current function.  There are
+ two forms of this instruction, corresponding to a conditional branch
+ and an unconditional branch.
      
+ 
      Arguments:
      
+ 
      The conditional branch form of the 'br' instruction takes a
+ single 'bool' value and two 'label' values.  The
+ unconditional form of the 'br' instruction takes a single 'label'
+ value as a target.
      
+ 
      Semantics:
      
+ 
      Upon execution of a conditional 'br' instruction, the 'bool'
+ argument is evaluated.  If the value is true, control flows
+ to the 'iftrue' label argument.  If "cond" is false,
+ control flows to the 'iffalse' label argument.
      
+ 
      Example:
      
+ 
      Test:
        %cond = seteq int %a, %b
        br bool %cond, label %IfEqual, label %IfUnequal
      IfEqual:
        ret int 1
      IfUnequal:
        ret int 0
      
+ 
      
+ 
+ 
      
+    'switch' Instruction
+ 
      
+ 
+ 
      
+ 
      Syntax:
      
+ 
+ 
      +   switch <intty> <value>, label <defaultdest> [ <intty> <val>, label <dest> ... ]
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      The 'switch' instruction is used to transfer control flow to one of
+ several different places.  It is a generalization of the 'br'
+ instruction, allowing a branch to occur to one of many possible
+ destinations.
      
+ 
+ 
+ 
      Arguments:
      
+ 
+ 
      The 'switch' instruction uses three parameters: an integer
+ comparison value 'value', a default 'label' destination, and
+ an array of pairs of comparison value constants and 'label's.  The
+ table is not allowed to contain duplicate constant entries.
      
+ 
+ 
      Semantics:
      
+ 
+ 
      The switch instruction specifies a table of values and
+ destinations. When the 'switch' instruction is executed, this
+ table is searched for the given value.  If the value is found, control flow is
+ transfered to the corresponding destination; otherwise, control flow is
+ transfered to the default destination.
      
+ 
+ 
      Implementation:
      
+ 
+ 
      Depending on properties of the target machine and the particular
+ switch instruction, this instruction may be code generated in different
+ ways.  For example, it could be generated as a series of chained conditional
+ branches or with a lookup table.
      
+ 
+ 
      Example:
      
+ 
+ 
      +  ; Emulate a conditional br instruction
+  %Val = cast bool %value to int
+  switch int %Val, label %truedest [int 0, label %falsedest ]
+ 
+  ; Emulate an unconditional br instruction
+  switch uint 0, label %dest [ ]
+ 
+  ; Implement a jump table:
+  switch uint %val, label %otherwise [ uint 0, label %onzero 
+                                       uint 1, label %onone 
+                                       uint 2, label %ontwo ]
+ 
      
+ 
      
+ 
+ 
       'invoke'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = invoke <ptr to function ty> %<function ptr val>(<function args>)
                       to label <normal label> except label <exception label>
      
+ 
      Overview:
      
+ 
      The 'invoke' instruction causes control to transfer to a
+ specified function, with the possibility of control flow transfer to
+ either the 'normal' label label or the 'exception'label.
+ If the callee function returns with the "ret"
+ instruction, control flow will return to the "normal" label.  If the
+ callee (or any indirect callees) returns with the "unwind"
+ instruction, control is interrupted, and continued at the dynamically
+ nearest "except" label.
      
+ 
      Arguments:
      
+ 
      This instruction requires several arguments:
      
+ 
        
+   
      1. 'ptr to function ty': shall be the signature of the
+ pointer to function value being invoked.  In most cases, this is a
+ direct function invocation, but indirect invokes are just as
+ possible, branching off an arbitrary pointer to function value. 
        2. 
+   
      2. 'function ptr val': An LLVM value containing a pointer
+ to a function to be invoked. 
        3. 
+   
      3. 'function args': argument list whose types match the
+ function signature argument types.  If the function signature indicates
+ the function accepts a variable number of arguments, the extra
+ arguments can be specified. 
        4. 
+   
      4. 'normal label': the label reached when the called
+ function executes a 'ret' instruction. 
        5. 
+   
      5. 'exception label': the label reached when a callee
+ returns with the unwind instruction. 
        6. 
+ 
      
+ 
      Semantics:
      
+ 
      This instruction is designed to operate as a standard 'call' instruction in most regards.  The
+ primary difference is that it establishes an association with a label,
+ which is used by the runtime library to unwind the stack.
      
+ 
      This instruction is used in languages with destructors to ensure
+ that proper cleanup is performed in the case of either a longjmp
+ or a thrown exception.  Additionally, this is important for
+ implementation of 'catch' clauses in high-level languages that
+ support them.
      
+ 
      Example:
      
+ 
        %retval = invoke int %Test(int 15)
                    to label %Continue
                    except label %TestCleanup     ; {int}:retval set
+ 
      
+ 
      
+ 
+ 
+ 
+ 
+ 
       'unwind'
+ Instruction 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
      +   unwind
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      The 'unwind' instruction unwinds the stack, continuing control flow
+ at the first callee in the dynamic call stack which used an invoke instruction to perform the call.  This is
+ primarily used to implement exception handling.
      
+ 
+ 
      Semantics:
      
+ 
+ 
      The 'unwind' intrinsic causes execution of the current function to
+ immediately halt.  The dynamic call stack is then searched for the first invoke instruction on the call stack.  Once found,
+ execution continues at the "exceptional" destination block specified by the
+ invoke instruction.  If there is no invoke instruction in the
+ dynamic call chain, undefined behavior results.
      
+ 
      
+ 
+ 
+ 
+ 
       'unreachable'
+ Instruction 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
      +   unreachable
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      The 'unreachable' instruction has no defined semantics.  This
+ instruction is used to inform the optimizer that a particular portion of the
+ code is not reachable.  This can be used to indicate that the code after a
+ no-return function cannot be reached, and other facts.
      
+ 
+ 
      Semantics:
      
+ 
+ 
      The 'unreachable' instruction has no defined semantics.
      
+ 
      
+ 
+ 
+ 
+ 
+ 
       Binary Operations 
      
+ 
      
+ 
      Binary operators are used to do most of the computation in a
+ program.  They require two operands, execute an operation on them, and
+ produce a single value.  The operands might represent 
+ multiple data, as is the case with the packed data type. 
+ The result value of a binary operator is not
+ necessarily the same type as its operands.
      
+ 
      There are several different binary operators:
      
+ 
      
+ 
+ 
       'add'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = add <ty> <var1>, <var2>   ; yields {ty}:result
+ 
      
+ 
      Overview:
      
+ 
      The 'add' instruction returns the sum of its two operands.
      
+ 
      Arguments:
      
+ 
      The two arguments to the 'add' instruction must be either integer or floating point values.
+  This instruction can also take packed versions of the values.
+ Both arguments must have identical types.
      
+ 
      Semantics:
      
+ 
      The value produced is the integer or floating point sum of the two
+ operands.
      
+ 
      Example:
      
+ 
        <result> = add int 4, %var          ; yields {int}:result = 4 + %var
+ 
      
+ 
      
+ 
+ 
       'sub'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = sub <ty> <var1>, <var2>   ; yields {ty}:result
+ 
      
+ 
      Overview:
      
+ 
      The 'sub' instruction returns the difference of its two
+ operands.
      
+ 
      Note that the 'sub' instruction is used to represent the 'neg'
+ instruction present in most other intermediate representations.
      
+ 
      Arguments:
      
+ 
      The two arguments to the 'sub' instruction must be either integer or floating point
+ values. 
+ This instruction can also take packed versions of the values.
+ Both arguments must have identical types.
      
+ 
      Semantics:
      
+ 
      The value produced is the integer or floating point difference of
+ the two operands.
      
+ 
      Example:
      
+ 
        <result> = sub int 4, %var          ; yields {int}:result = 4 - %var
+   <result> = sub int 0, %val          ; yields {int}:result = -%var
+ 
      
+ 
      
+ 
+ 
       'mul'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = mul <ty> <var1>, <var2>   ; yields {ty}:result
+ 
      
+ 
      Overview:
      
+ 
      The  'mul' instruction returns the product of its two
+ operands.
      
+ 
      Arguments:
      
+ 
      The two arguments to the 'mul' instruction must be either integer or floating point
+ values. 
+ This instruction can also take packed versions of the values.
+ Both arguments must have identical types.
      
+ 
      Semantics:
      
+ 
      The value produced is the integer or floating point product of the
+ two operands.
      
+ 
      There is no signed vs unsigned multiplication.  The appropriate
+ action is taken based on the type of the operand.
      
+ 
      Example:
      
+ 
        <result> = mul int 4, %var          ; yields {int}:result = 4 * %var
+ 
      
+ 
      
+ 
+ 
       'div'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = div <ty> <var1>, <var2>   ; yields {ty}:result
+ 
      
+ 
      Overview:
      
+ 
      The 'div' instruction returns the quotient of its two
+ operands.
      
+ 
      Arguments:
      
+ 
      The two arguments to the 'div' instruction must be either integer or floating point
+ values. 
+ This instruction can also take packed versions of the values.
+ Both arguments must have identical types.
      
+ 
      Semantics:
      
+ 
      The value produced is the integer or floating point quotient of the
+ two operands.
      
+ 
      Example:
      
+ 
        <result> = div int 4, %var          ; yields {int}:result = 4 / %var
+ 
      
+ 
      
+ 
+ 
       'rem'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = rem <ty> <var1>, <var2>   ; yields {ty}:result
+ 
      
+ 
      Overview:
      
+ 
      The 'rem' instruction returns the remainder from the
+ division of its two operands.
      
+ 
      Arguments:
      
+ 
      The two arguments to the 'rem' instruction must be either integer or floating point
+ values. 
+ This instruction can also take packed versions of the values.
+ Both arguments must have identical types.
      
+ 
      Semantics:
      
+ 
      This returns the remainder of a division (where the result
+ has the same sign as the divisor), not the modulus (where the
+ result has the same sign as the dividend) of a value.  For more
+ information about the difference, see: The
+ Math Forum.
      
+ 
      Example:
      
+ 
        <result> = rem int 4, %var          ; yields {int}:result = 4 % %var
+ 
      
+ 
      
+ 
+ 
       'setcc'
+ Instructions 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = seteq <ty> <var1>, <var2>   ; yields {bool}:result
+   <result> = setne <ty> <var1>, <var2>   ; yields {bool}:result
+   <result> = setlt <ty> <var1>, <var2>   ; yields {bool}:result
+   <result> = setgt <ty> <var1>, <var2>   ; yields {bool}:result
+   <result> = setle <ty> <var1>, <var2>   ; yields {bool}:result
+   <result> = setge <ty> <var1>, <var2>   ; yields {bool}:result
+ 
      
+ 
      Overview:
      
+ 
      The 'setcc' family of instructions returns a boolean
+ value based on a comparison of their two operands.
      
+ 
      Arguments:
      
+ 
      The two arguments to the 'setcc' instructions must
+ be of first class type (it is not possible
+ to compare 'label's, 'array's, 'structure'
+ or 'void' values, etc...).  Both arguments must have identical
+ types.
      
+ 
      Semantics:
      
+ 
      The 'seteq' instruction yields a true 'bool'
+ value if both operands are equal.
      
+ The 'setne' instruction yields a true 'bool'
+ value if both operands are unequal.
      
+ The 'setlt' instruction yields a true 'bool'
+ value if the first operand is less than the second operand.
      
+ The 'setgt' instruction yields a true 'bool'
+ value if the first operand is greater than the second operand.
      
+ The 'setle' instruction yields a true 'bool'
+ value if the first operand is less than or equal to the second operand.
      
+ The 'setge' instruction yields a true 'bool'
+ value if the first operand is greater than or equal to the second
+ operand.
      
+ 
      Example:
      
+ 
        <result> = seteq int   4, 5        ; yields {bool}:result = false
+   <result> = setne float 4, 5        ; yields {bool}:result = true
+   <result> = setlt uint  4, 5        ; yields {bool}:result = true
+   <result> = setgt sbyte 4, 5        ; yields {bool}:result = false
+   <result> = setle sbyte 4, 5        ; yields {bool}:result = true
+   <result> = setge sbyte 4, 5        ; yields {bool}:result = false
+ 
      
+ 
      
+ 
+ 
       Bitwise Binary
+ Operations 
      
+ 
      
+ 
      Bitwise binary operators are used to do various forms of
+ bit-twiddling in a program.  They are generally very efficient
+ instructions and can commonly be strength reduced from other
+ instructions.  They require two operands, execute an operation on them,
+ and produce a single value.  The resulting value of the bitwise binary
+ operators is always the same type as its first operand.
      
+ 
      
+ 
+ 
       'and'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = and <ty> <var1>, <var2>   ; yields {ty}:result
+ 
      
+ 
      Overview:
      
+ 
      The 'and' instruction returns the bitwise logical and of
+ its two operands.
      
+ 
      Arguments:
      
+ 
      The two arguments to the 'and' instruction must be integral values.  Both arguments must have
+ identical types.
      
+ 
      Semantics:
      
+ 
      The truth table used for the 'and' instruction is:
      
+ 
       
      
+ 
      
+ 
+   
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+   
+ 
      In0In1Out
      000
      010
      100
      111
      
+ 
      
+ 
      Example:
      
+ 
        <result> = and int 4, %var         ; yields {int}:result = 4 & %var
+   <result> = and int 15, 40          ; yields {int}:result = 8
+   <result> = and int 4, 8            ; yields {int}:result = 0
+ 
      
+ 
      
+ 
+ 
       'or' Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = or <ty> <var1>, <var2>   ; yields {ty}:result
+ 
      
+ 
      Overview:
      
+ 
      The 'or' instruction returns the bitwise logical inclusive
+ or of its two operands.
      
+ 
      Arguments:
      
+ 
      The two arguments to the 'or' instruction must be integral values.  Both arguments must have
+ identical types.
      
+ 
      Semantics:
      
+ 
      The truth table used for the 'or' instruction is:
      
+ 
       
      
+ 
      
+ 
+   
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+   
+ 
      In0In1Out
      000
      011
      101
      111
      
+ 
      
+ 
      Example:
      
+ 
        <result> = or int 4, %var         ; yields {int}:result = 4 | %var
+   <result> = or int 15, 40          ; yields {int}:result = 47
+   <result> = or int 4, 8            ; yields {int}:result = 12
+ 
      
+ 
      
+ 
+ 
       'xor'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = xor <ty> <var1>, <var2>   ; yields {ty}:result
+ 
      
+ 
      Overview:
      
+ 
      The 'xor' instruction returns the bitwise logical exclusive
+ or of its two operands.  The xor is used to implement the
+ "one's complement" operation, which is the "~" operator in C.
      
+ 
      Arguments:
      
+ 
      The two arguments to the 'xor' instruction must be integral values.  Both arguments must have
+ identical types.
      
+ 
      Semantics:
      
+ 
      The truth table used for the 'xor' instruction is:
      
+ 
       
      
+ 
      
+ 
+   
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+     
+       
+       
+       
+     
+   
+ 
      In0In1Out
      000
      011
      101
      110
      
+ 
      
+ 
       
      
+ 
      Example:
      
+ 
        <result> = xor int 4, %var         ; yields {int}:result = 4 ^ %var
+   <result> = xor int 15, 40          ; yields {int}:result = 39
+   <result> = xor int 4, 8            ; yields {int}:result = 12
+   <result> = xor int %V, -1          ; yields {int}:result = ~%V
+ 
      
+ 
      
+ 
+ 
       'shl'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = shl <ty> <var1>, ubyte <var2>   ; yields {ty}:result
+ 
      
+ 
      Overview:
      
+ 
      The 'shl' instruction returns the first operand shifted to
+ the left a specified number of bits.
      
+ 
      Arguments:
      
+ 
      The first argument to the 'shl' instruction must be an integer type.  The second argument must be an 'ubyte'
+ type.
      
+ 
      Semantics:
      
+ 
      The value produced is var1 * 2var2.
      
+ 
      Example:
      
+ 
        <result> = shl int 4, ubyte %var   ; yields {int}:result = 4 << %var
+   <result> = shl int 4, ubyte 2      ; yields {int}:result = 16
+   <result> = shl int 1, ubyte 10     ; yields {int}:result = 1024
+ 
      
+ 
      
+ 
+ 
       'shr'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = shr <ty> <var1>, ubyte <var2>   ; yields {ty}:result
+ 
      
+ 
      Overview:
      
+ 
      The 'shr' instruction returns the first operand shifted to
+ the right a specified number of bits.
      
+ 
      Arguments:
      
+ 
      The first argument to the 'shr' instruction must be an integer type.  The second argument must be an 'ubyte'
+ type.
      
+ 
      Semantics:
      
+ 
      If the first argument is a signed type, the
+ most significant bit is duplicated in the newly free'd bit positions. 
+ If the first argument is unsigned, zero bits shall fill the empty
+ positions.
      
+ 
      Example:
      
+ 
        <result> = shr int 4, ubyte %var   ; yields {int}:result = 4 >> %var
+   <result> = shr uint 4, ubyte 1     ; yields {uint}:result = 2
+   <result> = shr int 4, ubyte 2      ; yields {int}:result = 1
+   <result> = shr sbyte 4, ubyte 3    ; yields {sbyte}:result = 0
+   <result> = shr sbyte -2, ubyte 1   ; yields {sbyte}:result = -1
+ 
      
+ 
      
+ 
+ 
       Memory Access
+ Operations
      
+ 
      
+ 
      A key design point of an SSA-based representation is how it
+ represents memory.  In LLVM, no memory locations are in SSA form, which
+ makes things very simple.  This section describes how to read, write,
+ allocate, and free memory in LLVM.
      
+ 
      
+ 
+ 
       'malloc'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = malloc <type>, uint <NumElements>     ; yields {type*}:result
+   <result> = malloc <type>                         ; yields {type*}:result
+ 
      
+ 
      Overview:
      
+ 
      The 'malloc' instruction allocates memory from the system
+ heap and returns a pointer to it.
      
+ 
      Arguments:
      
+ 
      The 'malloc' instruction allocates sizeof(<type>)*NumElements
+ bytes of memory from the operating system and returns a pointer of the
+ appropriate type to the program.  The second form of the instruction is
+ a shorter version of the first instruction that defaults to allocating
+ one element.
      
+ 
      'type' must be a sized type.
      
+ 
      Semantics:
      
+ 
      Memory is allocated using the system "malloc" function, and
+ a pointer is returned.
      
+ 
      Example:
      
+ 
        %array  = malloc [4 x ubyte ]                    ; yields {[%4 x ubyte]*}:array
+ 
+   %size   = add uint 2, 2                          ; yields {uint}:size = uint 4
+   %array1 = malloc ubyte, uint 4                   ; yields {ubyte*}:array1
+   %array2 = malloc [12 x ubyte], uint %size        ; yields {[12 x ubyte]*}:array2
+ 
      
+ 
      
+ 
+ 
       'free'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        free <type> <value>                              ; yields {void}
+ 
      
+ 
      Overview:
      
+ 
      The 'free' instruction returns memory back to the unused
+ memory heap, to be reallocated in the future.
      
+ 
       
      
+ 
      Arguments:
      
+ 
      'value' shall be a pointer value that points to a value
+ that was allocated with the 'malloc'
+ instruction.
      
+ 
      Semantics:
      
+ 
      Access to the memory pointed to by the pointer is no longer defined
+ after this instruction executes.
      
+ 
      Example:
      
+ 
        %array  = malloc [4 x ubyte]                    ; yields {[4 x ubyte]*}:array
+             free   [4 x ubyte]* %array
+ 
      
+ 
      
+ 
+ 
       'alloca'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = alloca <type>, uint <NumElements>  ; yields {type*}:result
+   <result> = alloca <type>                      ; yields {type*}:result
+ 
      
+ 
      Overview:
      
+ 
      The 'alloca' instruction allocates memory on the current
+ stack frame of the procedure that is live until the current function
+ returns to its caller.
      
+ 
      Arguments:
      
+ 
      The 'alloca' instruction allocates sizeof(<type>)*NumElements
+ bytes of memory on the runtime stack, returning a pointer of the
+ appropriate type to the program.  The second form of the instruction is
+ a shorter version of the first that defaults to allocating one element.
      
+ 
      'type' may be any sized type.
      
+ 
      Semantics:
      
+ 
      Memory is allocated, a pointer is returned.  'alloca'd
+ memory is automatically released when the function returns.  The 'alloca'
+ instruction is commonly used to represent automatic variables that must
+ have an address available.  When the function returns (either with the ret or invoke
+ instructions), the memory is reclaimed.
      
+ 
      Example:
      
+ 
        %ptr = alloca int                              ; yields {int*}:ptr
+   %ptr = alloca int, uint 4                      ; yields {int*}:ptr
+ 
      
+ 
      
+ 
+ 
       'load'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = load <ty>* <pointer>
        <result> = volatile load <ty>* <pointer>
      
+ 
      Overview:
      
+ 
      The 'load' instruction is used to read from memory.
      
+ 
      Arguments:
      
+ 
      The argument to the 'load' instruction specifies the memory
+ address to load from.  The pointer must point to a first class type.  If the load is
+ marked as volatile then the optimizer is not allowed to modify
+ the number or order of execution of this load with other
+ volatile load and store
+ instructions. 
      
+ 
      Semantics:
      
+ 
      The location of memory pointed to is loaded.
      
+ 
      Examples:
      
+ 
        %ptr = alloca int                               ; yields {int*}:ptr
+   store int 3, int* %ptr                          ; yields {void}
+   %val = load int* %ptr                           ; yields {int}:val = int 3
+ 
      
+ 
      
+ 
+ 
       'store'
+ Instruction 
      
+ 
      Syntax:
      
+ 
        store <ty> <value>, <ty>* <pointer>                   ; yields {void}
+   volatile store <ty> <value>, <ty>* <pointer>                   ; yields {void}
+ 
      
+ 
      Overview:
      
+ 
      The 'store' instruction is used to write to memory.
      
+ 
      Arguments:
      
+ 
      There are two arguments to the 'store' instruction: a value
+ to store and an address to store it into.  The type of the '<pointer>'
+ operand must be a pointer to the type of the '<value>'
+ operand. If the store is marked as volatile then the
+ optimizer is not allowed to modify the number or order of execution of
+ this store with other volatile load and store instructions.
      
+ 
      Semantics:
      
+ 
      The contents of memory are updated to contain '<value>'
+ at the location specified by the '<pointer>' operand.
      
+ 
      Example:
      
+ 
        %ptr = alloca int                               ; yields {int*}:ptr
+   store int 3, int* %ptr                          ; yields {void}
+   %val = load int* %ptr                           ; yields {int}:val = int 3
+ 
      
+ 
+ 
      
+    'getelementptr' Instruction
+ 
      
+ 
+ 
      
+ 
      Syntax:
      
+ 
      +   <result> = getelementptr <ty>* <ptrval>{, <ty> <idx>}*
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      
+ The 'getelementptr' instruction is used to get the address of a
+ subelement of an aggregate data structure.
      
+ 
+ 
      Arguments:
      
+ 
+ 
      This instruction takes a list of integer constants that indicate what
+ elements of the aggregate object to index to.  The actual types of the arguments
+ provided depend on the type of the first pointer argument.  The
+ 'getelementptr' instruction is used to index down through the type
+ levels of a structure.  When indexing into a structure, only uint
+ integer constants are allowed.  When indexing into an array or pointer
+ int and long indexes are allowed of any sign.
      
+ 
+ 
      For example, let's consider a C code fragment and how it gets
+ compiled to LLVM:
      
+ 
+ 
      +   struct RT {
+     char A;
+     int B[10][20];
+     char C;
+   };
+   struct ST {
+     int X;
+     double Y;
+     struct RT Z;
+   };
+ 
+   int *foo(struct ST *s) {
+     return &s[1].Z.B[5][13];
+   }
+ 
      
+ 
+ 
      The LLVM code generated by the GCC frontend is:
      
+ 
+ 
      +   %RT = type { sbyte, [10 x [20 x int]], sbyte }
+   %ST = type { int, double, %RT }
+ 
+   implementation
+ 
+   int* %foo(%ST* %s) {
+   entry:
+     %reg = getelementptr %ST* %s, int 1, uint 2, uint 1, int 5, int 13
+     ret int* %reg
+   }
+ 
      
+ 
+ 
      Semantics:
      
+ 
+ 
      The index types specified for the 'getelementptr' instruction depend
+ on the pointer type that is being index into. Pointer
+ and array types require uint, int,
+ ulong, or long values, and structure
+ types require uint constants.
      
+ 
+ 
      In the example above, the first index is indexing into the '%ST*'
+ type, which is a pointer, yielding a '%ST' = '{ int, double, %RT
+ }' type, a structure.  The second index indexes into the third element of
+ the structure, yielding a '%RT' = '{ sbyte, [10 x [20 x int]],
+ sbyte }' type, another structure.  The third index indexes into the second
+ element of the structure, yielding a '[10 x [20 x int]]' type, an
+ array.  The two dimensions of the array are subscripted into, yielding an
+ 'int' type.  The 'getelementptr' instruction return a pointer
+ to this element, thus computing a value of 'int*' type.
      
+ 
+ 
      Note that it is perfectly legal to index partially through a
+ structure, returning a pointer to an inner element.  Because of this,
+ the LLVM code for the given testcase is equivalent to:
      
+ 
+ 
      +   int* "foo"(%ST* %s) {
+     %t1 = getelementptr %ST* %s, int 1                        ; yields %ST*:%t1
+     %t2 = getelementptr %ST* %t1, int 0, uint 2               ; yields %RT*:%t2
+     %t3 = getelementptr %RT* %t2, int 0, uint 1               ; yields [10 x [20 x int]]*:%t3
+     %t4 = getelementptr [10 x [20 x int]]* %t3, int 0, int 5  ; yields [20 x int]*:%t4
+     %t5 = getelementptr [20 x int]* %t4, int 0, int 13        ; yields int*:%t5
+     ret int* %t5
+   }
+ 
      
+ 
      Example:
      
+ 
      +     ; yields [12 x ubyte]*:aptr
+     %aptr = getelementptr {int, [12 x ubyte]}* %sptr, long 0, uint 1
+ 
      
+ 
+ 
      
+ 
+ 
       Other Operations 
      
+ 
      
+ 
      The instructions in this category are the "miscellaneous"
+ instructions, which defy better classification.
      
+ 
      
+ 
+ 
       'phi'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = phi <ty> [ <val0>, <label0>], ...
      
+ 
      Overview:
      
+ 
      The 'phi' instruction is used to implement the φ node in
+ the SSA graph representing the function.
      
+ 
      Arguments:
      
+ 
      The type of the incoming values are specified with the first type
+ field. After this, the 'phi' instruction takes a list of pairs
+ as arguments, with one pair for each predecessor basic block of the
+ current block.  Only values of first class
+ type may be used as the value arguments to the PHI node.  Only labels
+ may be used as the label arguments.
      
+ 
      There must be no non-phi instructions between the start of a basic
+ block and the PHI instructions: i.e. PHI instructions must be first in
+ a basic block.
      
+ 
      Semantics:
      
+ 
      At runtime, the 'phi' instruction logically takes on the
+ value specified by the parameter, depending on which basic block we
+ came from in the last terminator instruction.
      
+ 
      Example:
      
+ 
      Loop:       ; Infinite loop that counts from 0 on up...
        %indvar = phi uint [ 0, %LoopHeader ], [ %nextindvar, %Loop ]
        %nextindvar = add uint %indvar, 1
        br label %Loop
      
+ 
      
+ 
+ 
+ 
      
+    'cast .. to' Instruction
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
+ 
      +   <result> = cast <ty> <value> to <ty2>             ; yields ty2
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      
+ The 'cast' instruction is used as the primitive means to convert
+ integers to floating point, change data type sizes, and break type safety (by
+ casting pointers).
+ 
      
+ 
+ 
+ 
      Arguments:
      
+ 
+ 
      
+ The 'cast' instruction takes a value to cast, which must be a first
+ class value, and a type to cast it to, which must also be a first class type.
+ 
      
+ 
+ 
      Semantics:
      
+ 
+ 
      
+ This instruction follows the C rules for explicit casts when determining how the
+ data being cast must change to fit in its new container.
+ 
      
+ 
+ 
      
+ When casting to bool, any value that would be considered true in the context of
+ a C 'if' condition is converted to the boolean 'true' values,
+ all else are 'false'.
+ 
      
+ 
+ 
      
+ When extending an integral value from a type of one signness to another (for
+ example 'sbyte' to 'ulong'), the value is sign-extended if the
+ source value is signed, and zero-extended if the source value is
+ unsigned. bool values are always zero extended into either zero or
+ one.
+ 
      
+ 
+ 
      Example:
      
+ 
+ 
      +   %X = cast int 257 to ubyte              ; yields ubyte:1
+   %Y = cast int 123 to bool               ; yields bool:true
+ 
      
+ 
      
+ 
+ 
+ 
      
+    'select' Instruction
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
+ 
      +   <result> = select bool <cond>, <ty> <val1>, <ty> <val2>             ; yields ty
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      
+ The 'select' instruction is used to choose one value based on a
+ condition, without branching.
+ 
      
+ 
+ 
+ 
      Arguments:
      
+ 
+ 
      
+ The 'select' instruction requires a boolean value indicating the condition, and two values of the same first class type.
+ 
      
+ 
+ 
      Semantics:
      
+ 
+ 
      
+ If the boolean condition evaluates to true, the instruction returns the first
+ value argument, otherwise it returns the second value argument.
+ 
      
+ 
+ 
      Example:
      
+ 
+ 
      +   %X = select bool true, ubyte 17, ubyte 42          ; yields ubyte:17
+ 
      
+ 
      
+ 
+ 
+ 
+ 
+ 
+ 
+ 
       'call'
+ Instruction 
      
+ 
      
+ 
      Syntax:
      
+ 
        <result> = call <ty>* <fnptrval>(<param list>)
      
+ 
      Overview:
      
+ 
      The 'call' instruction represents a simple function call.
      
+ 
      Arguments:
      
+ 
      This instruction requires several arguments:
      
+ 
        
+   
      1. 
+     
        'ty': shall be the signature of the pointer to function
+ value   being invoked.  The argument types must match the types implied
+ by this   signature.
        
+   
        2. 
+   
      2. 
+     
        'fnptrval': An LLVM value containing a pointer to a
+ function   to be invoked. In most cases, this is a direct function
+ invocation, but   indirect calls are just as possible,
+ calling an arbitrary pointer to   function values.
        
+   
        3. 
+   
      3. 
+     
        'function args': argument list whose types match the
+ function   signature argument types.  If the function signature
+ indicates the function   accepts a variable number of arguments, the
+ extra arguments can be   specified.
        
+   
        4. 
+ 
      
+ 
      Semantics:
      
+ 
      The 'call' instruction is used to cause control flow to
+ transfer to a specified function, with its incoming arguments bound to
+ the specified values. Upon a 'ret'
+ instruction in the called function, control flow continues with the
+ instruction after the function call, and the return value of the
+ function is bound to the result argument.  This is a simpler case of
+ the invoke instruction.
      
+ 
      Example:
      
+ 
        %retval = call int %test(int %argc)
        call int(sbyte*, ...) *%printf(sbyte* %msg, int 12, sbyte 42);
      
+ 
      
+ 
+ 
+ 
      
+   'vanext' Instruction
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
+ 
      +   <resultarglist> = vanext <va_list> <arglist>, <argty>
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      The 'vanext' instruction is used to access arguments passed
+ through the "variable argument" area of a function call.  It is used to
+ implement the va_arg macro in C.
      
+ 
+ 
      Arguments:
      
+ 
+ 
      This instruction takes a va_list value and the type of the
+ argument. It returns another va_list. The actual type of
+ va_list may be defined differently for different targets.  Most targets
+ use a va_list type of sbyte* or some other pointer type.
      
+ 
+ 
      Semantics:
      
+ 
+ 
      The 'vanext' instruction advances the specified va_list
+ past an argument of the specified type.  In conjunction with the vaarg instruction, it is used to implement
+ the va_arg macro available in C.  For more information, see
+ the variable argument handling Intrinsic
+ Functions.
      
+ 
+ 
      It is legal for this instruction to be called in a function which
+ does not take a variable number of arguments, for example, the vfprintf
+ function.
      
+ 
+ 
      vanext is an LLVM instruction instead of an intrinsic function because it takes a type as an
+ argument.  The type refers to the current argument in the va_list, it
+ tells the compiler how far on the stack it needs to advance to find the next
+ argument
      
+ 
+ 
      Example:
      
+ 
+ 
      See the variable argument processing
+ section.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   'vaarg' Instruction
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
+ 
      +   <resultval> = vaarg <va_list> <arglist>, <argty>
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      The 'vaarg' instruction is used to access arguments passed through
+ the "variable argument" area of a function call.  It is used to implement the
+ va_arg macro in C.
      
+ 
+ 
      Arguments:
      
+ 
+ 
      This instruction takes a va_list value and the type of the
+ argument. It returns a value of the specified argument type.  Again, the actual
+ type of va_list is target specific.
      
+ 
+ 
      Semantics:
      
+ 
+ 
      The 'vaarg' instruction loads an argument of the specified type from
+ the specified va_list.  In conjunction with the vanext instruction, it is used to implement the
+ va_arg macro available in C.  For more information, see the variable
+ argument handling Intrinsic Functions.
      
+ 
+ 
      It is legal for this instruction to be called in a function which does not
+ take a variable number of arguments, for example, the vfprintf
+ function.
      
+ 
+ 
      vaarg is an LLVM instruction instead of an intrinsic function because it takes an type as an
+ argument.
      
+ 
+ 
      Example:
      
+ 
+ 
      See the variable argument processing section.
      
+ 
+ 
      
+ 
+ 
+ 
       Intrinsic Functions 
      
+ 
+ 
+ 
      
+ 
+ 
      LLVM supports the notion of an "intrinsic function".  These functions have
+ well known names and semantics, and are required to follow certain
+ restrictions. Overall, these instructions represent an extension mechanism for
+ the LLVM language that does not require changing all of the transformations in
+ LLVM to add to the language (or the bytecode reader/writer, the parser,
+ etc...).
      
+ 
+ 
      Intrinsic function names must all start with an "llvm." prefix, this
+ prefix is reserved in LLVM for intrinsic names, thus functions may not be named
+ this.  Intrinsic functions must always be external functions: you cannot define
+ the body of intrinsic functions.  Intrinsic functions may only be used in call
+ or invoke instructions: it is illegal to take the address of an intrinsic
+ function.  Additionally, because intrinsic functions are part of the LLVM
+ language, it is required that they all be documented here if any are added.
      
+ 
+ 
+ 
      
+ Adding an intrinsic to LLVM is straight-forward if it is possible to express the
+ concept in LLVM directly (ie, code generator support is not _required_).  To do
+ this, extend the default implementation of the IntrinsicLowering class to handle
+ the intrinsic.  Code generators use this class to lower intrinsics they do not
+ understand to raw LLVM instructions that they do.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Variable Argument Handling Intrinsics
+ 
      
+ 
+ 
      
+ 
+ 
      Variable argument support is defined in LLVM with the vanext instruction and these three
+ intrinsic functions.  These functions are related to the similarly
+ named macros defined in the <stdarg.h> header file.
      
+ 
+ 
      All of these functions operate on arguments that use a
+ target-specific value type "va_list".  The LLVM assembly
+ language reference manual does not define what this type is, so all
+ transformations should be prepared to handle intrinsics with any type
+ used.
      
+ 
+ 
      This example shows how the vanext
+ instruction and the variable argument handling intrinsic functions are
+ used.
      
+ 
+ 
      + int %test(int %X, ...) {
+   ; Initialize variable argument processing
+   %ap = call sbyte* %llvm.va_start()
+ 
+   ; Read a single integer argument
+   %tmp = vaarg sbyte* %ap, int
+ 
+   ; Advance to the next argument
+   %ap2 = vanext sbyte* %ap, int
+ 
+   ; Demonstrate usage of llvm.va_copy and llvm.va_end
+   %aq = call sbyte* %llvm.va_copy(sbyte* %ap2)
+   call void %llvm.va_end(sbyte* %aq)
+ 
+   ; Stop processing of arguments.
+   call void %llvm.va_end(sbyte* %ap2)
+   ret int %tmp
+ }
+ 
      
+ 
      
+ 
+ 
+ 
      
+   'llvm.va_start' Intrinsic
+ 
      
+ 
+ 
+ 
      
+ 
      Syntax:
      
+ 
        call <va_list> ()* %llvm.va_start()
      
+ 
      Overview:
      
+ 
      The 'llvm.va_start' intrinsic returns a new <arglist>
+ for subsequent use by the variable argument intrinsics.
      
+ 
      Semantics:
      
+ 
      The 'llvm.va_start' intrinsic works just like the va_start
+ macro available in C.  In a target-dependent way, it initializes and
+ returns a va_list element, so that the next vaarg
+ will produce the first variable argument passed to the function.  Unlike
+ the C va_start macro, this intrinsic does not need to know the
+ last argument of the function, the compiler can figure that out.
      
+ 
      Note that this intrinsic function is only legal to be called from
+ within the body of a variable argument function.
      
+ 
      
+ 
+ 
+ 
      
+  'llvm.va_end' Intrinsic
+ 
      
+ 
+ 
      
+ 
      Syntax:
      
+ 
        call void (<va_list>)* %llvm.va_end(<va_list> <arglist>)
      
+ 
      Overview:
      
+ 
      The 'llvm.va_end' intrinsic destroys <arglist>
+ which has been initialized previously with llvm.va_start
+ or llvm.va_copy.
      
+ 
      Arguments:
      
+ 
      The argument is a va_list to destroy.
      
+ 
      Semantics:
      
+ 
      The 'llvm.va_end' intrinsic works just like the va_end
+ macro available in C.  In a target-dependent way, it destroys the va_list.
+ Calls to llvm.va_start and llvm.va_copy must be matched exactly
+ with calls to llvm.va_end.
      
+ 
      
+ 
+ 
+ 
      
+   'llvm.va_copy' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
+ 
      +   call  <va_list> (<va_list>)* %llvm.va_copy(<va_list> <destarglist>)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      The 'llvm.va_copy' intrinsic copies the current argument position
+ from the source argument list to the destination argument list.
      
+ 
+ 
      Arguments:
      
+ 
+ 
      The argument is the va_list to copy.
      
+ 
+ 
      Semantics:
      
+ 
+ 
      The 'llvm.va_copy' intrinsic works just like the va_copy
+ macro available in C.  In a target-dependent way, it copies the source
+ va_list element into the returned list.  This intrinsic is necessary
+ because the llvm.va_start intrinsic may be
+ arbitrarily complex and require memory allocation, for example.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Accurate Garbage Collection Intrinsics
+ 
      
+ 
+ 
      
+ 
+ 
      
+ LLVM support for Accurate Garbage
+ Collection requires the implementation and generation of these intrinsics.
+ These intrinsics allow identification of GC roots on the
+ stack, as well as garbage collector implementations that require read and write barriers.
+ Front-ends for type-safe garbage collected languages should generate these
+ intrinsics to make use of the LLVM garbage collectors.  For more details, see Accurate Garbage Collection with LLVM.
+ 
      
+ 
      
+ 
+ 
+ 
      
+   'llvm.gcroot' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
+ 
      +   call void (<ty>**, <ty2>*)* %llvm.gcroot(<ty>** %ptrloc, <ty2>* %metadata)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      The 'llvm.gcroot' intrinsic declares the existence of a GC root to
+ the code generator, and allows some metadata to be associated with it.
      
+ 
+ 
      Arguments:
      
+ 
+ 
      The first argument specifies the address of a stack object that contains the
+ root pointer.  The second pointer (which must be either a constant or a global
+ value address) contains the meta-data to be associated with the root.
      
+ 
+ 
      Semantics:
      
+ 
+ 
      At runtime, a call to this intrinsics stores a null pointer into the "ptrloc"
+ location.  At compile-time, the code generator generates information to allow
+ the runtime to find the pointer at GC safe points.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   'llvm.gcread' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
+ 
      +   call sbyte* (sbyte**)* %llvm.gcread(sbyte** %Ptr)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      The 'llvm.gcread' intrinsic identifies reads of references from heap
+ locations, allowing garbage collector implementations that require read
+ barriers.
      
+ 
+ 
      Arguments:
      
+ 
+ 
      The argument is the address to read from, which should be an address
+ allocated from the garbage collector.
      
+ 
+ 
      Semantics:
      
+ 
+ 
      The 'llvm.gcread' intrinsic has the same semantics as a load
+ instruction, but may be replaced with substantially more complex code by the
+ garbage collector runtime, as needed.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   'llvm.gcwrite' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
+ 
      +   call void (sbyte*, sbyte**)* %llvm.gcwrite(sbyte* %P1, sbyte** %P2)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      The 'llvm.gcwrite' intrinsic identifies writes of references to heap
+ locations, allowing garbage collector implementations that require write
+ barriers (such as generational or reference counting collectors).
      
+ 
+ 
      Arguments:
      
+ 
+ 
      The first argument is the reference to store, and the second is the heap
+ location to store to.
      
+ 
+ 
      Semantics:
      
+ 
+ 
      The 'llvm.gcwrite' intrinsic has the same semantics as a store
+ instruction, but may be replaced with substantially more complex code by the
+ garbage collector runtime, as needed.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
+ 
      
+   Code Generator Intrinsics
+ 
      
+ 
+ 
      
+ 
      
+ These intrinsics are provided by LLVM to expose special features that may only
+ be implemented with code generator support.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   'llvm.returnaddress' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
      +   call void* ()* %llvm.returnaddress(uint <level>)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      
+ The 'llvm.returnaddress' intrinsic returns a target-specific value
+ indicating the return address of the current function or one of its callers.
+ 
      
+ 
+ 
      Arguments:
      
+ 
+ 
      
+ The argument to this intrinsic indicates which function to return the address
+ for.  Zero indicates the calling function, one indicates its caller, etc.  The
+ argument is required to be a constant integer value.
+ 
      
+ 
+ 
      Semantics:
      
+ 
+ 
      
+ The 'llvm.returnaddress' intrinsic either returns a pointer indicating
+ the return address of the specified call frame, or zero if it cannot be
+ identified.  The value returned by this intrinsic is likely to be incorrect or 0
+ for arguments other than zero, so it should only be used for debugging purposes.
+ 
      
+ 
+ 
      
+ Note that calling this intrinsic does not prevent function inlining or other
+ aggressive transformations, so the value returned may not that of the obvious
+ source-language caller.
+ 
      
+ 
      
+ 
+ 
+ 
+ 
      
+   'llvm.frameaddress' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
      +   call void* ()* %llvm.frameaddress(uint <level>)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      
+ The 'llvm.frameaddress' intrinsic returns the target-specific frame
+ pointer value for the specified stack frame.
+ 
      
+ 
+ 
      Arguments:
      
+ 
+ 
      
+ The argument to this intrinsic indicates which function to return the frame
+ pointer for.  Zero indicates the calling function, one indicates its caller,
+ etc.  The argument is required to be a constant integer value.
+ 
      
+ 
+ 
      Semantics:
      
+ 
+ 
      
+ The 'llvm.frameaddress' intrinsic either returns a pointer indicating
+ the frame address of the specified call frame, or zero if it cannot be
+ identified.  The value returned by this intrinsic is likely to be incorrect or 0
+ for arguments other than zero, so it should only be used for debugging purposes.
+ 
      
+ 
+ 
      
+ Note that calling this intrinsic does not prevent function inlining or other
+ aggressive transformations, so the value returned may not that of the obvious
+ source-language caller.
+ 
      
+ 
      
+ 
+ 
+ 
      
+   Operating System Intrinsics
+ 
      
+ 
+ 
      
+ 
      
+ These intrinsics are provided by LLVM to support the implementation of
+ operating system level code.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   'llvm.readport' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
      +   call <integer type> (<integer type>)* %llvm.readport (<integer type> <address>)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      
+ The 'llvm.readport' intrinsic reads data from the specified hardware
+ I/O port.
+ 
      
+ 
+ 
      Arguments:
      
+ 
+ 
      
+ The argument to this intrinsic indicates the hardware I/O address from which
+ to read the data.  The address is in the hardware I/O address namespace (as
+ opposed to being a memory location for memory mapped I/O).
+ 
      
+ 
+ 
      Semantics:
      
+ 
+ 
      
+ The 'llvm.readport' intrinsic reads data from the hardware I/O port
+ specified by address and returns the value.  The address and return
+ value must be integers, but the size is dependent upon the platform upon which
+ the program is code generated.  For example, on x86, the address must be an
+ unsigned 16 bit value, and the return value must be 8, 16, or 32 bits.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   'llvm.writeport' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
      +   call void (<integer type>, <integer type>)*
+             %llvm.writeport (<integer type> <value>,
+                              <integer type> <address>)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      
+ The 'llvm.writeport' intrinsic writes data to the specified hardware
+ I/O port.
+ 
      
+ 
+ 
      Arguments:
      
+ 
+ 
      
+ The first argument is the value to write to the I/O port.
+ 
      
+ 
+ 
      
+ The second argument indicates the hardware I/O address to which data should be
+ written.  The address is in the hardware I/O address namespace (as opposed to
+ being a memory location for memory mapped I/O).
+ 
      
+ 
+ 
      Semantics:
      
+ 
+ 
      
+ The 'llvm.writeport' intrinsic writes value to the I/O port
+ specified by address.  The address and value must be integers, but the
+ size is dependent upon the platform upon which the program is code generated.
+ For example, on x86, the address must be an unsigned 16 bit value, and the
+ value written must be 8, 16, or 32 bits in length.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   'llvm.readio' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
      +   call <result> (<ty>*)* %llvm.readio (<ty> * <pointer>)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      
+ The 'llvm.readio' intrinsic reads data from a memory mapped I/O
+ address.
+ 
      
+ 
+ 
      Arguments:
      
+ 
+ 
      
+ The argument to this intrinsic is a pointer indicating the memory address from
+ which to read the data.  The data must be a
+ first class type.
+ 
      
+ 
+ 
      Semantics:
      
+ 
+ 
      
+ The 'llvm.readio' intrinsic reads data from a memory mapped I/O
+ location specified by pointer and returns the value.  The argument must
+ be a pointer, and the return value must be a
+ first class type.  However, certain architectures
+ may not support I/O on all first class types.  For example, 32 bit processors
+ may only support I/O on data types that are 32 bits or less.
+ 
      
+ 
+ 
      
+ This intrinsic enforces an in-order memory model for llvm.readio and
+ llvm.writeio calls on machines that use dynamic scheduling.  Dynamically
+ scheduled processors may execute loads and stores out of order, re-ordering at
+ run time accesses to memory mapped I/O registers.  Using these intrinsics
+ ensures that accesses to memory mapped I/O registers occur in program order.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   'llvm.writeio' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
      +   call void (<ty1>, <ty2>*)* %llvm.writeio (<ty1> <value>, <ty2> * <pointer>)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      
+ The 'llvm.writeio' intrinsic writes data to the specified memory
+ mapped I/O address.
+ 
      
+ 
+ 
      Arguments:
      
+ 
+ 
      
+ The first argument is the value to write to the memory mapped I/O location.
+ The second argument is a pointer indicating the memory address to which the
+ data should be written.
+ 
      
+ 
+ 
      Semantics:
      
+ 
+ 
      
+ The 'llvm.writeio' intrinsic writes value to the memory mapped
+ I/O address specified by pointer.  The value must be a
+ first class type.  However, certain architectures
+ may not support I/O on all first class types.  For example, 32 bit processors
+ may only support I/O on data types that are 32 bits or less.
+ 
      
+ 
+ 
      
+ This intrinsic enforces an in-order memory model for llvm.readio and
+ llvm.writeio calls on machines that use dynamic scheduling.  Dynamically
+ scheduled processors may execute loads and stores out of order, re-ordering at
+ run time accesses to memory mapped I/O registers.  Using these intrinsics
+ ensures that accesses to memory mapped I/O registers occur in program order.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Standard C Library Intrinsics
+ 
      
+ 
+ 
      
+ 
      
+ LLVM provides intrinsics for a few important standard C library functions.
+ These intrinsics allow source-language front-ends to pass information about the
+ alignment of the pointer arguments to the code generator, providing opportunity
+ for more efficient code generation.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   'llvm.memcpy' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
      +   call void (sbyte*, sbyte*, uint, uint)* %llvm.memcpy(sbyte* <dest>, sbyte* <src>,
+                                                        uint <len>, uint <align>)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      
+ The 'llvm.memcpy' intrinsic copies a block of memory from the source
+ location to the destination location.
+ 
      
+ 
+ 
      
+ Note that, unlike the standard libc function, the llvm.memcpy intrinsic
+ does not return a value, and takes an extra alignment argument.
+ 
      
+ 
+ 
      Arguments:
      
+ 
+ 
      
+ The first argument is a pointer to the destination, the second is a pointer to
+ the source.  The third argument is an (arbitrarily sized) integer argument
+ specifying the number of bytes to copy, and the fourth argument is the alignment
+ of the source and destination locations.
+ 
      
+ 
+ 
      
+ If the call to this intrinisic has an alignment value that is not 0 or 1, then
+ the caller guarantees that the size of the copy is a multiple of the alignment
+ and that both the source and destination pointers are aligned to that boundary.
+ 
      
+ 
+ 
      Semantics:
      
+ 
+ 
      
+ The 'llvm.memcpy' intrinsic copies a block of memory from the source
+ location to the destination location, which are not allowed to overlap.  It
+ copies "len" bytes of memory over.  If the argument is known to be aligned to
+ some boundary, this can be specified as the fourth argument, otherwise it should
+ be set to 0 or 1.
+ 
      
+ 
      
+ 
+ 
+ 
+ 
      
+   'llvm.memmove' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
      +   call void (sbyte*, sbyte*, uint, uint)* %llvm.memmove(sbyte* <dest>, sbyte* <src>,
+                                                        uint <len>, uint <align>)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      
+ The 'llvm.memmove' intrinsic moves a block of memory from the source
+ location to the destination location. It is similar to the 'llvm.memcpy' 
+ intrinsic but allows the two memory locations to overlap.
+ 
      
+ 
+ 
      
+ Note that, unlike the standard libc function, the llvm.memmove intrinsic
+ does not return a value, and takes an extra alignment argument.
+ 
      
+ 
+ 
      Arguments:
      
+ 
+ 
      
+ The first argument is a pointer to the destination, the second is a pointer to
+ the source.  The third argument is an (arbitrarily sized) integer argument
+ specifying the number of bytes to copy, and the fourth argument is the alignment
+ of the source and destination locations.
+ 
      
+ 
+ 
      
+ If the call to this intrinisic has an alignment value that is not 0 or 1, then
+ the caller guarantees that the size of the copy is a multiple of the alignment
+ and that both the source and destination pointers are aligned to that boundary.
+ 
      
+ 
+ 
      Semantics:
      
+ 
+ 
      
+ The 'llvm.memmove' intrinsic copies a block of memory from the source
+ location to the destination location, which may overlap.  It
+ copies "len" bytes of memory over.  If the argument is known to be aligned to
+ some boundary, this can be specified as the fourth argument, otherwise it should
+ be set to 0 or 1.
+ 
      
+ 
      
+ 
+ 
+ 
+ 
      
+   'llvm.memset' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
      +   call void (sbyte*, ubyte, uint, uint)* %llvm.memset(sbyte* <dest>, ubyte <val>,
+                                                       uint <len>, uint <align>)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      
+ The 'llvm.memset' intrinsic fills a block of memory with a particular
+ byte value.
+ 
      
+ 
+ 
      
+ Note that, unlike the standard libc function, the llvm.memset intrinsic
+ does not return a value, and takes an extra alignment argument.
+ 
      
+ 
+ 
      Arguments:
      
+ 
+ 
      
+ The first argument is a pointer to the destination to fill, the second is the
+ byte value to fill it with, the third argument is an (arbitrarily sized) integer
+ argument specifying the number of bytes to fill, and the fourth argument is the
+ known alignment of destination location.
+ 
      
+ 
+ 
      
+ If the call to this intrinisic has an alignment value that is not 0 or 1, then
+ the caller guarantees that the size of the copy is a multiple of the alignment
+ and that the destination pointer is aligned to that boundary.
+ 
      
+ 
+ 
      Semantics:
      
+ 
+ 
      
+ The 'llvm.memset' intrinsic fills "len" bytes of memory starting at the
+ destination location.  If the argument is known to be aligned to some boundary,
+ this can be specified as the fourth argument, otherwise it should be set to 0 or
+ 1.
+ 
      
+ 
      
+ 
+ 
+ 
+ 
      
+   'llvm.isunordered' Intrinsic
+ 
      
+ 
+ 
      
+ 
+ 
      Syntax:
      
+ 
      +   call bool (<float or double>, <float or double>)* %llvm.isunordered(<float or double> Val1,
+                                                                       <float or double> Val2)
+ 
      
+ 
+ 
      Overview:
      
+ 
+ 
      
+ The 'llvm.isunordered' intrinsic returns true if either or both of the
+ specified floating point values is a NAN.
+ 
      
+ 
+ 
      Arguments:
      
+ 
+ 
      
+ The arguments are floating point numbers of the same type.
+ 
      
+ 
+ 
      Semantics:
      
+ 
+ 
      
+ If either or both of the arguments is a SNAN or QNAN, it returns true, otherwise
+ false.
+ 
      
+ 
      
+ 
+ 
+ 
+ 
+ 
+ 
      
+   Debugger Intrinsics
+ 
      
+ 
+ 
      
+ 
      
+ The LLVM debugger intrinsics (which all start with llvm.dbg. prefix),
+ are described in the LLVM Source Level
+ Debugging document.
+ 
      
+ 
      
+ 
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Chris Lattner
      
+   The LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 


Index: llvm-www/releases/1.4/docs/Lexicon.html
diff -c /dev/null llvm-www/releases/1.4/docs/Lexicon.html:1.1
*** /dev/null	Thu Dec  9 16:19:06 2004
--- llvm-www/releases/1.4/docs/Lexicon.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,170 ----
+ 
+ 
+ 
+   
+   The LLVM Lexicon
+   
+   
+   
+ 
+ 
+ 
      The LLVM Lexicon
      
+ 
      NOTE: This document is a work in progress!
      
+ 
+ 
      Table Of Contents
      
+ 
+ 
      
+   
+     
+     
+       
+       
+       
+     
+     
+     
+       
+       
+       
+     
+     
+     
+       
+       
+       
+     
+     
+     
+       
+       
+       
+       
+     
+     
+     
+       
+       
+       
+       
+     
+     
+     
+       
+       
+       
+       
+     
+     
+     
+       
+       
+       
+     
+     
+     
+       
+       
+       
+     
+   
      - A -
      ADCE
      - B -
      BURS
      - C -
      CSE
      - D -
      DSADSE
      - I -
      IPAIPO
      - L -
      LICMLoad-VN
      - P -
      PRE
      - S -
      SCCPSSA
      
+ 
      
+ 
+ 
+ 
      Definitions
      
+ 
+ 
+ 
      - A -
      
+ 
      
+   
      
+     
      ADCE
      
+     
      Aggressive Dead Code Elimination
      
+   
      
+ 
      
+ 
+ 
      - B -
      
+ 
      
+   
      
+     
      BURS
      
+     
      Bottom Up Rewriting System - A method of instruction selection for
+         code generation.  An example is the BURG tool.
      
+   
      
+ 
      
+ 
+ 
      - C -
      
+ 
      
+   
      
+     
      CSE
      
+     
      Common Subexpression Elimination. An optimization that removes common
+     subexpression compuation. For example (a+b)*(a+b) has two
+     subexpressions that are the same: (a+b). This optimization would
+     perform the addition only once and then perform the multiply (but only if
+     its compulationally correct/safe).
+   
      
+ 
      
+ 
+ 
      - D -
      
+ 
      
+   
      
+     
      DSA
      
+     
      Data Structure Analysis
      
+     
      DSE
      
+     
      Dead Store Elimination
      
+   
      
+ 
      
+ 
+ 
      - I -
      
+ 
      
+   
      
+     
      IPA
      
+     
      Inter-Procedural Analysis. Refers to any variety of code analysis that
+     occurs between procedures, functions or compilation units (modules).
      
+     
      IPO
      
+     
      Inter-Procedural Optimization. Refers to any variety of code
+     optimization that occurs between procedures, functions or compilation units
+     (modules).
      
+   
      
+ 
      
+ 
+ 
      - L -
      
+ 
      
+   
      
+     
      LICM
      
+     
      Loop Invariant Code Motion
      
+     
      Load-VN
      
+     
      Load Value Numbering
      
+   
      
+ 
      
+ 
+ 
      - P -
      
+ 
      
+   
      
+     
      PRE
      
+     
      Partial Redundancy Elimination
      
+   
      
+ 
      
+ 
+ 
      - S -
      
+ 
      
+   
      
+     
      SCCP
      
+     
      Sparse Conditional Constant Propagation
+     
      SSA
      
+     
      Static Single Assignment
      
+   
      
+ 
      
+ 
+ 
      
+ 
       Valid CSS!Valid HTML 4.01!The LLVM Team
      
+ The LLVM Compiler Infrastructure
      
+ Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/Makefile
diff -c /dev/null llvm-www/releases/1.4/docs/Makefile:1.1
*** /dev/null	Thu Dec  9 16:19:07 2004
--- llvm-www/releases/1.4/docs/Makefile	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,62 ----
+ ##===- docs/Makefile ---------------------------------------*- Makefile -*-===##
+ # 
+ #                     The LLVM Compiler Infrastructure
+ #
+ # This file was developed by the LLVM research group and is distributed under
+ # the University of Illinois Open Source License. See LICENSE.TXT for details.
+ # 
+ ##===----------------------------------------------------------------------===##
+ 
+ LEVEL      := ..
+ DIRS       := CommandGuide
+ 
+ include $(LEVEL)/Makefile.common
+ 
+ HTML       := $(wildcard $(BUILD_SRC_DIR)/*.html) \
+               $(wildcard $(BUILD_SRC_DIR)/*.css)
+ IMAGES     := $(wildcard $(BUILD_SRC_DIR)/img/*.*)
+ DOXYFILES  := $(wildcard $(BUILD_SRC_DIR)/doxygen.*)
+ EXTRA_DIST := $(HTML) $(DOXYFILES) llvm.css CommandGuide img
+ 
+ .PHONY: install-html install-doxygen doxygen
+ 
+ ifeq ($(ENABLE_DOXYGEN),1)
+ install-local:: install-html install-doxygen
+ else
+ install-local:: install-html
+ endif
+ 
+ install-html: $(BUILD_OBJ_DIR)/html.tar.gz
+ 	$(Echo) Installing HTML documentation
+ 	$(Verb) $(INSTALL) -d $(LLVM_DOCSDIR)/html
+ 	$(Verb) $(INSTALL) -d $(LLVM_DOCSDIR)/html/img
+ 	$(Verb) $(INSTALL) -C $(HTML) $(LLVM_DOCSDIR)/html
+ 	$(Verb) $(INSTALL) -C $(IMAGES) $(LLVM_DOCSDIR)/html/img
+ 	$(Verb) $(INSTALL) -C $(BUILD_OBJ_DIR)/html.tar.gz $(LLVM_DOCSDIR)
+ 
+ $(BUILD_OBJ_DIR)/html.tar.gz: $(HTML)
+ 	$(Echo) Packaging HTML documentation
+ 	$(Verb) $(RM) -rf $@ $(BUILD_OBJ_DIR)/html.tar
+ 	$(Verb) cd $(BUILD_SRC_DIR) && \
+ 	  $(TAR) cf $(BUILD_OBJ_DIR)/html.tar *.html
+ 	$(Verb) $(GZIP) $(BUILD_OBJ_DIR)/html.tar
+ 
+ install-doxygen: doxygen
+ 	$(Echo) Installing doxygen documentation
+ 	$(Echo) Installing doxygen documentation
+ 	$(Verb) $(INSTALL) -d $(LLVM_DOCSDIR)/html/doxygen
+ 	$(Verb) $(INSTALL) $(BUILD_OBJ_DIR)/doxygen.tar.gz $(LLVM_DOCSDIR)
+ 	$(Verb) cd $(BUILD_OBJ_DIR)/doxygen && \
+ 	  $(FIND) . -type f -exec \
+ 	    $(INSTALL) -C {} $(LLVM_DOCSDIR)/html/doxygen \;
+ 
+ doxygen: $(BUILD_OBJ_DIR)/doxygen.tar.gz
+ 
+ $(BUILD_OBJ_DIR)/doxygen.tar.gz: $(DOXYFILES) $(BUILD_OBJ_DIR)/doxygen.cfg
+ 	$(Echo) Building doxygen documentation
+ 	$(Verb) $(DOXYGEN) $(BUILD_OBJ_DIR)/doxygen.cfg
+ 	$(Echo) Packaging doxygen documentation
+ 	$(Verb) $(RM) -rf $@ $(BUILD_OBJ_DIR)/doxygen.tar
+ 	$(Verb) $(TAR) cf $(BUILD_OBJ_DIR)/doxygen.tar doxygen
+ 	$(Verb) $(GZIP) $(BUILD_OBJ_DIR)/doxygen.tar
+ 


Index: llvm-www/releases/1.4/docs/MakefileGuide.html
diff -c /dev/null llvm-www/releases/1.4/docs/MakefileGuide.html:1.1
*** /dev/null	Thu Dec  9 16:19:07 2004
--- llvm-www/releases/1.4/docs/MakefileGuide.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,962 ----
+ 
+ 
+ 
+   
+   LLVM Makefile Guide
+   
+ 
+ 
+ 
+ 
      LLVM Makefile Guide
      
+ 
+ 
        
+   
      1. Introduction
        2. 
+   
      2. General Concepts
+     
          
+       
        1. Projects
          2. 
+       
        2. Variable Values
          3. 
+       
        3. Including Makefiles
+         
            
+           
          1. Makefile
            2. 
+           
          2. Makefile.common
            3. 
+           
          3. Makefile.config
            4. 
+           
          4. Makefile.rules
            5. 
+         
          
+       
          4. 
+       
        4. Comments
          5. 
+     
        
+   
        3. 
+   
      3. Tutorial
+     
          
+       
        1. Libraries
+         
            
+ 	  
          1. Bytecode Modules
            2. 
+ 	
          
+       
          2. 
+       
        2. Tools
+         
            
+ 	  
          1. JIT Tools
            2. 
+ 	
          
+       
          3. 
+     
        
+   
        4. 
+   
      4. Targets Supported
+     
          
+       
        1. all
          2. 
+       
        2. all-local
          3. 
+       
        3. check
          4. 
+       
        4. check-local
          5. 
+       
        5. clean
          6. 
+       
        6. clean-local
          7. 
+       
        7. dist
          8. 
+       
        8. dist-check
          9. 
+       
        9. dist-clean
          10. 
+       
        10. install
          11. 
+       
        11. preconditions
          12. 
+       
        12. printvars
          13. 
+       
        13. tags
          14. 
+       
        14. uninstall
          15. 
+     
        
+   
        5. 
+   
      5. Using Variables
+     
          
+       
        1. Control Variables
          2. 
+       
        2. Override Variables
          3. 
+       
        3. Readable Variables
          4. 
+       
        4. Internal Variables
          5. 
+     
        
+   
        6. 
+ 
      
+ 
+ 
          
+   
      Written by Reid Spencer
      
+ 
      
+ 
+ 
+ 
      Introduction 
      
+ 
+ 
+ 
      
+   
      This document provides usage information about the LLVM makefile 
+   system. While loosely patterned after the BSD makefile system, LLVM has taken 
+   a departure from BSD in order to implement additional features needed by LLVM.
+   Although makefile systems such as automake were attempted at one point, it
+   has become clear that the features needed by LLVM and the Makefile norm are 
+   too great to use a more limited tool. Consequently, LLVM requires simply GNU 
+   Make 3.79, a widely portable makefile processor. LLVM unabashedly makes heavy 
+   use of the features of GNU Make so the dependency on GNU Make is firm. If 
+   you're not familiar with make, it is recommended that you read the 
+   GNU Makefile Manual
+   .
      
+   
      While this document is rightly part of the 
+   LLVM Programmer's Manual, it is treated
+   separately here because of the volume of content and because it is often an
+   early source of bewilderment for new developers.
      
+ 
      
+ 
+ 
+ 
      General Concepts
      
+ 
+ 
+ 
      
+   
      The LLVM Makefile System is the component of LLVM that is responsible for
+   building the software, testing it,  generating distributions, checking those
+   distributions, installing and uninstalling, etc. It consists of a several
+   files throughout the source tree. These files and other general concepts are
+   described in this section.
      
+ 
      
+ 
+ 
+ 
      Projects
      
+ 
      
+   
      The LLVM Makefile System is quite generous. It not only builds its own
+   software, but it can build yours too. Built into the system is knowledge of
+   the llvm/projects directory. Any directory under projects
+   that has both a configure script and a Makefile is assumed
+   to be a project that uses the LLVM Makefile system. This allows your project
+   to get up and running quickly by utilizing the built-in features that are used
+   to compile LLVM. LLVM compiles itself using the same features of the makefile
+   system as used for projects.
      
+ 
      
+ 
+ 
+ 
      Variable Values
      
+ 
      
+   
      To use the makefile system, you simply create a file named 
+   Makefile in your directory and declare values for certain variables. 
+   The variables and values that you select determine what the makefile system
+   will do. These variables enable rules and processing in the makefile system
+   that automatically Do The Right Thing™. 
+ 
      
+ 
+ 
+ 
      Including Makefiles
      
+ 
      
+   
      Setting variables alone is not enough. You must include into your Makefile
+   additional files that provide the rules of the LLVM Makefile system. The 
+   various files involved are described in the sections that follow.
      
+ 
      
+ 
+ 
+ 
      Makefile
      
+ 
      
+   
      Each directory to participate in the build needs to have a file named
+   Makefile. This is the file first read by make. It has three
+   sections:
      
+   
        
+     
      1. Settable Variables - Required that must be set
+     first.
        2. 
+     
      2. include $(LEVEL)/Makefile.common
+     - include the LLVM Makefile system.
+     
      3. Override Variables - Override variables set by
+     the LLVM Makefile system.
+   
      
+ 
      
+ 
+ 
+ 
      Makefile.common
+ 
      
+ 
      
+   
      Every project must have a Makefile.common file at its top source 
+   directory. This file serves three purposes:
      
+   
        
+     
      1. It includes the project's configuration makefile to obtain values
+     determined by the configure script. This is done by including the
+     $(LEVEL)/Makefile.config file.
        2. 
+     
      2. It specifies any other (static) values that are needed throughout the
+     project. Only values that are used in all or a large proportion of the
+     project's directories should be placed here.
        3. 
+     
      3. It includes the standard rules for the LLVM Makefile system,
+     $(LLVM_SRC_ROOT)/Makefile.rules. 
+     This file is the "guts" of the LLVM Makefile system.
        4. 
+   
      
+ 
      
+ 
+ 
+ 
      Makefile.config
+ 
      
+ 
      
+   
      Every project must have a Makefile.config at the top of its
+   build directory. This file is generated by the
+   configure script from the pattern provided by the
+   Makefile.config.in file located at the top of the project's
+   source directory. The contents of this file depend largely on what
+   configuration items the project uses, however most projects can get what they
+   need by just relying on LLVM's configuration found in
+   $(LLVM_OBJ_ROOT)/Makefile.config.
+ 
      
+ 
+ 
+ 
      Makefile.rules
      
+ 
      
+   
      This file, located at $(LLVM_SRC_ROOT)/Makefile.rules is the heart
+   of the LLVM Makefile System. It provides all the logic, dependencies, and
+   rules for building the targets supported by the system. What it does largely
+   depends on the values of make variables that
+   have been set before Makefile.rules is included.
+ 
      
+ 
+ 
+ 
      Comments
      
+ 
      
+   
      User Makefiles need not have comments in them unless the construction is
+   unusual or it does not strictly follow the rules and patterns of the LLVM
+   makefile system. Makefile comments are invoked with the pound (#) character.
+   The # character and any text following it, to the end of the line, are ignored
+   by make.
      
+ 
      
+ 
+ 
+ 
      Tutorial
      
+ 
+ 
      
+   
      This section provides some examples of the different kinds of modules you
+   can build with the LLVM makefile system. In general, each directory you 
+   provide will build a single object although that object may be composed of
+   additionally compiled components.
      
+ 
      
+ 
+ 
+ 
      Libraries
      
+ 
      
+   
      Only a few variable definitions are needed to build a regular library.
+   Normally, the makefile system will build all the software into a single
+   libname.o (pre-linked) object. This means the library is not
+   searchable and that the distinction between compilation units has been
+   dissolved. Optionally, you can ask for a shared library (.so), archive library
+   (.a) or to not have the default (relinked) library built. For example:
      
+   
      
+       LIBRARYNAME = mylib
+       SHARED_LIBRARY = 1
+       ARCHIVE_LIBRARY = 1
+       DONT_BUILT_RELINKED = 1
+   
      
+   
      says to build a library named "mylib" with both a shared library 
+   (mylib.so) and an archive library (mylib.a) version but
+   not to build the relinked object (mylib.o). The contents of all the
+   libraries produced will be the same, they are just constructed differently.
+   Note that you normally do not need to specify the sources involved. The LLVM
+   Makefile system will infer the source files from the contents of the source
+   directory.
      
+ 
      
+ 
+ 
+ 
      Bytecode Modules
      
+ 
      
+   
      In some situations, it is desireable to build a single bytecode module from
+   a variety of sources, instead of an archive, shared library, or bytecode 
+   library. Bytecode modules can be specified in addition to any of the other
+   types of libraries by defining the MODULE_NAME
+   variable. For example:
      
+   
      
+       LIBRARYNAME = mylib
+       BYTECODE_LIBRARY = 1
+       MODULE_NAME = mymod
+   
      
+   
      will build a module named mymod.bc from the sources in the
+   directory. This module will be an aggregation of all the bytecode modules 
+   derived from the sources. The example will also build a bytecode archive 
+   containing a bytecode module for each compiled source file. The difference is
+   subtle, but important depending on how the module or library is to be linked.
+   
      
+ 
      
+ 
+ 
+ 
      Tools
      
+ 
      
+   
      For building executable programs (tools), you must provide the name of the
+   tool and the names of the libraries you wish to link with the tool. For
+   example:
      
+   
      
+       TOOLNAME = mytool
+       USEDLIBS = mylib
+       LLVMLIBS = LLVMSupport.a LLVMSystem.a
+   
      
+   
      says that we are to build a tool name mytool and that it requires
+   three libraries: mylib, LLVMSupport.a and
+   LLVMSystem.a.
      
+   
      Note that two different variables are use to indicate which libraries are
+   linked: USEDLIBS and LLVMLIBS. This distinction is necessary
+   to support projects. LLVMLIBS refers to the LLVM libraries found in 
+   the LLVM object directory. USEDLIBS refers to the libraries built by 
+   your project. In the case of building LLVM tools, USEDLIBS and 
+   LLVMLIBS can be used interchangeably since the "project" is LLVM 
+   itself and USEDLIBS refers to the same place as LLVMLIBS.
+   
      
+   
      Also note that there are two different ways of specifying a library: with a
+   .a suffix and without. Without the suffix, the entry refers to the
+   re-linked (.o) file which will include all symbols of the library.
+   This is useful, for example, to include all passes from a library of passes.
+   If the .a suffix is used then the library is linked as a searchable
+   library (with the -l option). In this case, only the symbols that are
+   unresolved at that point will be resolved from the library, if they
+   exist. Other (unreferenced) symbols will not be included when the .a
+   syntax is used. Note that in order to use the .a suffix, the library
+   in question must have been built with the ARCHIVE_LIBRARY option set.
+   
      
+ 
      
+ 
+ 
+ 
      JIT Tools
      
+ 
      
+   
      Many tools will want to use the JIT features of LLVM. However, getting the
+   right set of libraries to link with is tedious, platform specific, and error 
+   prone. Additionally, the JIT has special linker switch options that it needs.
+   Consequently, to make it easier to build tools that use the JIT, you can 
+   use a special value for the LLVMLIBS variable:
      
+   
      
+       TOOLNAME = my_jit_tool
+       USEDLIBS = mylib
+       LLVMLIBS = JIT
+   
      
+   
      Using a value of JIT for LLVMLIBS tells the makefile
+   system to construct a special value for LLVMLIBS that gives the program all
+   the LLVM libraries needed to run the JIT. Any additional libraries needed can
+   still be specified with USEDLIBS. To get a full understanding of how
+   this changes the linker command, it is recommended that you:
      
+   
      
+       cd examples/Fibonacci
+       make VERBOSE=1
+   
      
+   
      By default, using LLVMLIBS=JIT will link in enough to support JIT
+   code generation for the architecture on which the tool is linked. If you need
+   additional target architectures linked in, you may specify them on the command
+   line or in your Makefile. For example:
      
+   
      
+       ENABLE_X86_JIT=1
+       ENABLE_SPARCV9_JIT=1
+       ENALBE_PPC_JIT=1
+   
      
+   
      will cause the tool to be able to generate code for all three platforms.
+   
      
+ 
      
+ 
+ 
+ 
      Targets Supported
      
+ 
+ 
+ 
      
+   
      This section describes each of the targets that can be built using the LLVM
+   Makefile system. Any target can be invoked from any directory but not all are
+   applicable to a given directory (e.g. "check", "dist" and "install" will
+   always operate as if invoked from the top level directory).
      
+ 
+   
+     
+       
+     
+     
+       
+     
+       
+     
+       
+     
+       
+     
+       
+     
+       
+     
+       
+     
+       
+     
+       
+     
+       
+     
+       
+     
+       
+     
+       
+     
+       
+   
      Target NameImplied TargetsTarget Description
      allCompile the software recursively. Default target.
+     
      all-localCompile the software in the local directory only.
+     
      checkChange to the test directory in a project and run the
+       test suite there.
+     
      check-localRun a local test suite. Generally this is only defined in the 
+         Makefile of the project's test directory.
+     
      cleanRemove built objects recursively.
+     
      clean-localRemove built objects from the local directory only.
+     
      distallPrepare a source distribution tarball.
+     
      dist-checkall checkPrepare a source distribution tarball and check that it builds.
+     
      dist-cleancleanClean source distribution tarball temporary files.
+     
      installallCopy built objects to installation directory.
+     
      preconditionsallCheck to make sure configuration and makefiles are up to date.
+     
      printvarsallPrints variables defined by the makefile system (for debugging).
+     
      tagsMake C and C++ tags files for emacs and vi.
+     
      uninstallRemove built objects from installation directory.
+     
      
+ 
      
+ 
+ 
+ 
      all (default)
      
+ 
      
+   
      When you invoke make with no arguments, you are implicitly
+   instructing it to seek the "all" target (goal). This target is used for
+   building the software recursively and will do different things in different 
+   directories.  For example, in a lib directory, the "all" target will 
+   compile source files and generate libraries. But, in a tools 
+   directory, it will link libraries and generate executables.
      
+ 
      
+ 
+ 
+ 
      all-local
      
+ 
      
+   
      This target is the same as all but it operates only on
+   the current directory instead of recursively.
      
+ 
      
+ 
+ 
+ 
      check
      
+ 
      
+   
      This target can be invoked from anywhere within a project's directories
+   but always invokes the check-local target 
+   in the project's test directory, if it exists and has a 
+   Makefile. A warning is produced otherwise.  If 
+   TESTSUITE is defined on the make
+   command line, it will be passed down to the invocation of 
+   make check-local in the test directory. The intended usage 
+   for this is to assist in running specific suites of tests. If
+   TESTSUITE is not set, the implementation of check-local 
+   should run all normal tests.  It is up to the project to define what 
+   different values for TESTSUTE will do. See the 
+   TestingGuide for further details.
      
+ 
      
+ 
+ 
+ 
      check-local
      
+ 
      
+   
      This target should be implemented by the Makefile in the project's
+   test directory. It is invoked by the check target elsewhere.
+   Each project is free to define the actions of check-local as 
+   appropriate for that project. The LLVM project itself uses dejagnu to run a 
+   suite of feature and regresson tests. Other projects may choose to use 
+   dejagnu or any other testing mechanism.
      
+ 
      
+ 
+ 
+ 
      clean
      
+ 
      
+   
      This target cleans the build directory, recursively removing all things
+   that the Makefile builds. The cleaning rules have been made guarded so they 
+   shouldn't go awry (via rm -f $(UNSET_VARIABLE)/* which will attempt
+   to erase the entire directory structure.
      
+ 
      
+ 
+ 
+ 
      clean-local
      
+ 
      
+   
      This target does the same thing as clean but only for the current
+   (local) directory.
      
+ 
      
+ 
+ 
+ 
      dist
      
+ 
      
+   
      This target builds a distribution tarball. It first builds the entire
+   project using the all target and then tars up the necessary files and
+   compresses it. The generated tarball is sufficient for a casual source 
+   distribution, but probably not for a release (see dist-check).
      
+ 
      
+ 
+ 
+ 
      dist-check
      
+ 
      
+   
      This target does the same thing as the dist target but also checks
+   the distribution tarball. The check is made by unpacking the tarball to a new
+   directory, configuring it, building it, installing it, and then verifying that
+   the installation results are correct (by comparing to the original build).
+   This target can take a long time to run but should be done before a release
+   goes out to make sure that the distributed tarball can actually be built into
+   a working release.
      
+ 
      
+ 
+ 
+ 
      dist-clean
      
+ 
      
+   
      This is a special form of the clean clean target. It performs a
+   normal clean but also removes things pertaining to building the
+   distribution.
      
+ 
      
+ 
+ 
+ 
      install
      
+ 
      
+   
      This target finalizes shared objects and executables and copies all
+   libraries, headers, executables and documentation to the directory given 
+   with the --prefix option to configure.  When completed, 
+   the prefix directory will have everything needed to use LLVM. 
      
+   
      The LLVM makefiles can generate complete internal documentation 
+   for all the classes by using doxygen. By default, this feature is 
+   not enabled because it takes a long time and generates a massive 
+   amount of data (>100MB). If you want this feature, you must configure LLVM
+   with the --enable-doxygen switch and ensure that a modern version of doxygen
+   (1.3.7 or later) is available in your PATH. You can download 
+   doxygen from 
+   
+   here.
+ 
      
+ 
+ 
+ 
      preconditions
      
+ 
      
+   
      This utility target checks to see if the Makefile in the object
+   directory is older than the Makefile in the source directory and
+   copies it if so. It also reruns the configure script if that needs to
+   be done and rebuilds the Makefile.config file similarly. Users may
+   overload this target to ensure that sanity checks are run before any
+   building of targets as all the targets depend on preconditions.
      
+ 
      
+ 
+ 
+ 
      printvars
      
+ 
      
+   
      This utility target just causes the LLVM makefiles to print out some of 
+   the makefile variables so that you can double check how things are set. 
      
+ 
      
+ 
+ 
+ 
      tags
      
+ 
      
+   
      This target will generate a TAGS file in the top-level source
+   directory. It is meant for use with emacs, XEmacs, or ViM. The TAGS file
+   provides an index of symbol definitions so that the editor can jump you to the
+   definition quickly. 
      
+ 
      
+ 
+ 
+ 
      uninstall
      
+ 
      
+   
      This target is the opposite of the install target. It removes the
+   header, library and executable files from the installation directories. Note
+   that the directories themselves are not removed because it is not guaranteed
+   that LLVM is the only thing installing there (e.g. --prefix=/usr).
      
+ 
      
+ 
+ 
+ 
      Variables
      
+ 
+ 
      
+   
      Variables are used to tell the LLVM Makefile System what to do and to
+   obtain information from it. Variables are also used internally by the LLVM
+   Makefile System. Variable names that contain only the upper case alphabetic
+   letters and underscore are intended for use by the end user. All other
+   variables are internal to the LLVM Makefile System and should not be relied
+   upon nor modified. The sections below describe how to use the LLVM Makefile 
+   variables.
      
+ 
      
+ 
+ 
+ 
      Control Variables
      
+ 
      
+   
      Variables listed in the table below should be set before the 
+   inclusion of $(LEVEL)/Makefile.common.
+   These variables provide input to the LLVM make system that tell it what to do 
+   for the current directory.
      
+   
      
+     
      BUILD_ARCHIVE
      
+     
      If set to any value, causes an archive (.a) library to be built.
      
+     
      BUILT_SOURCES
      
+     
      Specifies a set of source files that are generated from other source
+     files. These sources will be built before any other target processing to 
+     ensure they are present.
      
+     
      BYTECODE_LIBRARY
      
+     
      If set to any value, causes a bytecode library (.bc) to be built.
      
+     
      CONFIG_FILES
      
+     
      Specifies a set of configuration files to be installed.
      
+     
      DIRS
      
+     
      Specifies a set of directories, usually children of the current
+     directory, that should also be made using the same goal. These directories 
+     will be built serially.
      
+     
      DISABLE_AUTO_DEPENDENCIES
      
+     
      If set to any value, causes the makefiles to not automatically
+     generate dependencies when running the compiler. Use of this feature is
+     discouraged and it may be removed at a later date.
      
+     
      DONT_BUILD_RELINKED
      
+     
      If set to any value, causes a relinked library (.o) not to be built. By
+     default, libraries are built as re-linked since most LLVM libraries are
+     needed in their entirety and re-linked libraries will be linked more quickly
+     than equivalent archive libraries.
      
+     
      ENABLE_OPTIMIZED
      
+     
      If set to any value, causes the build to generate optimized objects,
+     libraries and executables. This alters the flags specified to the compilers
+     and linkers. Generally debugging won't be a fun experience with an optimized
+     build.
      
+     
      ENABLE_PROFILING
      
+     
      If set to any value, causes the build to generate both optimized and 
+     profiled objects, libraries and executables. This alters the flags specified
+     to the compilers and linkers to ensure that profile data can be collected
+     from the tools built. Use the gprof tool to analyze the output from
+     the profiled tools (gmon.out).
      
+     
      EXPERIMENTAL_DIRS
      
+     
      Specify a set of directories that should be built, but if they fail, it
+     should not cause the build to fail. Note that this should only be used 
+     temporarily while code is being written.
       
+     
      EXPORTED_SYMBOL_FILE
      
+     
      Specifies the name of a single file that contains a list of the 
+     symbols to be exported by the linker. One symbol per line.
      
+     
      EXPORTED_SYMBOL_LIST
      
+     
      Specifies a set of symbols to be exported by the linker.
      
+     
      EXTRA_DIST
      
+     
      Specifies additional files that should be distributed with LLVM. All
+     source files, all built sources, all Makefiles, and most documentation files 
+     will be automatically distributed. Use this variable to distribute any 
+     files that are not automatically distributed.
      
+     
      FAKE_SOURCES(optional)
+     
      
+     
      This variable is like SOURCES except that
+     the source files don't need to exist. The makefiles only use
+     FAKE_SOURCES to create the names of derived objects that should be
+     included in the directory's result. It is assumed that the project's
+     Makefile will define how to build the derived objects
+     necessary.
      
+     
      KEEP_SYMBOLS
      
+     
      If set to any value, specifies that when linking executables the
+     makefiles should retain debug symbols in the executable. Normally, symbols
+     are stripped from the executable.
      
+     
      LEVEL(required)
      
+     
      Specify the level of nesting from the top level. This variable must be
+     set in each makefile as it is used to find the top level and thus the other
+     makefiles.
      
+     
      LIBRARYNAME
      
+     
      Specify the name of the library to be built. (Required For
+     Libraries)
      
+     
      LLVMLIBS
      
+     
      Specifies the set of libraries from the LLVM $(ObjDir) that will be
+     linked into the tool or library.
      
+     
      MODULE_NAME
      
+     
      Specifies the name of a bytecode module to be created. A bytecode 
+     module can be specified in conjunction with other kinds of library builds 
+     or by itself. It constructs from the sources a single linked bytecode 
+     file.
      
+     
      OPTIONAL_DIRS
      
+     
      Specify a set of directories that may be built, if they exist, but its
+     not an error for them not to exist.
      
+     
      PARALLEL_DIRS
      
+     
      Specify a set of directories to build recursively and in parallel if
+     the -j option was used with make.
      
+     
      SHARED_LIBRARY
      
+     
      If set to any value, causes a shared library (.so) to be built in
+     addition to any other kinds of libraries. Note that this option will cause
+     all source files to be built twice: once with options for position
+     independent code and once without. Use it only where you really need a
+     shared library.
      
+     
      SOURCES(optional)
      
+     
      Specifies the list of source files in the current directory to be
+     built. Source files of any type may be specified (programs, documentation, 
+     config files, etc.). If not specified, the makefile system will infer the
+     set of source files from the files present in the current directory.
      
+     
      SUFFIXES
      
+     
      Specifies a set of filename suffixes that occur in suffix match rules.
+     Only set this if your local Makefile specifies additional suffix
+     match rules.
       
+     
      TARGET
      
+     
      Specifies the name of the LLVM code generation target that the
+     current directory builds. Setting this variable enables additional rules to
+     build .inc files from .td files. 
      
+     
      TESTSUITE
      
+     
      Specifies the directory of tests to run in llvm/test.
      
+     
      TOOLNAME
      
+     
      Specifies the name of the tool that the current directory should
+     build.
      
+     
      TOOL_VERBOSE
      
+     
      Implies VERBOSE and also tells each tool invoked to be verbose. This is
+     handy when you're trying to see the sub-tools invoked by each tool invoked 
+     by the makefile. For example, this will pass -v to the GCC 
+     compilers which causes it to print out the command lines it uses to invoke
+     sub-tools (compiler, assembler, linker).
      
+     
      USEDLIBS
      
+     
      Specifies the list of project libraries that will be linked into the
+     tool or library.
      
+     
      VERBOSE
      
+     
      Tells the Makefile system to produce detailed output of what it is doing
+     instead of just summary comments. This will generate a LOT of output.
      
+   
      
+ 
      
+ 
+ 
+ 
      Override Variables
      
+ 
      
+   
      Override variables can be used to override the default
+   values provided by the LLVM makefile system. These variables can be set in 
+   several ways:
      
+   
        
+     
      • In the environment (e.g. setenv, export) -- not recommended.
        • 
+     
      • On the make command line -- recommended.
        • 
+     
      • On the configure command line
        • 
+     
      • In the Makefile (only after the inclusion of $(LEVEL)/Makefile.common).
        • 
+   
      
+   
      The override variables are given below:
      
+   
      
+     
      AR (defaulted)
      
+     
      Specifies the path to the ar tool.
      
+     
      BISON(configured)
      
+     
      Specifies the path to the bison tool.
      
+     
      BUILD_OBJ_DIR
      
+     
      The directory into which the products of build rules will be placed.
+     This might be the same as 
+     BUILD_SRC_DIR but typically is
+     not.
      
+     
      BUILD_SRC_DIR
      
+     
      The directory which contains the source files to be built.
      
+     
      BURG
      
+     
      Specifies the path to the burg tool.
      
+     
      BZIP2(configured)
      
+     
      The path to the bzip2 tool.
      
+     
      CC(configured)
      
+     
      The path to the 'C' compiler.
      
+     
      CFLAGS
      
+     
      Additional flags to be passed to the 'C' compiler.
      
+     
      CXX
      
+     
      Specifies the path to the C++ compiler.
      
+     
      CXXFLAGS
      
+     
      Additional flags to be passed to the C++ compiler.
      
+     
      DATE(configured)
      
+     
      Specifies the path to the date program or any program that can
+     generate the current date and time on its standard output
      
+     
      DOT(configured)
      
+     
      Specifies the path to the dot tool or false if there
+     isn't one.
      
+     
      ECHO(configured)
      
+     
      Specifies the path to the echo tool for printing output.
      
+     
      ETAGS(configured)
      
+     
      Specifies the path to the etags tool.
      
+     
      ETAGSFLAGS(configured)
      
+     
      Provides flags to be passed to the etags tool.
      
+     
      EXEEXT(configured)
      
+     
      Provides the extension to be used on executables built by the makefiles.
+     The value may be empty on platforms that do not use file extensions for
+     executables (e.g. Unix).
      
+     
      FLEX(configured)
      
+     
      Specifies the path to the flex tool.
      
+     
      GCCLD(defaulted)
      
+     
      Specifies the path to the gccld tool.
      
+     
      INSTALL(configured)
      
+     
      Specifies the path to the install tool.
      
+     
      LDFLAGS(configured)
      
+     
      Allows users to specify additional flags to pass to the linker.
      
+     
      LIBS(configured)
      
+     
      The list of libraries that should be linked with each tool.
      
+     
      LIBTOOL(configured)
      
+     
      Specifies the path to the libtool tool. This tool is renamed
+     mklib by the configure script and always located in the 
+     
      LLVMAS(defaulted)
      
+     
      Specifies the path to the llvm-as tool.
      
+     
      LLVMGCC(defaulted)
      
+     
      Specifies the path to the LLVM version of the GCC 'C' Compiler
      
+     
      LLVMGXX(defaulted)
      
+     
      Specifies the path to the LLVM version of the GCC C++ Compiler
      
+     
      LLVM_OBJ_ROOT(configured)
      
+     
      Specifies the top directory into which the output of the build is
+     placed.
      
+     
      LLVM_SRC_ROOT(configured)
      
+     
      Specifies the top directory in which the sources are found.
      
+     
      LLVM_TARBALL_NAME(configured)
      
+     
      Specifies the name of the distribution tarball to create. This is
+     configured from the name of the project and its version number.
      
+     
      MKDIR(defaulted)
      
+     
      Specifies the path to the mkdir tool that creates
+     directories.
      
+     
      PLATFORMSTRIPOPTS
      
+     
      The options to provide to the linker to specify that a stripped (no
+     symbols) executable should be built.
      
+     
      RANLIB(defaulted)
      
+     
      Specifies the path to the ranlib tool.
      
+     
      RM(defaulted)
      
+     
      Specifies the path to the rm tool.
      
+     
      SED(defaulted)
      
+     
      Specifies the path to the sed tool.
      
+     
      SHLIBEXT(configured)
      
+     
      Provides the filename extension to use for shared libraries.
      
+     
      TBLGEN(defaulted)
      
+     
      Specifies the path to the tblgen tool.
      
+     
      TAR(defaulted)
      
+     
      Specifies the path to the tar tool.
      
+     
      ZIP(defaulted)
      
+     
      Specifies the path to the zip tool.
      
+   
      
+ 
      
+ 
+ 
+ 
      Readable Variables
      
+ 
      
+   
      Variables listed in the table below can be used by the user's Makefile but
+   should not be changed. Changing the value will generally cause the build to go
+   wrong, so don't do it.
      
+   
      
+     
      bindir
      
+     
      The directory into which executables will ultimately be installed. This
+     value is derived from the --prefix option given to
+     configure.
      
+     
      BuildMode
      
+     
      The name of the type of build being performed: Debug, Release, or 
+     Profile
      
+     
      bytecode_libdir
      
+     
      The directory into which bytecode libraries will ultimately be installed. 
+     This value is derived from the --prefix option given to
+     configure.
      
+     
      ConfigureScriptFLAGS
      
+     
      Additional flags given to the configure script when
+     reconfiguring.
      
+     
      DistDir
      
+     
      The current directory for which a distribution copy is being
+     made.
      
+     
      Echo
      
+     
      The LLVM Makefile System output command. This provides the
+     llvm[n] prefix and starts with @ so the command itself is not
+     printed by make.
      
+     
      EchoCmd
      
+     
       Same as Echo but without the leading @.
+     
      
+     
      includedir
      
+     
      The directory into which include files will ultimately be installed. 
+     This value is derived from the --prefix option given to
+     configure.
      
+     
      libdir
      
+     
      The directory into which native libraries will ultimately be installed. 
+     This value is derived from the --prefix option given to
+     configure.
      
+     
      LibDir
      
+     
      The configuration specific directory into which libraries are placed
+     before installation.
      
+     
      MakefileConfig
      
+     
      Full path of the Makefile.config file.
      
+     
      MakefileConfigIn
      
+     
      Full path of the Makefile.config.in file.
      
+     
      ObjDir
      
+     
      The configuration and directory specific directory where build objects
+     (compilation results) are placed.
      
+     
      SubDirs
      
+     
      The complete list of sub-directories of the current directory as
+     specified by other variables.
      
+     
      Sources
      
+     
      The complete list of source files.
      
+     
      sysconfdir
      
+     
      The directory into which configuration files will ultimately be
+     installed. This value is derived from the --prefix option given to
+     configure.
      
+     
      ToolDir
      
+     
      The configuration specific directory into which executables are placed
+     before they are installed.
      
+     
      TopDistDir
      
+     
      The top most directory into which the distribution files are copied.
+     
      
+     
      Verb
      
+     
      Use this as the first thing on your build script lines to enable or
+     disable verbose mode. It expands to either an @ (quiet mode) or nothing
+     (verbose mode). 
      
+   
      
+ 
      
+ 
+ 
+ 
      Internal Variables
      
+ 
      
+   
      Variables listed below are used by the LLVM Makefile System 
+   and considered internal. You should not use these variables under any
+   circumstances.
      
+   
      
+     Archive
+     AR.Flags
+     BaseNameSources
+     BCCompile.C
+     BCCompile.CXX
+     BCLinkLib
+     Burg
+     C.Flags
+     Compile.C
+     CompileCommonOpts
+     Compile.CXX
+     ConfigStatusScript
+     ConfigureScript
+     CPP.Flags
+     CPP.Flags 
+     CXX.Flags
+     DependFiles
+     DestArchiveLib
+     DestBytecodeLib
+     DestModule
+     DestRelinkedLib
+     DestSharedLib
+     DestTool
+     DistAlways
+     DistCheckDir
+     DistCheckTop
+     DistFiles
+     DistName
+     DistOther
+     DistSources
+     DistSubDirs
+     DistTarBZ2
+     DistTarGZip
+     DistZip
+     ExtraLibs
+     FakeSources
+     INCFiles
+     InternalTargets
+     LD.Flags
+     LexFiles
+     LexOutput
+     LibName.A
+     LibName.BC
+     LibName.LA
+     LibName.O
+     LibTool.Flags
+     Link
+     LinkModule
+     LLVMLibDir
+     LLVMLibsOptions
+     LLVMLibsPaths
+     LLVMToolDir
+     LLVMUsedLibs
+     LocalTargets
+     LTCompile.C
+     LTCompile.CXX
+     LTInstall
+     Module
+     ObjectsBC
+     ObjectsLO
+     ObjectsO
+     ObjMakefiles
+     ParallelTargets
+     PreConditions
+     ProjLibsOptions
+     ProjLibsPaths
+     ProjUsedLibs
+     Ranlib
+     RecursiveTargets
+     Relink
+     SrcMakefiles
+     Strip
+     StripWarnMsg
+     TableGen
+     TDFiles
+     ToolBuildPath
+     TopLevelTargets
+     UserTargets
+     YaccFiles
+     YaccOutput
+   
      
+ 
      
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Reid Spencer
      
+   The LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/OpenProjects.html
diff -c /dev/null llvm-www/releases/1.4/docs/OpenProjects.html:1.1
*** /dev/null	Thu Dec  9 16:19:07 2004
--- llvm-www/releases/1.4/docs/OpenProjects.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,394 ----
+ 
+ 
+ 
+   Open LLVM Projects
+   
+ 
+ 
+ 
+ 
      
+   Open LLVM Projects
+ 
      
+ 
+ 
+ 
+ 
      
+   
      Written by the LLVM Team
      
+ 
      
+ 
+ 
+ 
+ 
      
+   What is this?
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      This document is meant to be a sort of "big TODO list" for LLVM.  Each
+ project in this document is something that would be useful for LLVM to have, and
+ would also be a great way to get familiar with the system.  Some of these
+ projects are small and self-contained, which may be implemented in a couple of
+ days, others are larger.  Several of these projects may lead to interesting
+ research projects in their own right.  In any case, we welcome all
+ contributions.
      
+ 
+ 
      If you are thinking about tackling one of these projects, please send a mail
+ to the LLVM
+ Developer's mailing list, so that we know the project is being worked on.
+ Additionally this is a good way to get more information about a specific project
+ or to suggest other projects to add to this page.
+ 
      
+ 
+ 
      The projects in this page are open-ended. More specific projects are
+ filed as unassigned enhancements in the 
+ LLVM bug tracker. See the list of currently outstanding issues if you wish to help improve LLVM.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Improving the current system
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Improvements to the current infrastructure are always very welcome and tend
+ to be fairly straight-forward to implement.  Here are some of the key areas that
+ can use improvement...
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Implementing Code Cleanup bugs
+ 
      
+ 
+ 
      
+ 
+ 
      
+ The LLVM bug tracker occasionally
+ has "code-cleanup" bugs filed in it.  Taking one of these and fixing it is a good
+ way to get your feet wet in the LLVM code and discover how some of its components
+ work.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Port glibc to LLVM
+ 
      
+ 
+ 
      
+ 
+ 
      It would be very useful to port glibc to LLVM.  This would allow a
+ variety of interprocedural algorithms to be much more effective in the face of
+ library calls.  The most important pieces to port are things like the string
+ library and the stdio related functions... low-level system calls like
+ 'read' should stay unimplemented in LLVM.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Compile programs with the LLVM Compiler
+ 
      
+ 
+ 
      
+ 
+ 
      We are always looking for new testcases and benchmarks for use with LLVM.  In
+ particular, it is useful to try compiling your favorite C source code with LLVM.
+ If it doesn't compile, try to figure out why or report it to the llvm-bugs list.  If you
+ get the program to compile, it would be extremely useful to convert the build
+ system to be compatible with the LLVM Programs testsuite so that we can check it
+ into CVS and the automated tester can use it to track progress of the
+ compiler.
      
+ 
+ 
      When testing a code, try running it with a variety of optimizations, and with
+ all the back-ends: CBE, llc, and lli.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Extend the LLVM intermediate representation
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
      1. Add support for platform-independent prefetch support.  The GCC prefetch project page
+     has a good survey of the prefetching capabilities of a variety of modern
+     processors.
        2. 
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Target backend improvements
+ 
      
+ 
+ 
      
+ 
+ 
        
+   
      1. Find benchmarks either using our test results or on your own,
+   where LLVM code generators do not produce optimal code or simply where another
+   compiler produces better code.  Try to minimize the test case that
+   demonstrates the issue.  Then, either submit a bug with your testcase and
+   the code that LLVM produces vs. the code that it should produce, or
+   even better, see if you can improve the code generator and submit a
+   patch.
        2. 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Miscellaneous Improvements
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
      1. Rework the PassManager to be more flexible
        2. 
+ 
+ 
      2. Some transformations and analyses only work on reducible flow graphs.  It
+ would be nice to have a transformation which could be "required" by these passes
+ which makes irreducible graphs reducible.  This can easily be accomplished
+ through code duplication.  See Making Graphs Reducible
+ with Controlled Node Splitting and perhaps Nesting of Reducible and
+ Irreducible Loops.
        3. 
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Adding new capabilities to LLVM
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Sometimes creating new things is more fun than improving existing things.
+ These projects tend to be more involved and perhaps require more work, but can
+ also be very rewarding.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Implementing new feature PRs
+ 
      
+ 
+ 
      
+ 
+ 
      Many ideas for feature requests are stored in LLVM bugzilla.  Just search for bugs with a "new-feature" keyword.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Pointer and Alias Analysis
+ 
      
+ 
+ 
      
+ 
+ 
      We have a strong base for development of
+ both pointer analysis based optimizations as well as pointer analyses
+ themselves.  It seems natural to want to take advantage of this...
      
+ 
+ 
        
+ 
      1. Implement a flow-sensitive context-sensitive alias analysis algorithm
        
+   - Pick one of the somewhat efficient algorithms, but strive for maximum
+     precision
        2. 
+ 
+ 
      2. Implement a flow-sensitive context-insensitive alias analysis algorithm
        
+   - Just an efficient local algorithm perhaps?
        3. 
+ 
+ 
      3. Implement alias-analysis-based optimizations:
+   
          
+   
        • ...
          • 
+   
        4. 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Profile-Guided Optimization
+ 
      
+ 
+ 
      
+ 
+ 
      We now have a unified infrastructure for writing profile-guided
+ transformations, which will work either at offline-compile-time or in the JIT,
+ but we don't have many transformations.  We would welcome new profile-guided
+ transformations as well as improvements to the current profiling system.
+ 
      
+ 
+ 
      Ideas for profile-guided transformations:
      
+ 
+ 
        
+ 
      1. Superblock formation (with many optimizations)
        2. 
+ 
      2. Loop unrolling/peeling
        3. 
+ 
      3. Profile directed inlining
        4. 
+ 
      4. Code layout
        5. 
+ 
      5. ...
        6. 
+ 
      
+ 
+ 
      Improvements to the existing support:
      
+ 
+ 
        
+ 
      1. The current block and edge profiling code that gets inserted is very simple
+ and inefficient.  Through the use of control-dependence information, many fewer
+ counters could be inserted into the code.  Also, if the execution count of a
+ loop is known to be a compile-time or runtime constant, all of the counters in
+ the loop could be avoided.
        2. 
+ 
+ 
      2. You could implement one of the "static profiling" algorithms which analyze a
+ piece of code an make educated guesses about the relative execution frequencies
+ of various parts of the code.
        3. 
+ 
+ 
      3. You could add path profiling support, or adapt the existing LLVM path
+ profiling code to work with the generic profiling interfaces.
        4. 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   New Transformations and Analyses
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
      1. Implement GVN-PRE, a 
+   powerful and simple Partial Redundancy Elimination algorithm for SSA form
        2. 
+ 
      2. Implement a Dependence Analysis Infrastructure
        
+      - Design some way to represent and query dep analysis
        3. 
+ 
      3. Implement a strength reduction pass
        4. 
+ 
      4. Value range propagation pass
        5. 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   X86 Back-end Improvements
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
      1. Implement a better instruction selector
        2. 
+ 
      2. Implement support for the "switch" instruction without requiring the 
+     lower-switches pass.
        3. 
+ 
      3. Implement interprocedural register allocation. The CallGraphSCCPass can be
+     used to implement a bottom-up analysis that will determine the *actual* 
+     registers clobbered by a function. Use the pass to fine tune register usage 
+     in callers based on *actual* registers used by the callee.
        4. 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Miscellaneous Additions
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
      1. Port the Bigloo
+ Scheme compiler, from Manuel Serrano at INRIA Sophia-Antipolis, to
+ output LLVM bytecode. It seems that it can already output .NET
+ bytecode, JVM bytecode, and C, so LLVM would ostensibly be another good
+ candidate.
        2. 
+ 
      2. Write a new frontend for C/C++ in C++, giving us the ability to
+ directly use LLVM C++ classes from within a compiler rather than use
+ C-based wrapper functions a la llvm-gcc.  One possible starting point is the C++
+ yacc grammar by Ed Willink.
        3. 
+ 
      3. Write a new frontend for some other language (Java? OCaml? Forth?)
        4. 
+ 
      4. Write a new backend for a target (IA64? MIPS? MMIX?)
        5. 
+ 
      5. Write a disassembler for machine code that would use TableGen to output 
+ MachineInstrs for transformations, optimizations, etc.
        6. 
+ 
      6. Random test vector generator: Use a C grammar to generate random C code;
+ run it through llvm-gcc, then run a random set of passes on it using opt.
+ Try to crash opt. When opt crashes, use bugpoint to reduce the test case and
+ mail the result to yourself.  Repeat ad infinitum.
        7. 
+ 
      7. Design a simple, recognizable logo.
        8. 
+ 
      8. Improve the usefulness and utility of the Skeleton target backend:
+ 
          
+   
        • Convert the non-functional Skeleton target to become an abstract machine
+   target (choose some simple instructions, a register set, etc).  This will
+   become a much more useful example of a backend since it would be a simple
+   but functional backend.  Examples of such architectures include MIX,
+   MMIX, DLX,
+   or come up with your own!
          • 
+   
        • Use the new Skeleton backend in the Interpreter: compile LLVM to Skeleton
+   target, and then interpret that code instead of LLVM.  Performance win would
+   be the primary goal, as the number of registers would be a small constant
+   instead of unbounded, for example.
          • 
+ 
        9. 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Chris Lattner
      
+   LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/ProgrammersManual.html
diff -c /dev/null llvm-www/releases/1.4/docs/ProgrammersManual.html:1.1
*** /dev/null	Thu Dec  9 16:19:07 2004
--- llvm-www/releases/1.4/docs/ProgrammersManual.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,2069 ----
+ 
+ 
+ 
+   LLVM Programmer's Manual
+   
+ 
+ 
+ 
+ 
      
+   LLVM Programmer's Manual
+ 
      
+ 
+ 
        
+   
      1. Introduction
        2. 
+   
      2. General Information
+     
+   
        3. 
+   
      3. Important and useful LLVM APIs
+     
+   
        4. 
+   
      4. Helpful Hints for Common Operations
+     
+   
        5. 
+   
      5. The Core LLVM Class Hierarchy Reference
+     
+   
        6. 
+   
      6. The SymbolTable class 
        7. 
+   
      7. The ilist and iplist classes
+     
          
+       
        • Creating, inserting, moving and deleting from LLVM lists 
          • 
+     
        
+   
        8. 
+   
      8. Important iterator invalidation semantics to be aware of.
        9. 
+ 
      
+ 
+ 
          
+   
      Written by Chris Lattner, 
+                 Dinakar Dhurjati, 
+                 Joel Stanley, and
+                 Reid Spencer
      
+ 
      
+ 
+ 
+ 
      
+   Introduction 
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      This document is meant to highlight some of the important classes and
+ interfaces available in the LLVM source-base.  This manual is not
+ intended to explain what LLVM is, how it works, and what LLVM code looks
+ like.  It assumes that you know the basics of LLVM and are interested
+ in writing transformations or otherwise analyzing or manipulating the
+ code.
      
+ 
+ 
      This document should get you oriented so that you can find your
+ way in the continuously growing source code that makes up the LLVM
+ infrastructure. Note that this manual is not intended to serve as a
+ replacement for reading the source code, so if you think there should be
+ a method in one of these classes to do something, but it's not listed,
+ check the source.  Links to the doxygen sources
+ are provided to make this as easy as possible.
      
+ 
+ 
      The first section of this document describes general information that is
+ useful to know when working in the LLVM infrastructure, and the second describes
+ the Core LLVM classes.  In the future this manual will be extended with
+ information describing how to use extension libraries, such as dominator
+ information, CFG traversal routines, and useful utilities like the InstVisitor template.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   General Information
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      This section contains general information that is useful if you are working
+ in the LLVM source-base, but that isn't specific to any particular API.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The C++ Standard Template Library
+ 
      
+ 
+ 
      
+ 
+ 
      LLVM makes heavy use of the C++ Standard Template Library (STL),
+ perhaps much more than you are used to, or have seen before.  Because of
+ this, you might want to do a little background reading in the
+ techniques used and capabilities of the library.  There are many good
+ pages that discuss the STL, and several books on the subject that you
+ can get, so it will not be discussed in this document.
      
+ 
+ 
      Here are some useful links:
      
+ 
+ 
        
+ 
+ 
      1. Dinkumware C++ Library
+ reference - an excellent reference for the STL and other parts of the
+ standard C++ library.
        2. 
+ 
+ 
      2. C++ In a Nutshell - This is an
+ O'Reilly book in the making.  It has a decent 
+ Standard Library
+ Reference that rivals Dinkumware's, and is unfortunately no longer free since the book has been 
+ published.
        3. 
+ 
+ 
      3. C++ Frequently Asked
+ Questions
        4. 
+ 
+ 
      4. SGI's STL Programmer's Guide -
+ Contains a useful Introduction to the
+ STL.
        5. 
+ 
+ 
      5. Bjarne Stroustrup's C++
+ Page
        6. 
+ 
+ 
      6. 
+ Bruce Eckel's Thinking in C++, 2nd ed. Volume 2 Revision 4.0 (even better, get
+ the book).
        7. 
+ 
+ 
      
+   
+ 
      You are also encouraged to take a look at the LLVM Coding Standards guide which focuses on how
+ to write maintainable code more than where to put your curly braces.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Other useful references
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
      1. CVS
+ Branch and Tag Primer
        2. 
+ 
      2. Using
+ static and shared libraries across platforms
        3. 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Important and useful LLVM APIs
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Here we highlight some LLVM APIs that are generally useful and good to
+ know about when writing transformations.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The isa<>, cast<> and dyn_cast<> templates
+ 
      
+ 
+ 
      
+ 
+ 
      The LLVM source-base makes extensive use of a custom form of RTTI.
+ These templates have many similarities to the C++ dynamic_cast<>
+ operator, but they don't have some drawbacks (primarily stemming from
+ the fact that dynamic_cast<> only works on classes that
+ have a v-table). Because they are used so often, you must know what they
+ do and how they work. All of these templates are defined in the Support/Casting.h
+ file (note that you very rarely have to include this file directly).
      
+ 
+ 
      
+   
      isa<>: 
      
+ 
+   
      The isa<> operator works exactly like the Java
+   "instanceof" operator.  It returns true or false depending on whether
+   a reference or pointer points to an instance of the specified class.  This can
+   be very useful for constraint checking of various sorts (example below).
      
+ 
+   
      cast<>: 
      
+ 
+   
      The cast<> operator is a "checked cast" operation. It
+   converts a pointer or reference from a base class to a derived cast, causing
+   an assertion failure if it is not really an instance of the right type.  This
+   should be used in cases where you have some information that makes you believe
+   that something is of the right type.  An example of the isa<>
+   and cast<> template is:
+ 
+   
      +   static bool isLoopInvariant(const Value *V, const Loop *L) {
+     if (isa<Constant>(V) || isa<Argument>(V) || isa<GlobalValue>(V))
+       return true;
+ 
+   // Otherwise, it must be an instruction...
+   return !L->contains(cast<Instruction>(V)->getParent());
+   
      
+ 
+   
      Note that you should not use an isa<> test followed
+   by a cast<>, for that use the dyn_cast<>
+   operator.
      
+ 
+   
      
+ 
+   
      dyn_cast<>:
      
+ 
+   
      The dyn_cast<> operator is a "checking cast" operation. It
+   checks to see if the operand is of the specified type, and if so, returns a
+   pointer to it (this operator does not work with references). If the operand is
+   not of the correct type, a null pointer is returned.  Thus, this works very
+   much like the dynamic_cast operator in C++, and should be used in the
+   same circumstances.  Typically, the dyn_cast<> operator is used
+   in an if statement or some other flow control statement like this:
+ 
+    
      +      if (AllocationInst *AI = dyn_cast<AllocationInst>(Val)) {
+        ...
+      }
+    
      
+    
+    
       This form of the if statement effectively combines together a
+    call to isa<> and a call to cast<> into one
+    statement, which is very convenient.
      
+ 
+    
       Another common example is:
      
+ 
+    
      +      // Loop over all of the phi nodes in a basic block
+      BasicBlock::iterator BBI = BB->begin();
+      for (; PHINode *PN = dyn_cast<PHINode>(BBI); ++BBI)
+        std::cerr << *PN;
+    
      
+ 
+    
      Note that the dyn_cast<> operator, like C++'s
+    dynamic_cast or Java's instanceof operator, can be abused.
+    In particular you should not use big chained if/then/else blocks to
+    check for lots of different variants of classes.  If you find yourself
+    wanting to do this, it is much cleaner and more efficient to use the
+    InstVisitor class to dispatch over the instruction type directly.
      
+ 
+     
      
+ 
+     
      cast_or_null<>: 
      
+    
+     
      The cast_or_null<> operator works just like the
+     cast<> operator, except that it allows for a null pointer as
+     an argument (which it then propagates).  This can sometimes be useful,
+     allowing you to combine several null checks into one.
      
+ 
+     
      dyn_cast_or_null<>: 
      
+ 
+     
      The dyn_cast_or_null<> operator works just like the
+     dyn_cast<> operator, except that it allows for a null pointer
+     as an argument (which it then propagates).  This can sometimes be useful,
+     allowing you to combine several null checks into one.
      
+ 
+   
      
+ 
+ 
      These five templates can be used with any classes, whether they have a
+ v-table or not.  To add support for these templates, you simply need to add
+ classof static methods to the class you are interested casting
+ to. Describing this is currently outside the scope of this document, but there
+ are lots of examples in the LLVM source base.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The DEBUG() macro & -debug option
+ 
      
+ 
+ 
      
+ 
+ 
      Often when working on your pass you will put a bunch of debugging printouts
+ and other code into your pass.  After you get it working, you want to remove
+ it... but you may need it again in the future (to work out new bugs that you run
+ across).
      
+ 
+ 
       Naturally, because of this, you don't want to delete the debug printouts,
+ but you don't want them to always be noisy.  A standard compromise is to comment
+ them out, allowing you to enable them if you need them in the future.
      
+ 
+ 
      The "Support/Debug.h"
+ file provides a macro named DEBUG() that is a much nicer solution to
+ this problem.  Basically, you can put arbitrary code into the argument of the
+ DEBUG macro, and it is only executed if 'opt' (or any other
+ tool) is run with the '-debug' command line argument:
      
+ 
+   
           ... 
           DEBUG(std::cerr << "I am here!\n");
           ...
      
+ 
+ 
      Then you can run your pass like this:
      
+ 
+   
        $ opt < a.bc > /dev/null -mypass
          <no output>
        $ opt < a.bc > /dev/null -mypass -debug
          I am here!
        $
      
+ 
+ 
      Using the DEBUG() macro instead of a home-brewed solution allows you
+ to not have to create "yet another" command line option for the debug output for
+ your pass.  Note that DEBUG() macros are disabled for optimized builds,
+ so they do not cause a performance impact at all (for the same reason, they
+ should also not contain side-effects!).
      
+ 
+ 
      One additional nice thing about the DEBUG() macro is that you can
+ enable or disable it directly in gdb.  Just use "set DebugFlag=0" or
+ "set DebugFlag=1" from the gdb if the program is running.  If the
+ program hasn't been started yet, you can always just run it with
+ -debug.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Fine grained debug info with DEBUG_TYPE() and
+   the -debug-only option
+ 
      
+ 
+ 
      
+ 
+ 
      Sometimes you may find yourself in a situation where enabling -debug
+ just turns on too much information (such as when working on the code
+ generator).  If you want to enable debug information with more fine-grained
+ control, you define the DEBUG_TYPE macro and the -debug only
+ option as follows:
      
+ 
+   
           ...
           DEBUG(std::cerr << "No debug type\n");
           #undef  DEBUG_TYPE
           #define DEBUG_TYPE "foo"
           DEBUG(std::cerr << "'foo' debug type\n");
           #undef  DEBUG_TYPE
           #define DEBUG_TYPE "bar"
           DEBUG(std::cerr << "'bar' debug type\n");
           #undef  DEBUG_TYPE
           #define DEBUG_TYPE ""
           DEBUG(std::cerr << "No debug type (2)\n");
           ...
      
+ 
+ 
      Then you can run your pass like this:
      
+ 
+   
        $ opt < a.bc > /dev/null -mypass
          <no output>
        $ opt < a.bc > /dev/null -mypass -debug
          No debug type
          'foo' debug type
          'bar' debug type
          No debug type (2)
        $ opt < a.bc > /dev/null -mypass -debug-only=foo
          'foo' debug type
        $ opt < a.bc > /dev/null -mypass -debug-only=bar
          'bar' debug type
        $
      
+ 
+ 
      Of course, in practice, you should only set DEBUG_TYPE at the top of
+ a file, to specify the debug type for the entire module (if you do this before
+ you #include "Support/Debug.h", you don't have to insert the ugly
+ #undef's).  Also, you should use names more meaningful than "foo" and
+ "bar", because there is no system in place to ensure that names do not
+ conflict. If two different modules use the same string, they will all be turned
+ on when the name is specified. This allows, for example, all debug information
+ for instruction scheduling to be enabled with -debug-type=InstrSched,
+ even if the source lives in multiple files.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The Statistic template & -stats
+   option
+ 
      
+ 
+ 
      
+ 
+ 
      The "Support/Statistic.h" file
+ provides a template named Statistic that is used as a unified way to
+ keep track of what the LLVM compiler is doing and how effective various
+ optimizations are.  It is useful to see what optimizations are contributing to
+ making a particular program run faster.
      
+ 
+ 
      Often you may run your pass on some big program, and you're interested to see
+ how many times it makes a certain transformation.  Although you can do this with
+ hand inspection, or some ad-hoc method, this is a real pain and not very useful
+ for big programs.  Using the Statistic template makes it very easy to
+ keep track of this information, and the calculated information is presented in a
+ uniform manner with the rest of the passes being executed.
      
+ 
+ 
      There are many examples of Statistic uses, but the basics of using
+ it are as follows:
      
+ 
+ 
        
+     
      1. Define your statistic like this:
+       
        static Statistic<> NumXForms("mypassname", "The # of times I did stuff");
        
+ 
+       
        The Statistic template can emulate just about any data-type,
+       but if you do not specify a template argument, it defaults to acting like
+       an unsigned int counter (this is usually what you want).
        2. 
+ 
+     
      2. Whenever you make a transformation, bump the counter:
+       
           ++NumXForms;   // I did stuff
        
+     
        3. 
+   
      
+ 
+   
      That's all you have to do.  To get 'opt' to print out the
+   statistics gathered, use the '-stats' option:
      
+ 
+   
         $ opt -stats -mypassname < program.bc > /dev/null
          ... statistic output ...
      
+ 
+   
       When running gccas on a C file from the SPEC benchmark
+ suite, it gives a report that looks like this:
      
+ 
+   
         7646 bytecodewriter  - Number of normal instructions
          725 bytecodewriter  - Number of oversized instructions
       129996 bytecodewriter  - Number of bytecode bytes written
         2817 raise           - Number of insts DCEd or constprop'd
         3213 raise           - Number of cast-of-self removed
         5046 raise           - Number of expression trees converted
           75 raise           - Number of other getelementptr's formed
          138 raise           - Number of load/store peepholes
           42 deadtypeelim    - Number of unused typenames removed from symtab
          392 funcresolve     - Number of varargs functions resolved
           27 globaldce       - Number of global variables removed
            2 adce            - Number of basic blocks removed
          134 cee             - Number of branches revectored
           49 cee             - Number of setcc instruction eliminated
          532 gcse            - Number of loads removed
         2919 gcse            - Number!
  of instructions removed
           86 indvars         - Number of canonical indvars added
           87 indvars         - Number of aux indvars removed
           25 instcombine     - Number of dead inst eliminate
          434 instcombine     - Number of insts combined
          248 licm            - Number of load insts hoisted
         1298 licm            - Number of insts hoisted to a loop pre-header
            3 licm            - Number of insts hoisted to multiple loop preds (bad, no loop pre-header)
           75 mem2reg         - Number of alloca's promoted
         1444 cfgsimplify     - Number of blocks simplified
      
+ 
+ 
      Obviously, with so many optimizations, having a unified framework for this
+ stuff is very nice.  Making your pass fit well into the framework makes it more
+ maintainable and useful.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Helpful Hints for Common Operations
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      This section describes how to perform some very simple transformations of
+ LLVM code.  This is meant to give examples of common idioms used, showing the
+ practical side of LLVM transformations.  
       Because this is a "how-to" section,
+ you should also read about the main classes that you will be working with.  The
+ Core LLVM Class Hierarchy Reference contains details
+ and descriptions of the main classes that you should know about.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Basic Inspection and Traversal Routines
+ 
      
+ 
+ 
      
+ 
+ 
      The LLVM compiler infrastructure have many different data structures that may
+ be traversed.  Following the example of the C++ standard template library, the
+ techniques used to traverse these various data structures are all basically the
+ same.  For a enumerable sequence of values, the XXXbegin() function (or
+ method) returns an iterator to the start of the sequence, the XXXend()
+ function returns an iterator pointing to one past the last valid element of the
+ sequence, and there is some XXXiterator data type that is common
+ between the two operations.
      
+ 
+ 
      Because the pattern for iteration is common across many different aspects of
+ the program representation, the standard template library algorithms may be used
+ on them, and it is easier to remember how to iterate. First we show a few common
+ examples of the data structures that need to be traversed.  Other data
+ structures are traversed in very similar ways.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Iterating over the BasicBlocks in a Function
+ 
      
+ 
+ 
      
+ 
+ 
      It's quite common to have a Function instance that you'd like to
+ transform in some way; in particular, you'd like to manipulate its
+ BasicBlocks.  To facilitate this, you'll need to iterate over all of
+ the BasicBlocks that constitute the Function. The following is
+ an example that prints the name of a BasicBlock and the number of
+ Instructions it contains:
      
+ 
+   
        // func is a pointer to a Function instance
        for (Function::iterator i = func->begin(), e = func->end(); i != e; ++i) {

            // print out the name of the basic block if it has one, and then the
            // number of instructions that it contains

            cerr << "Basic block (name=" << i->getName() << ") has " 
                 << i->size() << " instructions.\n";
        }
      
+ 
+ 
      Note that i can be used as if it were a pointer for the purposes of
+ invoking member functions of the Instruction class.  This is
+ because the indirection operator is overloaded for the iterator
+ classes.  In the above code, the expression i->size() is
+ exactly equivalent to (*i).size() just like you'd expect.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Iterating over the Instructions in a BasicBlock
+ 
      
+ 
+ 
      
+ 
+ 
      Just like when dealing with BasicBlocks in Functions, it's
+ easy to iterate over the individual instructions that make up
+ BasicBlocks. Here's a code snippet that prints out each instruction in
+ a BasicBlock:
      
+ 
+   
        // blk is a pointer to a BasicBlock instance
        for (BasicBlock::iterator i = blk->begin(), e = blk->end(); i != e; ++i)
           // the next statement works since operator<<(ostream&,...) 
           // is overloaded for Instruction&
           cerr << *i << "\n";
      
+ 
+ 
      However, this isn't really the best way to print out the contents of a
+ BasicBlock!  Since the ostream operators are overloaded for virtually
+ anything you'll care about, you could have just invoked the print routine on the
+ basic block itself: cerr << *blk << "\n";.
      
+ 
+ 
      Note that currently operator<< is implemented for Value*, so
+ it will print out the contents of the pointer, instead of the pointer value you
+ might expect.  This is a deprecated interface that will be removed in the
+ future, so it's best not to depend on it.  To print out the pointer value for
+ now, you must cast to void*.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Iterating over the Instructions in a Function
+ 
      
+ 
+ 
      
+ 
+ 
      If you're finding that you commonly iterate over a Function's
+ BasicBlocks and then that BasicBlock's Instructions,
+ InstIterator should be used instead. You'll need to include llvm/Support/InstIterator.h,
+ and then instantiate InstIterators explicitly in your code.  Here's a
+ small example that shows how to dump all instructions in a function to the standard error stream:
      
+ 
+   
      #include "llvm/Support/InstIterator.h"
      ...
      // Suppose F is a ptr to a function
      for (inst_iterator i = inst_begin(F), e = inst_end(F); i != e; ++i)
        cerr << *i << "\n";
      
+ Easy, isn't it?  You can also use InstIterators to fill a
+ worklist with its initial contents.  For example, if you wanted to
+ initialize a worklist to contain all instructions in a Function
+ F, all you would need to do is something like:
+   
      std::set<Instruction*> worklist;
      worklist.insert(inst_begin(F), inst_end(F));
      
+ 
+ 
      The STL set worklist would now contain all instructions in the
+ Function pointed to by F.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Turning an iterator into a class pointer (and
+   vice-versa)
+ 
      
+ 
+ 
      
+ 
+ 
      Sometimes, it'll be useful to grab a reference (or pointer) to a class
+ instance when all you've got at hand is an iterator.  Well, extracting
+ a reference or a pointer from an iterator is very straight-forward.
+ Assuming that i is a BasicBlock::iterator and j
+ is a BasicBlock::const_iterator:
      
+ 
+   
          Instruction& inst = *i;   // grab reference to instruction reference
          Instruction* pinst = &*i; // grab pointer to instruction reference
          const Instruction& inst = *j;
      
+ 
+ 
      However, the iterators you'll be working with in the LLVM framework are
+ special: they will automatically convert to a ptr-to-instance type whenever they
+ need to.  Instead of dereferencing the iterator and then taking the address of
+ the result, you can simply assign the iterator to the proper pointer type and
+ you get the dereference and address-of operation as a result of the assignment
+ (behind the scenes, this is a result of overloading casting mechanisms).  Thus
+ the last line of the last example,
      
+ 
+   
      Instruction* pinst = &*i;
      
+ 
+ 
      is semantically equivalent to
      
+ 
+   
      Instruction* pinst = i;
      
+ 
+ 
      It's also possible to turn a class pointer into the corresponding iterator,
+ and this is a constant time operation (very efficient).  The following code
+ snippet illustrates use of the conversion constructors provided by LLVM
+ iterators.  By using these, you can explicitly grab the iterator of something
+ without actually obtaining it via iteration over some structure:
      
+ 
+   
      void printNextInstruction(Instruction* inst) {
          BasicBlock::iterator it(inst);
          ++it; // after this line, it refers to the instruction after *inst.
          if (it != inst->getParent()->end()) cerr << *it << "\n";
      }
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Finding call sites: a slightly more complex
+   example
+ 
      
+ 
+ 
      
+ 
+ 
      Say that you're writing a FunctionPass and would like to count all the
+ locations in the entire module (that is, across every Function) where a
+ certain function (i.e., some Function*) is already in scope.  As you'll
+ learn later, you may want to use an InstVisitor to accomplish this in a
+ much more straight-forward manner, but this example will allow us to explore how
+ you'd do it if you didn't have InstVisitor around. In pseudocode, this
+ is what we want to do:
      
+ 
+   
      initialize callCounter to zero
      for each Function f in the Module
          for each BasicBlock b in f
            for each Instruction i in b
              if (i is a CallInst and calls the given function)
                increment callCounter
      
+ 
+ 
      And the actual code is (remember, since we're writing a
+ FunctionPass, our FunctionPass-derived class simply has to
+ override the runOnFunction method...):
      
+ 
+   
      Function* targetFunc = ...;

      class OurFunctionPass : public FunctionPass {
        public:
          OurFunctionPass(): callCounter(0) { }

          virtual runOnFunction(Function& F) {
       	for (Function::iterator b = F.begin(), be = F.end(); b != be; ++b) {
       	    for (BasicBlock::iterator i = b->begin(); ie = b->end(); i != ie; ++i) {
       		if (CallInst* callInst = dyn_cast<CallInst>(&*i)) {
       		    // we know we've encountered a call instruction, so we
       		    // need to determine if it's a call to the
      	            // function pointed to by m_func or not.
        
       		    if (callInst->getCalledFunction() == targetFunc)
       			++callCounter;
       	    }
       	}
          }
          
        private:
          unsigned  callCounter;
      };
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Treating calls and invokes the same way
+ 
      
+ 
+ 
      
+ 
+ 
      You may have noticed that the previous example was a bit oversimplified in
+ that it did not deal with call sites generated by 'invoke' instructions. In
+ this, and in other situations, you may find that you want to treat
+ CallInsts and InvokeInsts the same way, even though their
+ most-specific common base class is Instruction, which includes lots of
+ less closely-related things. For these cases, LLVM provides a handy wrapper
+ class called CallSite.
+ It is essentially a wrapper around an Instruction pointer, with some
+ methods that provide functionality common to CallInsts and
+ InvokeInsts.
      
+ 
+ 
      This class has "value semantics": it should be passed by value, not by
+ reference and it should not be dynamically allocated or deallocated using
+ operator new or operator delete. It is efficiently copyable,
+ assignable and constructable, with costs equivalents to that of a bare pointer.
+ If you look at its definition, it has only a single pointer member.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Iterating over def-use & use-def chains
+ 
      
+ 
+ 
      
+ 
+ 
      Frequently, we might have an instance of the Value Class and we want to
+ determine which Users use the Value.  The list of all
+ Users of a particular Value is called a def-use chain.
+ For example, let's say we have a Function* named F to a
+ particular function foo. Finding all of the instructions that
+ use foo is as simple as iterating over the def-use chain
+ of F:
      
+ 
+   
      Function* F = ...;

      for (Value::use_iterator i = F->use_begin(), e = F->use_end(); i != e; ++i) {
          if (Instruction *Inst = dyn_cast<Instruction>(*i)) {
              cerr << "F is used in instruction:\n";
              cerr << *Inst << "\n";
          }
      }
      
+ 
+ 
      Alternately, it's common to have an instance of the User Class and need to know what
+ Values are used by it.  The list of all Values used by a
+ User is known as a use-def chain.  Instances of class
+ Instruction are common Users, so we might want to iterate over
+ all of the values that a particular instruction uses (that is, the operands of
+ the particular Instruction):
      
+ 
+   
      Instruction* pi = ...;

      for (User::op_iterator i = pi->op_begin(), e = pi->op_end(); i != e; ++i) {
          Value* v = *i;
          ...
      }
      
+ 
+ 
+ 
+ 
      
+ 
+ 
+ 
      
+   Making simple changes
+ 
      
+ 
+ 
      
+ 
+ 
      There are some primitive transformation operations present in the LLVM
+ infrastructure that are worth knowing about.  When performing
+ transformations, it's fairly common to manipulate the contents of basic
+ blocks. This section describes some of the common methods for doing so
+ and gives example code.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Creating and inserting new
+   Instructions
+ 
      
+ 
+ 
      
+ 
+ 
      Instantiating Instructions
      
+ 
+ 
      Creation of Instructions is straight-forward: simply call the
+ constructor for the kind of instruction to instantiate and provide the necessary
+ parameters. For example, an AllocaInst only requires a
+ (const-ptr-to) Type. Thus:
       
+ 
+ 
      AllocaInst* ai = new AllocaInst(Type::IntTy);
      
+ 
+ 
      will create an AllocaInst instance that represents the allocation of
+ one integer in the current stack frame, at runtime. Each Instruction
+ subclass is likely to have varying default parameters which change the semantics
+ of the instruction, so refer to the doxygen documentation for the subclass of
+ Instruction that you're interested in instantiating.
      
+ 
+ 
      Naming values
      
+ 
+ 
      It is very useful to name the values of instructions when you're able to, as
+ this facilitates the debugging of your transformations.  If you end up looking
+ at generated LLVM machine code, you definitely want to have logical names
+ associated with the results of instructions!  By supplying a value for the
+ Name (default) parameter of the Instruction constructor, you
+ associate a logical name with the result of the instruction's execution at
+ runtime.  For example, say that I'm writing a transformation that dynamically
+ allocates space for an integer on the stack, and that integer is going to be
+ used as some kind of index by some other code.  To accomplish this, I place an
+ AllocaInst at the first point in the first BasicBlock of some
+ Function, and I'm intending to use it within the same
+ Function. I might do:
      
+ 
+   
      AllocaInst* pa = new AllocaInst(Type::IntTy, 0, "indexLoc");
      
+ 
+ 
      where indexLoc is now the logical name of the instruction's
+ execution value, which is a pointer to an integer on the runtime stack.
      
+ 
+ 
      Inserting instructions
      
+ 
+ 
      There are essentially two ways to insert an Instruction
+ into an existing sequence of instructions that form a BasicBlock:
      
+ 
+ 
        
+   
      • Insertion into an explicit instruction list
+ 
+     
        Given a BasicBlock* pb, an Instruction* pi within that
+     BasicBlock, and a newly-created instruction we wish to insert
+     before *pi, we do the following: 
        
+ 
+       
          BasicBlock *pb = ...;
          Instruction *pi = ...;
          Instruction *newInst = new Instruction(...);
          pb->getInstList().insert(pi, newInst); // inserts newInst before pi in pb
        
+ 
+     
        Appending to the end of a BasicBlock is so common that
+     the Instruction class and Instruction-derived
+     classes provide constructors which take a pointer to a
+     BasicBlock to be appended to. For example code that
+     looked like: 
        
+ 
+       
          BasicBlock *pb = ...;
          Instruction *newInst = new Instruction(...);
          pb->getInstList().push_back(newInst); // appends newInst to pb
        
+ 
+     
        becomes: 
        
+ 
+       
          BasicBlock *pb = ...;
          Instruction *newInst = new Instruction(..., pb);
        
+ 
+     
        which is much cleaner, especially if you are creating
+     long instruction streams.
        • 
+ 
+   
      • Insertion into an implicit instruction list
+ 
+     
        Instruction instances that are already in BasicBlocks
+     are implicitly associated with an existing instruction list: the instruction
+     list of the enclosing basic block. Thus, we could have accomplished the same
+     thing as the above code without being given a BasicBlock by doing:
+     
        
+ 
+       
          Instruction *pi = ...;
          Instruction *newInst = new Instruction(...);
          pi->getParent()->getInstList().insert(pi, newInst);
        
+ 
+     
        In fact, this sequence of steps occurs so frequently that the
+     Instruction class and Instruction-derived classes provide
+     constructors which take (as a default parameter) a pointer to an
+     Instruction which the newly-created Instruction should
+     precede.  That is, Instruction constructors are capable of
+     inserting the newly-created instance into the BasicBlock of a
+     provided instruction, immediately before that instruction.  Using an
+     Instruction constructor with a insertBefore (default)
+     parameter, the above code becomes:
        
+ 
+       
        Instruction* pi = ...;
        Instruction* newInst = new Instruction(..., pi);
        
+ 
+     
        which is much cleaner, especially if you're creating a lot of
+ instructions and adding them to BasicBlocks.
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Deleting Instructions
+ 
      
+ 
+ 
      
+ 
+ 
      Deleting an instruction from an existing sequence of instructions that form a
+ BasicBlock is very straight-forward. First,
+ you must have a pointer to the instruction that you wish to delete.  Second, you
+ need to obtain the pointer to that instruction's basic block. You use the
+ pointer to the basic block to get its list of instructions and then use the
+ erase function to remove your instruction. For example:
      
+ 
+   
        Instruction *I = .. ;
        BasicBlock *BB = I->getParent();
        BB->getInstList().erase(I);
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Replacing an Instruction with another
+   Value
+ 
      
+ 
+ 
      
+ 
+ 
      Replacing individual instructions
      
+ 
+ 
      Including "llvm/Transforms/Utils/BasicBlockUtils.h"
+ permits use of two very useful replace functions: ReplaceInstWithValue
+ and ReplaceInstWithInst.
      
+ 
+ 
      Deleting Instructions
      
+ 
+ 
        
+   
      • ReplaceInstWithValue
+ 
+     
        This function replaces all uses (within a basic block) of a given
+     instruction with a value, and then removes the original instruction. The
+     following example illustrates the replacement of the result of a particular
+     AllocaInst that allocates memory for a single integer with an null
+     pointer to an integer.
        
+ 
+       
        AllocaInst* instToReplace = ...;
        BasicBlock::iterator ii(instToReplace);
        ReplaceInstWithValue(instToReplace->getParent()->getInstList(), ii,
                             Constant::getNullValue(PointerType::get(Type::IntTy)));
        • 
+ 
+   
      • ReplaceInstWithInst 
+ 
+     
        This function replaces a particular instruction with another
+     instruction. The following example illustrates the replacement of one
+     AllocaInst with another.
        
+ 
+       
        AllocaInst* instToReplace = ...;
        BasicBlock::iterator ii(instToReplace);
        ReplaceInstWithInst(instToReplace->getParent()->getInstList(), ii,
                            new AllocaInst(Type::IntTy, 0, "ptrToReplacedInt"));
        • 
+ 
      
+ 
+ 
      Replacing multiple uses of Users and Values
      
+ 
+ 
      You can use Value::replaceAllUsesWith and
+ User::replaceUsesOfWith to change more than one use at a time.  See the
+ doxygen documentation for the Value Class
+ and User Class, respectively, for more
+ information.
      
+ 
+ 
+ 
+ 
      
+ 
+ 
+ 
      
+   The Core LLVM Class Hierarchy Reference 
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      The Core LLVM classes are the primary means of representing the program
+ being inspected or transformed.  The core LLVM classes are defined in
+ header files in the include/llvm/ directory, and implemented in
+ the lib/VMCore directory.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The Value class
+ 
      
+ 
+ 
      
+ 
+ 
      #include "llvm/Value.h"
+ 
       
+ doxygen info: Value Class
      
+ 
+ 
      The Value class is the most important class in the LLVM Source
+ base.  It represents a typed value that may be used (among other things) as an
+ operand to an instruction.  There are many different types of Values,
+ such as Constants,Arguments. Even Instructions and Functions are Values.
      
+ 
+ 
      A particular Value may be used many times in the LLVM representation
+ for a program.  For example, an incoming argument to a function (represented
+ with an instance of the Argument class) is "used" by
+ every instruction in the function that references the argument.  To keep track
+ of this relationship, the Value class keeps a list of all of the Users that is using it (the User class is a base class for all nodes in the LLVM
+ graph that can refer to Values).  This use list is how LLVM represents
+ def-use information in the program, and is accessible through the use_*
+ methods, shown below.
      
+ 
+ 
      Because LLVM is a typed representation, every LLVM Value is typed,
+ and this Type is available through the getType()
+ method. In addition, all LLVM values can be named.  The "name" of the
+ Value is a symbolic string printed in the LLVM code:
      
+ 
+   
         %foo = add int 1, 2
      
+ 
+ 
      The name of this instruction is "foo". NOTE
+ that the name of any value may be missing (an empty string), so names should
+ ONLY be used for debugging (making the source code easier to read,
+ debugging printouts), they should not be used to keep track of values or map
+ between them.  For this purpose, use a std::map of pointers to the
+ Value itself instead.
      
+ 
+ 
      One important aspect of LLVM is that there is no distinction between an SSA
+ variable and the operation that produces it.  Because of this, any reference to
+ the value produced by an instruction (or the value available as an incoming
+ argument, for example) is represented as a direct pointer to the instance of
+ the class that
+ represents this value.  Although this may take some getting used to, it
+ simplifies the representation and makes it easier to manipulate.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Important Public Members of the Value class
+ 
      
+ 
+ 
      
+ 
+ 
        
+   
      • Value::use_iterator - Typedef for iterator over the
+ use-list
        
+     Value::use_const_iterator - Typedef for const_iterator over
+ the use-list
        
+     unsigned use_size() - Returns the number of users of the
+ value.
        
+     bool use_empty() - Returns true if there are no users.
        
+     use_iterator use_begin() - Get an iterator to the start of
+ the use-list.
        
+     use_iterator use_end() - Get an iterator to the end of the
+ use-list.
        
+     User *use_back() - Returns the last
+ element in the list.
+     
         These methods are the interface to access the def-use
+ information in LLVM.  As with all other iterators in LLVM, the naming
+ conventions follow the conventions defined by the STL.
        
+   
        • 
+   
      • Type *getType() const
+     
        This method returns the Type of the Value.
        
+   
        • 
+   
      • bool hasName() const
        
+     std::string getName() const
        
+     void setName(const std::string &Name)
+     
         This family of methods is used to access and assign a name to a Value,
+ be aware of the precaution above.
        
+   
        • 
+   
      • void replaceAllUsesWith(Value *V)
+ 
+     
        This method traverses the use list of a Value changing all Users of the current value to refer to
+     "V" instead.  For example, if you detect that an instruction always
+     produces a constant value (for example through constant folding), you can
+     replace all uses of the instruction with the constant like this:
        
+ 
+     
          Inst->replaceAllUsesWith(ConstVal);
        
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The User class
+ 
      
+ 
+ 
      
+   
+ 
      
+ #include "llvm/User.h"
      
+ doxygen info: User Class
      
+ Superclass: Value
      
+ 
+ 
      The User class is the common base class of all LLVM nodes that may
+ refer to Values.  It exposes a list of "Operands"
+ that are all of the Values that the User is
+ referring to.  The User class itself is a subclass of
+ Value.
      
+ 
+ 
      The operands of a User point directly to the LLVM Value that it refers to.  Because LLVM uses Static
+ Single Assignment (SSA) form, there can only be one definition referred to,
+ allowing this direct connection.  This connection provides the use-def
+ information in LLVM.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Important Public Members of the User class
+ 
      
+ 
+ 
      
+ 
+ 
      The User class exposes the operand list in two ways: through
+ an index access interface and through an iterator based interface.
      
+ 
+ 
        
+   
      • Value *getOperand(unsigned i)
        
+     unsigned getNumOperands()
+     
         These two methods expose the operands of the User in a
+ convenient form for direct access.
        • 
+ 
+   
      • User::op_iterator - Typedef for iterator over the operand
+ list
        
+     User::op_const_iterator use_iterator op_begin() -
+ Get an iterator to the start of the operand list.
        
+     use_iterator op_end() - Get an iterator to the end of the
+ operand list.
+     
         Together, these methods make up the iterator based interface to
+ the operands of a User.
        • 
+ 
      
+ 
+ 
          
+ 
+ 
+ 
      
+   The Instruction class
+ 
      
+ 
+ 
      
+ 
+ 
      #include "llvm/Instruction.h"
      
+ doxygen info: Instruction Class
      
+ Superclasses: User, Value
      
+ 
+ 
      The Instruction class is the common base class for all LLVM
+ instructions.  It provides only a few methods, but is a very commonly used
+ class.  The primary data tracked by the Instruction class itself is the
+ opcode (instruction type) and the parent BasicBlock the Instruction is embedded
+ into.  To represent a specific type of instruction, one of many subclasses of
+ Instruction are used.
      
+ 
+ 
       Because the Instruction class subclasses the User class, its operands can be accessed in the same
+ way as for other Users (with the
+ getOperand()/getNumOperands() and
+ op_begin()/op_end() methods).
       
       An important file for
+ the Instruction class is the llvm/Instruction.def file. This
+ file contains some meta-data about the various different types of instructions
+ in LLVM.  It describes the enum values that are used as opcodes (for example
+ Instruction::Add and Instruction::SetLE), as well as the
+ concrete sub-classes of Instruction that implement the instruction (for
+ example BinaryOperator and SetCondInst).  Unfortunately, the use of macros in
+ this file confuses doxygen, so these enum values don't show up correctly in the
+ doxygen output.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Important Public Members of the Instruction
+   class
+ 
      
+ 
+ 
      
+ 
+ 
        
+   
      • BasicBlock *getParent()
+     
        Returns the BasicBlock that
+ this  Instruction is embedded into.
        • 
+   
      • bool mayWriteToMemory()
+     
        Returns true if the instruction writes to memory, i.e. it is a
+       call,free,invoke, or store.
        • 
+   
      • unsigned getOpcode()
+     
        Returns the opcode for the Instruction.
        • 
+   
      • Instruction *clone() const
+     
        Returns another instance of the specified instruction, identical
+ in all ways to the original except that the instruction has no parent
+ (ie it's not embedded into a BasicBlock),
+ and it has no name
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The BasicBlock class
+ 
      
+ 
+ 
      
+ 
+ 
      #include "llvm/BasicBlock.h"
      
+ doxygen info: BasicBlock
+ Class
      
+ Superclass: Value
      
+ 
+ 
      This class represents a single entry multiple exit section of the code,
+ commonly known as a basic block by the compiler community.  The
+ BasicBlock class maintains a list of Instructions, which form the body of the block.
+ Matching the language definition, the last element of this list of instructions
+ is always a terminator instruction (a subclass of the TerminatorInst class).
      
+ 
+ 
      In addition to tracking the list of instructions that make up the block, the
+ BasicBlock class also keeps track of the Function that it is embedded into.
      
+ 
+ 
      Note that BasicBlocks themselves are Values, because they are referenced by instructions
+ like branches and can go in the switch tables. BasicBlocks have type
+ label.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Important Public Members of the BasicBlock
+   class
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
+ 
      • BasicBlock(const std::string &Name = "", Function *Parent = 0)
+ 
+ 
        The BasicBlock constructor is used to create new basic blocks for
+ insertion into a function.  The constructor optionally takes a name for the new
+ block, and a Function to insert it into.  If
+ the Parent parameter is specified, the new BasicBlock is
+ automatically inserted at the end of the specified Function, if not specified, the BasicBlock must be
+ manually inserted into the Function.
        • 
+ 
+ 
      • BasicBlock::iterator - Typedef for instruction list iterator
        
+ BasicBlock::const_iterator - Typedef for const_iterator.
        
+ begin(), end(), front(), back(),
+ size(), empty(), rbegin(), rend() -
+ STL-style functions for accessing the instruction list.
+ 
+ 
        These methods and typedefs are forwarding functions that have the same
+ semantics as the standard library methods of the same names.  These methods
+ expose the underlying instruction list of a basic block in a way that is easy to
+ manipulate.  To get the full complement of container operations (including
+ operations to update the list), you must use the getInstList()
+ method.
        • 
+ 
+ 
      • BasicBlock::InstListType &getInstList()
+ 
+ 
        This method is used to get access to the underlying container that actually
+ holds the Instructions.  This method must be used when there isn't a forwarding
+ function in the BasicBlock class for the operation that you would like
+ to perform.  Because there are no forwarding functions for "updating"
+ operations, you need to use this if you want to update the contents of a
+ BasicBlock.
        • 
+ 
+ 
      • Function *getParent()
+ 
+ 
         Returns a pointer to Function the block is
+ embedded into, or a null pointer if it is homeless.
        • 
+ 
+ 
      • TerminatorInst *getTerminator()
+ 
+ 
         Returns a pointer to the terminator instruction that appears at the end of
+ the BasicBlock.  If there is no terminator instruction, or if the last
+ instruction in the block is not a terminator, then a null pointer is
+ returned.
        • 
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The GlobalValue class
+ 
      
+ 
+ 
      
+ 
+ 
      #include "llvm/GlobalValue.h"
      
+ doxygen info: GlobalValue
+ Class
      
+ Superclasses: User, Value
      
+ 
+ 
      Global values (GlobalVariables or Functions) are the only LLVM values that are
+ visible in the bodies of all Functions.
+ Because they are visible at global scope, they are also subject to linking with
+ other globals defined in different translation units.  To control the linking
+ process, GlobalValues know their linkage rules. Specifically,
+ GlobalValues know whether they have internal or external linkage, as
+ defined by the LinkageTypes enumeration.
      
+ 
+ 
      If a GlobalValue has internal linkage (equivalent to being
+ static in C), it is not visible to code outside the current translation
+ unit, and does not participate in linking.  If it has external linkage, it is
+ visible to external code, and does participate in linking.  In addition to
+ linkage information, GlobalValues keep track of which Module they are currently part of.
      
+ 
+ 
      Because GlobalValues are memory objects, they are always referred to
+ by their address. As such, the Type of a
+ global is always a pointer to its contents. It is important to remember this
+ when using the GetElementPtrInst instruction because this pointer must
+ be dereferenced first. For example, if you have a GlobalVariable (a
+ subclass of GlobalValue) that is an array of 24 ints, type [24 x
+ int], then the GlobalVariable is a pointer to that array. Although
+ the address of the first element of this array and the value of the
+ GlobalVariable are the same, they have different types. The
+ GlobalVariable's type is [24 x int]. The first element's type
+ is int. Because of this, accessing a global value requires you to
+ dereference the pointer with GetElementPtrInst first, then its elements
+ can be accessed. This is explained in the LLVM
+ Language Reference Manual.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Important Public Members of the GlobalValue
+   class
+ 
      
+ 
+ 
      
+ 
+ 
        
+   
      • bool hasInternalLinkage() const
        
+     bool hasExternalLinkage() const
        
+     void setInternalLinkage(bool HasInternalLinkage)
+     
         These methods manipulate the linkage characteristics of the GlobalValue.
        
+     
         
        
+   
        • 
+   
      • Module *getParent()
+     
         This returns the Module that the
+ GlobalValue is currently embedded into.
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The Function class
+ 
      
+ 
+ 
      
+ 
+ 
      #include "llvm/Function.h"
       doxygen
+ info: Function Class
      
+ Superclasses: GlobalValue, User, Value
      
+ 
+ 
      The Function class represents a single procedure in LLVM.  It is
+ actually one of the more complex classes in the LLVM heirarchy because it must
+ keep track of a large amount of data.  The Function class keeps track
+ of a list of BasicBlocks, a list of formal Arguments, and a SymbolTable.
      
+ 
+ 
      The list of BasicBlocks is the most
+ commonly used part of Function objects.  The list imposes an implicit
+ ordering of the blocks in the function, which indicate how the code will be
+ layed out by the backend.  Additionally, the first BasicBlock is the implicit entry node for the
+ Function.  It is not legal in LLVM to explicitly branch to this initial
+ block.  There are no implicit exit nodes, and in fact there may be multiple exit
+ nodes from a single Function.  If the BasicBlock list is empty, this indicates that
+ the Function is actually a function declaration: the actual body of the
+ function hasn't been linked in yet.
      
+ 
+ 
      In addition to a list of BasicBlocks, the
+ Function class also keeps track of the list of formal Arguments that the function receives.  This
+ container manages the lifetime of the Argument
+ nodes, just like the BasicBlock list does for
+ the BasicBlocks.
      
+ 
+ 
      The SymbolTable is a very rarely used
+ LLVM feature that is only used when you have to look up a value by name.  Aside
+ from that, the SymbolTable is used
+ internally to make sure that there are not conflicts between the names of Instructions, BasicBlocks, or Arguments in the function body.
      
+ 
+ 
      Note that Function is a GlobalValue
+ and therefore also a Constant. The value of the function
+ is its address (after linking) which is guaranteed to be constant.
      
+ 
      
+ 
+ 
+ 
      
+   Important Public Members of the Function
+   class
+ 
      
+ 
+ 
      
+ 
+ 
        
+   
      • Function(const FunctionType
+   *Ty, LinkageTypes Linkage, const std::string &N = "", Module* Parent = 0)
+ 
+     
        Constructor used when you need to create new Functions to add
+     the the program.  The constructor must specify the type of the function to
+     create and what type of linkage the function should have. The FunctionType argument
+     specifies the formal arguments and return value for the function. The same
+     FunctionType value can be used to
+     create multiple functions. The Parent argument specifies the Module
+     in which the function is defined. If this argument is provided, the function
+     will automatically be inserted into that module's list of
+     functions.
        • 
+ 
+   
      • bool isExternal()
+ 
+     
        Return whether or not the Function has a body defined.  If the
+     function is "external", it does not have a body, and thus must be resolved
+     by linking with a function defined in a different translation unit.
        • 
+ 
+   
      • Function::iterator - Typedef for basic block list iterator
        
+     Function::const_iterator - Typedef for const_iterator.
        
+ 
+     begin(), end(), front(), back(),
+     size(), empty(), rbegin(), rend()
+ 
+     
        These are forwarding methods that make it easy to access the contents of
+     a Function object's BasicBlock
+     list.
        • 
+ 
+   
      • Function::BasicBlockListType &getBasicBlockList()
+ 
+     
        Returns the list of BasicBlocks.  This
+     is necessary to use when you need to update the list or perform a complex
+     action that doesn't have a forwarding method.
        • 
+ 
+   
      • Function::aiterator - Typedef for the argument list
+ iterator
        
+     Function::const_aiterator - Typedef for const_iterator.
        
+ 
+     abegin(), aend(), afront(), aback(),
+     asize(), aempty(), arbegin(), arend()
+ 
+     
        These are forwarding methods that make it easy to access the contents of
+     a Function object's Argument
+     list.
        • 
+ 
+   
      • Function::ArgumentListType &getArgumentList()
+ 
+     
        Returns the list of Arguments.  This is
+     necessary to use when you need to update the list or perform a complex
+     action that doesn't have a forwarding method.
        • 
+ 
+   
      • BasicBlock &getEntryBlock()
+ 
+     
        Returns the entry BasicBlock for the
+     function.  Because the entry block for the function is always the first
+     block, this returns the first block of the Function.
        • 
+ 
+   
      • Type *getReturnType()
        
+     FunctionType *getFunctionType()
+ 
+     
        This traverses the Type of the
+     Function and returns the return type of the function, or the FunctionType of the actual
+     function.
        • 
+ 
+   
      • SymbolTable *getSymbolTable()
+ 
+     
         Return a pointer to the SymbolTable
+     for this Function.
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The GlobalVariable class
+ 
      
+ 
+ 
      
+ 
+ 
      #include "llvm/GlobalVariable.h"
+ 
      
+ doxygen info: GlobalVariable
+ Class
       Superclasses: GlobalValue, User, Value
      
+ 
+ 
      Global variables are represented with the (suprise suprise)
+ GlobalVariable class. Like functions, GlobalVariables are also
+ subclasses of GlobalValue, and as such are
+ always referenced by their address (global values must live in memory, so their
+ "name" refers to their address). See GlobalValue for more on this. Global variables
+ may have an initial value (which must be a Constant), and if they have an initializer, they
+ may be marked as "constant" themselves (indicating that their contents never
+ change at runtime).
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Important Public Members of the
+   GlobalVariable class
+ 
      
+ 
+ 
      
+ 
+ 
        
+   
      • GlobalVariable(const Type *Ty, bool
+   isConstant, LinkageTypes& Linkage, Constant
+   *Initializer = 0, const std::string &Name = "", Module* Parent = 0)
+ 
+     
        Create a new global variable of the specified type. If
+     isConstant is true then the global variable will be marked as
+     unchanging for the program. The Linkage parameter specifies the type of
+     linkage (internal, external, weak, linkonce, appending) for the variable. If
+     the linkage is InternalLinkage, WeakLinkage, or LinkOnceLinkage,  then
+     the resultant global variable will have internal linkage.  AppendingLinkage
+     concatenates together all instances (in different translation units) of the
+     variable into a single variable but is only applicable to arrays.   See
+     the LLVM Language Reference for
+     further details on linkage types. Optionally an initializer, a name, and the
+     module to put the variable into may be specified for the global variable as
+     well.
        • 
+ 
+   
      • bool isConstant() const
+ 
+     
        Returns true if this is a global variable that is known not to
+     be modified at runtime.
        • 
+ 
+   
      • bool hasInitializer()
+ 
+     
        Returns true if this GlobalVariable has an intializer.
        • 
+ 
+   
      • Constant *getInitializer()
+ 
+     
        Returns the intial value for a GlobalVariable.  It is not legal
+     to call this method if there is no initializer.
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The Module class
+ 
      
+ 
+ 
      
+ 
+ 
      #include "llvm/Module.h"
       doxygen info:
+ Module Class
      
+ 
+ 
      The Module class represents the top level structure present in LLVM
+ programs.  An LLVM module is effectively either a translation unit of the
+ original program or a combination of several translation units merged by the
+ linker.  The Module class keeps track of a list of Functions, a list of GlobalVariables, and a SymbolTable.  Additionally, it contains a few
+ helpful member functions that try to make common operations easy.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Important Public Members of the Module class
+ 
      
+ 
+ 
      
+ 
+ 
        
+   
      • Module::Module(std::string name = "")
        • 
+ 
      
+ 
+ 
      Constructing a Module is easy. You can optionally
+ provide a name for it (probably based on the name of the translation unit).
      
+ 
+ 
        
+   
      • Module::iterator - Typedef for function list iterator
        
+     Module::const_iterator - Typedef for const_iterator.
        
+ 
+     begin(), end(), front(), back(),
+     size(), empty(), rbegin(), rend()
+ 
+     
        These are forwarding methods that make it easy to access the contents of
+     a Module object's Function
+     list.
        • 
+ 
+   
      • Module::FunctionListType &getFunctionList()
+ 
+     
         Returns the list of Functions.  This is
+     necessary to use when you need to update the list or perform a complex
+     action that doesn't have a forwarding method.
        
+ 
+     
        •  
+ 
      
+ 
+ 
      
+ 
+ 
        
+   
      • Module::giterator - Typedef for global variable list iterator
        
+ 
+     Module::const_giterator - Typedef for const_iterator.
        
+ 
+     gbegin(), gend(), gfront(), gback(),
+     gsize(), gempty(), grbegin(), grend()
+ 
+     
         These are forwarding methods that make it easy to access the contents of
+     a Module object's GlobalVariable list.
        • 
+ 
+   
      • Module::GlobalListType &getGlobalList()
+ 
+     
        Returns the list of GlobalVariables.  This is necessary to
+     use when you need to update the list or perform a complex action that
+     doesn't have a forwarding method.
        
+ 
+     
         
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
+ 
        
+   
      • Function *getFunction(const std::string
+   &Name, const FunctionType *Ty)
+ 
+     
        Look up the specified function in the Module SymbolTable. If it does not exist, return
+     null.
        • 
+ 
+   
      • Function *getOrInsertFunction(const
+   std::string &Name, const FunctionType *T)
+ 
+     
        Look up the specified function in the Module SymbolTable. If it does not exist, add an
+     external declaration for the function and return it.
        • 
+ 
+   
      • std::string getTypeName(const Type *Ty)
+ 
+     
        If there is at least one entry in the SymbolTable for the specified Type, return it.  Otherwise return the empty
+     string.
        • 
+ 
+   
      • bool addTypeName(const std::string &Name, const Type *Ty)
+ 
+     
        Insert an entry in the SymbolTable
+     mapping Name to Ty. If there is already an entry for this
+     name, true is returned and the SymbolTable is not modified.
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The Constant class and subclasses
+ 
      
+ 
+ 
      
+ 
+ 
      Constant represents a base class for different types of constants. It
+ is subclassed by ConstantBool, ConstantInt, ConstantSInt, ConstantUInt,
+ ConstantArray etc for representing the various types of Constants.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Important Public Methods
+ 
      
+ 
      
+ 
      
+ 
+ 
+ 
      Important Subclasses of Constant 
      
+ 
      
+ 
        
+   
      • ConstantSInt : This subclass of Constant represents a signed integer 
+   constant.
+     
          
+       
        • int64_t getValue() const: Returns the underlying value of
+       this constant. 
          • 
+     
        
+   
        • 
+   
      • ConstantUInt : This class represents an unsigned integer.
+     
          
+       
        • uint64_t getValue() const: Returns the underlying value of 
+       this constant. 
          • 
+     
        
+   
        • 
+   
      • ConstantFP : This class represents a floating point constant.
+     
          
+       
        • double getValue() const: Returns the underlying value of 
+       this constant. 
          • 
+     
        
+   
        • 
+   
      • ConstantBool : This represents a boolean constant.
+     
          
+       
        • bool getValue() const: Returns the underlying value of this 
+       constant. 
          • 
+     
        
+   
        • 
+   
      • ConstantArray : This represents a constant array.
+     
          
+       
        • const std::vector<Use> &getValues() const: Returns 
+       a Vecotr of component constants that makeup this array. 
          • 
+     
        
+   
        • 
+   
      • ConstantStruct : This represents a constant struct.
+     
          
+       
        • const std::vector<Use> &getValues() const: Returns 
+       a Vector of component constants that makeup this array. 
          • 
+     
        
+   
        • 
+   
      • GlobalValue : This represents either a global variable or a function. In 
+   either case, the value is a constant fixed address (after linking). 
+   
        • 
+ 
      
+ 
      
+ 
+ 
+ 
      
+   The Type class and Derived Types
+ 
      
+ 
+ 
      
+ 
+ 
      Type as noted earlier is also a subclass of a Value class.  Any primitive
+ type (like int, short etc) in LLVM is an instance of Type Class.  All other
+ types are instances of subclasses of type like FunctionType, ArrayType
+ etc. DerivedType is the interface for all such dervied types including
+ FunctionType, ArrayType, PointerType, StructType. Types can have names. They can
+ be recursive (StructType).  There exists exactly one instance of any type
+ structure at a time. This allows using pointer equality of Type *s for comparing
+ types.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Important Public Methods
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
+   
      • bool isSigned() const: Returns whether an integral numeric type
+   is signed. This is true for SByteTy, ShortTy, IntTy, LongTy. Note that this is
+   not true for Float and Double. 
        • 
+ 
+   
      • bool isUnsigned() const: Returns whether a numeric type is
+   unsigned. This is not quite the complement of isSigned... nonnumeric types
+   return false as they do with isSigned. This returns true for UByteTy,
+   UShortTy, UIntTy, and ULongTy. 
        • 
+ 
+   
      • bool isInteger() const: Equivalent to isSigned() || isUnsigned().
        • 
+ 
+   
      • bool isIntegral() const: Returns true if this is an integral
+   type, which is either Bool type or one of the Integer types.
        • 
+ 
+   
      • bool isFloatingPoint(): Return true if this is one of the two
+   floating point types.
        • 
+ 
+   
      • isLosslesslyConvertableTo (const Type *Ty) const: Return true if
+   this type can be converted to 'Ty' without any reinterpretation of bits. For
+   example, uint to int or one pointer type to another.
        • 
+ 
      
+ 
      
+ 
+ 
+ 
      
+   Important Derived Types
+ 
      
+ 
      
+ 
        
+   
      • SequentialType : This is subclassed by ArrayType and PointerType
+     
          
+       
        • const Type * getElementType() const: Returns the type of each
+       of the elements in the sequential type. 
          • 
+     
        
+   
        • 
+   
      • ArrayType : This is a subclass of SequentialType and defines interface for
+   array types.
+     
          
+       
        • unsigned getNumElements() const: Returns the number of 
+       elements in the array. 
          • 
+     
        
+   
        • 
+   
      • PointerType : Subclass of SequentialType for  pointer types. 
        • 
+   
      • StructType : subclass of DerivedTypes for struct types 
        • 
+   
      • FunctionType : subclass of DerivedTypes for function types.
+     
          
+       
        • bool isVarArg() const: Returns true if its a vararg
+       function
          • 
+       
        •  const Type * getReturnType() const: Returns the
+       return type of the function.
          • 
+       
        • const Type * getParamType (unsigned i): Returns
+       the type of the ith parameter.
          • 
+       
        •  const unsigned getNumParams() const: Returns the
+       number of formal parameters.
          • 
+     
        
+   
        • 
+ 
      
+ 
      
+ 
+ 
+ 
      
+   The Argument class
+ 
      
+ 
+ 
      
+ 
+ 
      This subclass of Value defines the interface for incoming formal
+ arguments to a function. A Function maitanis a list of its formal
+ arguments. An argument has a pointer to the parent Function.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The SymbolTable class
+ 
      
+ 
      
+ 
      This class provides a symbol table that the
+ Function and 
+ Module classes use for naming definitions. The symbol table can 
+ provide a name for any Value or 
+ Type.  SymbolTable is an abstract data 
+ type. It hides the data it contains and provides access to it through a 
+ controlled interface.
      
+ 
+ 
      To use the SymbolTable well, you need to understand the 
+ structure of the information it holds. The class contains two 
+ std::map objects. The first, pmap, is a map of 
+ Type* to maps of name (std::string) to Value*. 
+ The second, tmap, is a map of names to Type*. Thus, Values
+ are stored in two-dimensions and accessed by Type and name. Types,
+ however, are stored in a single dimension and accessed only by name.
      
+ 
+ 
      The interface of this class provides three basic types of operations:
+ 
        
+   
      1. Accessors. Accessors provide read-only access to information
+   such as finding a value for a name with the 
+   lookup method.
        2.  
+   
      2. Mutators. Mutators allow the user to add information to the
+   SymbolTable with methods like 
+   insert.
        3. 
+   
      3. Iterators. Iterators allow the user to traverse the content
+   of the symbol table in well defined ways, such as the method
+   type_begin.
        4. 
+ 
      
+ 
+ 
      Accessors
      
+ 
      
+   
      Value* lookup(const Type* Ty, const std::string& name) const:
+   
      
+   
      The lookup method searches the type plane given by the
+   Ty parameter for a Value with the provided name.
+   If a suitable Value is not found, null is returned.
      
+ 
+   
      Type* lookupType( const std::string& name) const:
      
+   
      The lookupType method searches through the types for a
+   Type with the provided name. If a suitable Type
+   is not found, null is returned.
      
+ 
+   
      bool hasTypes() const:
      
+   
      This function returns true if an entry has been made into the type
+   map.
      
+ 
+   
      bool isEmpty() const:
      
+   
      This function returns true if both the value and types maps are
+   empty
      
+ 
+   
      std::string get_name(const Value*) const:
      
+   
      This function returns the name of the Value provided or the empty
+   string if the Value is not in the symbol table.
       
+ 
+   
      std::string get_name(const Type*) const:
      
+   
      This function returns the name of the Type provided or the empty
+   string if the Type is not in the symbol table.
      
+ 
      
+ 
+ 
      Mutators
      
+ 
      
+   
      void insert(Value *Val):
      
+   
      This method adds the provided value to the symbol table.  The Value must
+   have both a name and a type which are extracted and used to place the value
+   in the correct type plane under the value's name.
      
+ 
+   
      void insert(const std::string& Name, Value *Val):
      
+   
       Inserts a constant or type into the symbol table with the specified
+   name. There can be a many to one mapping between names and constants
+   or types.
      
+ 
+   
      void insert(const std::string& Name, Type *Typ):
      
+   
       Inserts a type into the symbol table with the specified name. There
+   can be a many-to-one mapping between names and types. This method
+   allows a type with an existing entry in the symbol table to get
+   a new name.
      
+ 
+   
      void remove(Value* Val):
      
+  
       This method removes a named value from the symbol table. The
+   type and name of the Value are extracted from \p N and used to
+   lookup the Value in the correct type plane. If the Value is
+   not in the symbol table, this method silently ignores the
+   request.
      
+ 
+   
      void remove(Type* Typ):
      
+   
       This method removes a named type from the symbol table. The
+   name of the type is extracted from \P T and used to look up
+   the Type in the type map. If the Type is not in the symbol
+   table, this method silently ignores the request.
      
+ 
+   
      Value* remove(const std::string& Name, Value *Val):
      
+   
       Remove a constant or type with the specified name from the 
+   symbol table.
      
+ 
+   
      Type* remove(const std::string& Name, Type* T):
      
+   
       Remove a type with the specified name from the symbol table.
+   Returns the removed Type.
      
+ 
+   
      Value *value_remove(const value_iterator& It):
      
+   
       Removes a specific value from the symbol table. 
+   Returns the removed value.
      
+ 
+   
      bool strip():
      
+   
       This method will strip the symbol table of its names leaving
+   the type and values. 
      
+ 
+   
      void clear():
      
+   
      Empty the symbol table completely.
      
+ 
      
+ 
+ 
      Iteration
      
+ 
      The following functions describe three types of iterators you can obtain
+ the beginning or end of the sequence for both const and non-const. It is
+ important to keep track of the different kinds of iterators. There are
+ three idioms worth pointing out:
      
+ 
+   
+   
+     
+     
+   
+   
+     
+     
+   
+   
+     
+     
+   
+ 
      UnitsIteratorIdiom
      Planes Of name/Value mapsPI
      
+ for (SymbolTable::plane_const_iterator PI = ST.plane_begin(),
+      PE = ST.plane_end(); PI != PE; ++PI ) {
+   PI->first // This is the Type* of the plane
+   PI->second // This is the SymbolTable::ValueMap of name/Value pairs
+     
      All name/Type PairsTI
      
+ for (SymbolTable::type_const_iterator TI = ST.type_begin(),
+      TE = ST.type_end(); TI != TE; ++TI )
+   TI->first  // This is the name of the type
+   TI->second // This is the Type* value associated with the name
+     
      name/Value pairs in a planeVI
      
+ for (SymbolTable::value_const_iterator VI = ST.value_begin(SomeType),
+      VE = ST.value_end(SomeType); VI != VE; ++VI )
+   VI->first  // This is the name of the Value
+   VI->second // This is the Value* value associated with the name
+     
      
+ 
+ 
      Using the recommended iterator names and idioms will help you avoid
+ making mistakes. Of particular note, make sure that whenever you use
+ value_begin(SomeType) that you always compare the resulting iterator
+ with value_end(SomeType) not value_end(SomeOtherType) or else you 
+ will loop infinitely.
      
+ 
+ 
      
+ 
+   
      plane_iterator plane_begin():
      
+   
      Get an iterator that starts at the beginning of the type planes.
+   The iterator will iterate over the Type/ValueMap pairs in the
+   type planes. 
      
+ 
+   
      plane_const_iterator plane_begin() const:
      
+   
      Get a const_iterator that starts at the beginning of the type 
+   planes.  The iterator will iterate over the Type/ValueMap pairs 
+   in the type planes. 
      
+ 
+   
      plane_iterator plane_end():
      
+   
      Get an iterator at the end of the type planes. This serves as
+   the marker for end of iteration over the type planes.
      
+ 
+   
      plane_const_iterator plane_end() const:
      
+   
      Get a const_iterator at the end of the type planes. This serves as
+   the marker for end of iteration over the type planes.
      
+ 
+   
      value_iterator value_begin(const Type *Typ):
      
+   
      Get an iterator that starts at the beginning of a type plane.
+   The iterator will iterate over the name/value pairs in the type plane.
+   Note: The type plane must already exist before using this.
      
+ 
+   
      value_const_iterator value_begin(const Type *Typ) const:
      
+   
      Get a const_iterator that starts at the beginning of a type plane.
+   The iterator will iterate over the name/value pairs in the type plane.
+   Note: The type plane must already exist before using this.
      
+ 
+   
      value_iterator value_end(const Type *Typ):
      
+   
      Get an iterator to the end of a type plane. This serves as the marker
+   for end of iteration of the type plane.
+   Note: The type plane must already exist before using this.
      
+ 
+   
      value_const_iterator value_end(const Type *Typ) const:
      
+   
      Get a const_iterator to the end of a type plane. This serves as the
+   marker for end of iteration of the type plane.
+   Note: the type plane must already exist before using this.
      
+ 
+   
      type_iterator type_begin():
      
+   
      Get an iterator to the start of the name/Type map.
      
+ 
+   
      type_const_iterator type_begin() cons:
      
+   
       Get a const_iterator to the start of the name/Type map.
      
+ 
+   
      type_iterator type_end():
      
+   
      Get an iterator to the end of the name/Type map. This serves as the
+   marker for end of iteration of the types.
      
+ 
+   
      type_const_iterator type_end() const:
      
+   
      Get a const-iterator to the end of the name/Type map. This serves 
+   as the marker for end of iteration of the types.
      
+ 
+   
      plane_const_iterator find(const Type* Typ ) const:
      
+   
      This method returns a plane_const_iterator for iteration over
+   the type planes starting at a specific plane, given by \p Ty.
      
+ 
+   
      plane_iterator find( const Type* Typ :
      
+   
      This method returns a plane_iterator for iteration over the
+   type planes starting at a specific plane, given by \p Ty.
      
+ 
+   
      const ValueMap* findPlane( const Type* Typ ) cons:
      
+   
      This method returns a ValueMap* for a specific type plane. This
+   interface is deprecated and may go away in the future.
      
+ 
      
+ 
      
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Dinakar Dhurjati and
+   Chris Lattner
      
+   The LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/Projects.html
diff -c /dev/null llvm-www/releases/1.4/docs/Projects.html:1.1
*** /dev/null	Thu Dec  9 16:19:07 2004
--- llvm-www/releases/1.4/docs/Projects.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,450 ----
+ 
+ 
+ 
+   Creating an LLVM Project
+   
+ 
+ 
+ 
+ 
      Creating an LLVM Project
      
+ 
+ 
        
+ 
      1. Overview
        2. 
+ 
      2. Create a project from the Sample Project
        3. 
+ 
      3. Source tree layout
        4. 
+ 
      4. Writing LLVM-style Makefiles
+   
          
+   
        1. Required Variables
          2. 
+   
        2. Variables for Building Subdirectories
          3. 
+   
        3. Variables for Building Libraries
          4. 
+   
        4. Variables for Building Programs
          5. 
+   
        5. Miscellaneous Variables
          6. 
+   
        5. 
+ 
      5. Placement of object code
        6. 
+ 
      6. Further help
        7. 
+ 
      
+ 
+ 
      
+   
      Written by John Criswell
      
+ 
      
+ 
+ 
+ 
      Overview
      
+ 
+ 
+ 
      
+ 
+ 
      The LLVM build system is designed to facilitate the building of third party
+ projects that use LLVM header files, libraries, and tools.  In order to use
+ these facilities, a Makefile from a project must do the following things:
      
+ 
+ 
        
+ 
      1. Set environment variables.There are several environment variables that a
+ Makefile needs to set to use the LLVM build system:
+ 
+ 
          
+   
        • LLVM_SRC_ROOT - The root of the LLVM source tree.
          • 
+   
        • LLVM_OBJ_ROOT - The root of the LLVM object tree.
          • 
+   
        • BUILD_SRC_ROOT - The root of the project's source tree.
          • 
+   
        • BUILD_OBJ_ROOT - The root of the project's object tree.
          • 
+   
        • BUILD_SRC_DIR - The directory containing the current source to be
+   compiled.
          • 
+   
        • BUILD_OBJ_DIR - The directory where the current source will place
+   the new object files.  This should always be the current directory.
          • 
+   
        • LEVEL - The relative path from the current directory to the root
+   of the object tree.
          • 
+ 
        2. 
+ 
      2. Include Makefile.config from $(LLVM_OBJ_ROOT).
        3. 
+ 
      3. Include Makefile.rules from $(LLVM_SRC_ROOT).
        4. 
+ 
      
+ 
+ 
      There are two ways that you can set all of these variables:
      
+ 
+ 
        
+ 
      1. You can write your own Makefiles which hard-code these values.
        2. 
+ 
+ 
      2.  You can use the pre-made LLVM sample project.  This sample project includes
+ Makefiles, a configure script that can be used to configure the location of
+ LLVM, and the ability to support multiple object directories from a single
+ source directory.
        3. 
+ 
      
+ 
+ 
      This document assumes that you will base your project off of the LLVM sample
+ project found in llvm/projects/sample.  If you want to devise your own
+ build system, studying the sample project and LLVM Makefiles will probably
+ provide enough information on how to write your own Makefiles.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Create a Project from the Sample Project
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      Follow these simple steps to start your project:
      
+ 
+ 
        
+ 
      1. Copy the llvm/projects/sample directory to any place of your
+ choosing.  You can place it anywhere you like.  Rename the directory to match
+ the name of your project.
        2. 
+ 
+ 
      2. Add your source code and Makefiles to your source tree.
        3. 
+ 
+ 
      3. If you want your Makefiles to be configured by the configure
+ script, or if you want to support multiple object directories, add your
+ Makefiles to the configure script by adding them into the
+ autoconf/configure.ac file.  The macro AC_CONFIG_MAKEFILE will
+ copy a file, unmodified, from the source directory to the object directory.
        4. 
+ 
+ 
      4. After updating autoconf/configure.ac, regenerate the
+ configure script with these commands:
+ 
+ 
        
+ 
        % cd autoconf
        
+        % autoconf -o ../configure
        
+ 
        
+ 
+ 
        You must be using Autoconf version 2.57 or higher.
        5. 
+ 
+ 
      5. Run configure in the directory in which you want to place
+ object code.  Use the following options to tell your project where it
+ can find LLVM:
+ 
+   
        
+     
        --with-llvmsrc=<directory>
+     
        
+     Tell your project where the LLVM source tree is located.
+     
        
+     
        --with-llvmobj=<directory>
+     
        
+     Tell your project where the LLVM object tree is located.
+   
        
+ 
      
+ 
+ 
      That's it!  Now all you have to do is type gmake in the root of
+ your object directory, and your project should build.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Source Tree Layout
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      In order to use the LLVM build system, you will want to organize your
+ source code so that it can benefit from the build system's features.
+ Mainly, you want your source tree layout to look similar to the LLVM
+ source tree layout.  The best way to do this is to just copy the
+ project tree from llvm/projects/sample and modify it to meet
+ your needs, but you can certainly add to it if you want.
      
+ 
+ 
      Underneath your top level directory, you should have the following
+ directories:
      
+ 
+ 
      
+   
      lib
+   
      
+   This subdirectory should contain all of your library source
+   code.  For each library that you build, you will have one
+   directory in lib that will contain that library's source
+   code.
+ 
+   
      
+   Libraries can be object files, archives, or dynamic libraries.
+   The lib directory is just a convenient place for libraries
+   as it places them all in a directory from which they can be linked
+   later.
+ 
+   
      include
+   
      
+   This subdirectory should contain any header files that are
+   global to your project.  By global, we mean that they are used
+   by more than one library or executable of your project.
+   
      
+   By placing your header files in include, they will be
+   found automatically by the LLVM build system.  For example, if
+   you have a file include/jazz/note.h, then your source
+   files can include it simply with #include "jazz/note.h".
+ 
+   
      tools
+   
      
+   This subdirectory should contain all of your source
+   code for executables.  For each program that you build, you
+   will have one directory in tools that will contain that
+   program's source code.
+   
      
+ 
+   
      test
+   
      
+   This subdirectory should contain tests that verify that your code
+   works correctly.  Automated tests are especially useful.
+   
      
+   Currently, the LLVM build system provides basic support for tests.
+   The LLVM system provides the following:
+   
        
+     
      • 
+     LLVM provides a tcl procedure that is used by Dejagnu to run
+     tests.  It can be found in llvm/lib/llvm-dg.exp.  This
+     test procedure uses RUN lines in the actual test case to determine
+     how to run the test.  See the TestingGuide for more details. You
+     can easily write Makefile support similar to the Makefiles in llvm/test
+     to use Dejagnu to run your project's tests.
        • 
+ 
+     
        
+ 
+     
      • 
+     LLVM contains an optional package called llvm-test
+     which provides benchmarks and programs that are known to compile with the
+     LLVM GCC front ends.  You can use these
+     programs to test your code, gather statistics information, and
+     compare it to the current LLVM performance statistics.
+     
        
+     Currently, there is no way to hook your tests directly into the
+     llvm/test testing harness.  You will simply
+     need to find a way to use the source provided within that directory
+     on your own.
+   
      
+ 
      
+ 
+ 
      Typically, you will want to build your lib directory first followed by
+ your tools directory.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Writing LLVM Style Makefiles
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      The LLVM build system provides a convenient way to build libraries and
+ executables.  Most of your project Makefiles will only need to define a few
+ variables.  Below is a list of the variables one can set and what they can
+ do:
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Required Variables
+ 
      
+ 
+ 
      
+ 
+ 
      
+   
      LEVEL
+   
      
+   This variable is the relative path from this Makefile to the
+   top directory of your project's source code.  For example, if
+   your source code is in /tmp/src, then the Makefile in
+   /tmp/src/jump/high would set LEVEL to "../..".
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Variables for Building Subdirectories
+ 
      
+ 
+ 
      
+ 
+ 
      
+   
      DIRS
+   
      
+   This is a space separated list of subdirectories that should be
+   built.  They will be built, one at a time, in the order
+   specified.
+   
      
+ 
+   
      PARALLEL_DIRS
+   
      
+   This is a list of directories that can be built in parallel.
+   These will be built after the directories in DIRS have been
+   built.
+   
      
+ 
+   
      OPTIONAL_DIRS
+   
      
+   This is a list of directories that can be built if they exist,
+   but will not cause an error if they do not exist.  They are
+   built serially in the order in which they are listed.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Variables for Building Libraries
+ 
      
+ 
+ 
      
+ 
+ 
      
+   
      LIBRARYNAME
+   
      
+   This variable contains the base name of the library that will
+   be built.  For example, to build a library named
+   libsample.a, LIBRARYNAME should be set to
+   sample.
+   
      
+ 
+   
      BUILD_ARCHIVE
+   
      
+   By default, a library is a .o file that is linked
+   directly into a program.  To build an archive (also known as
+   a static library), set the BUILD_ARCHIVE variable.
+   
      
+ 
+   
      SHARED_LIBRARY
+   
      
+   If SHARED_LIBRARY is defined in your Makefile, a shared
+   (or dynamic) library will be built.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Variables for Building Programs
+ 
      
+ 
+ 
      
+ 
+ 
      
+   
      TOOLNAME
+   
      
+   This variable contains the name of the program that will
+   be built.  For example, to build an executable named
+   sample, TOOLNAME should be set to sample.
+   
      
+ 
+   
      USEDLIBS
+   
      
+   This variable holds a space separated list of libraries that
+   should be linked into the program.  These libraries must either
+   be LLVM libraries or libraries that come from your lib
+   directory.  The libraries must be specified by their base name.
+   For example, to link libsample.a, you would set USEDLIBS to
+   sample.
+   
      
+   Note that this works only for statically linked libraries.
+   
      
+ 
+   
      LIBS
+   
      
+   To link dynamic libraries, add -l<library base name> to
+   the LIBS variable.  The LLVM build system will look in the same places
+   for dynamic libraries as it does for static libraries.
+   
      
+   For example, to link libsample.so, you would have the
+   following line in your Makefile:
+   
      
+   
+   LIBS += -lsample
+   
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Miscellaneous Variables
+ 
      
+ 
+ 
      
+ 
+ 
      
+   
      ExtraSource
+   
      
+   This variable contains a space separated list of extra source
+   files that need to be built.  It is useful for including the
+   output of Lex and Yacc programs.
+   
      
+ 
+   
      CFLAGS
+   
      CPPFLAGS
+   
      
+   This variable can be used to add options to the C and C++
+   compiler, respectively.  It is typically used to add options
+   that tell the compiler the location of additional directories
+   to search for header files.
+   
      
+   It is highly suggested that you append to CFLAGS and CPPFLAGS as
+   opposed to overwriting them.  The master Makefiles may already
+   have useful options in them that you may not want to overwrite.
+   
      
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Placement of Object Code
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      The final location of built libraries and executables will depend upon
+ whether you do a Debug, Release, or Profile build.
      
+ 
+ 
      
+   
      Libraries
+   
      
+   All libraries (static and dynamic) will be stored in
+   BUILD_OBJ_ROOT/lib/<type>, where type is Debug,
+   Release, or Profile for a debug, optimized, or
+   profiled build, respectively.
      
+ 
+   
      Executables
+   
      All executables will be stored in
+   BUILD_OBJ_ROOT/tools/<type>, where type is Debug,
+   Release, or Profile for a debug, optimized, or profiled
+   build, respectively.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Further Help
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      If you have any questions or need any help creating an LLVM project,
+ the LLVM team would be more than happy to help.  You can always post your
+ questions to the LLVM Developers
+ Mailing List.
      
+ 
+ 
      
+   
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   John Criswell
      
+   The LLVM Compiler Infrastructure
+   
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/ReleaseNotes.html
diff -c /dev/null llvm-www/releases/1.4/docs/ReleaseNotes.html:1.1
*** /dev/null	Thu Dec  9 16:19:07 2004
--- llvm-www/releases/1.4/docs/ReleaseNotes.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,738 ----
+ 
+ 
+ 
+   
+   
+   LLVM 1.4 Release Notes
+ 
+ 
+ 
+ 
      LLVM 1.4 Release Notes
      
+  
+ 
        
+   
      1. Introduction
        2. 
+   
      2. What's New?
        3. 
+   
      3. Installation Instructions
        4. 
+   
      4. Portability and Supported Platforms
        5. 
+   
      5. Known Problems
+   
        6. 
+   
      6. Additional Information
        7. 
+ 
      
+ 
+ 
      
+   
      Written by the LLVM team
      
+ 
      
+ 
+ 
+ 
      
+   Introduction
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      This document contains the release notes for the LLVM compiler
+ infrastructure, release 1.4.  Here we describe the status of LLVM, including any
+ known problems and improvements from the previous release.  The most up-to-date
+ version of this document can be found on the LLVM 1.4 web site.  If you are
+ not reading this on the LLVM web pages, you should probably go there because
+ this document may be updated after the release.
      
+ 
+ 
      For more information about LLVM, including information about the latest
+ release, please check out the main LLVM
+ web site.  If you have questions or comments, the LLVM developer's mailing
+ list is a good place to send them.
      
+ 
+ 
      Note that if you are reading this file from CVS, this document applies
+ to the next release, not the current one.  To see the release notes for
+ the current or previous releases, see the releases page.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   What's New?
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      This is the fifth public release of the LLVM compiler infrastructure.
      
+ 
+ 
       At this time, LLVM is known to correctly compile on a broad range of
+ C and C++ programs, including the SPEC CPU95 & 2000 suite.  This release
+ includes several major enhancements to the LLVM system, including a new 
+ PowerPC JIT, enhancements to the C/C++ front-end to provide source line number
+ information in LLVM, a new compiler
+ driver, and several other enhancements listed below.  It also includes
+ bug fixes for those problems found since the 1.3 release.
      
+ 
+ 
      Note that this release seperates the LLVM Program Testsuite out of the 
+ main LLVM distribution into a seperate CVS repository and tarball.  This
+ reduces the size of the main LLVM distribution.  Also note that LLVM now
+ builds tools into llvm/Debug/bin by default instead of llvm/tools/Debug.
      
+ 
+ 
      
+ 
+ 
+ 
      
+ This release implements the following new features:
+ 
      
+ 
+ 
      
+ 
        
+   
      1. LLVM now includes a Just-In-Time compiler for the PowerPC target.
        2. 
+   
      2. llvmgcc and llvmg++ now emit source line number information when '-g' is
+   passed in, making it possible to map from LLVM code back to source.
+   This information is currently used by llvm-db and can be used with other 
+   tools and passes.
        3. 
+   
      3. The test/Programs hierarchy has
+     been moved out of the main LLVM tree into a separate CVS repository and
+     tarball. This shrinks the distribution size of LLVM itself significantly.
+   
        4. 
+   
      4. LLVM now optimizes global variables more aggressively than it did 
+   before.
        5. 
+   
      5. LLVM now includes the new 'undef' value and 
+   unreachable instruction,
+   which give the optimizer more information about the behavior of the
+   program.
+   
        6. 
+   
      6. Bytecode compression with bzip2 has been implemented. All bytecode files
+   generated by LLVM will now be compressed by default. Compression can be 
+   disabled with the -disable-compression option to the tools that can 
+   generate bytecode files.
+   
        7. 
+   
      7. A generic compiler driver
+   (llvmc) and
+   an associated generic linker
+   (llvm-ld) have been added. The compiler driver is generic because it can be
+   configured
+   to pre-process, translate, optimize, assemble, and link code from any source
+   language with an LLVM front-end. This makes it easier for compiler writers
+   to hide the multiple steps required to compile a program (compiling,
+   optimizing, linking runtime libraries, etc) in one simple command.
+   
        8. 
+   
      8. The dependent libraries 
+   feature has been implemented. This allows front end compilers to indicate in
+   the bytecode which libraries the bytecode needs to be linked with. Both the
+   C/C++ and Stacker front ends support generating the required dependencies. 
+   The linker now supports using this information to ensure required libaries are
+   linked into the module. This minimizes the need to use the -l option
+   when using llvmc.
+   
        9. 
+   
      9. The LLVM makefiles have been improved to build LLVM much faster and 
+   includes new targets (like dist-check, uninstall). One important user-visible
+   change is that libraries and tools will now be built into 
+   $builddir/Debug/{bin,lib}
+   instead of $builddir/tools/Debug and $builddir/lib/Debug
+   (Similarly for Release and Profile builds).
+   
        10. 
+   
      10. The LLVM source code is much more compatible with Microsoft Visual C++,
+   including the JIT and runtime-code generation, though the entire system 
+   may not work with it.
+   
        11. 
+   
      11. The JIT-Target interfaces are 
+     now much simpler and more powerful.
+   
        12. 
+   
      12. LLVM now provides llvm-ar and llvm-ranlib tools for working with archives
+       of LLVM bytecode files.
        13. 
+   
      13. zlib and libpng are no longer
+       included in the main LLVM tarball.
        14. 
+   
      14. The LLVM code generator now automatically generates assembly code writers
+       from an abstract target descriptions, eliminating the need to write
+       assembly printers manually.
        15. 
+   
      15. LLVM regression and feature tests now use DejaGNU instead of QMTest.
        16. 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ In this release, the following missing features were implemented:
+ 
      
+ 
+ 
      
+ 
+ 
        
+   
      1. JIT interface should support
+     arbitrary calls
+   
        2. 
+   
      2. The llvm-ar tool was previously incomplete and didn't properly
+   support other ar(1) implementations. This has been corrected. llvm-ar
+   now fully supports all archive editing functions, table of contents listing,
+   extraction, and printing. It can also read BSD4.4/MacOSX and SVR4 style 
+   archives. See llvm-ar for 
+   details.
+   
        3. 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+ In this release, the following Quality of Implementation
+ issues were fixed:
+ 
      
+ 
+ 
      
+ 
+ 
        
+   
      1. The linker no longer emits many
+       useless warnings when linking C++ programs.
+   
        2. 
+   
      2. The LLVM #include namespace
+       has been made consistent.  Files in llvm/include/{Support,Config}
+       are now located in llvm/include/llvm/{Support,Config}.
+   
        3. 
+   
      3. The names of the libraries generated by compiling LLVM source have been 
+   changed to ensure they do not conflict with other packages upon installation.
+   Each LLVM library is now prefixed with LLVM and uses mixed clase. For example,
+   the library libasmparser.a in 1.3 has become
+   libLLVMAsmParser.a in release 1.4.
+   
        4. 
+   
      4. The C++ frontend no longer expands and emits all inline functions, even if they
+       are unused.  It now properly tracks which functions are needed and
+       only compiles those.
        5. 
+ 
+   
      5. Many improvements in the autoconf
+       and makefile systems have been implemented.
        6. 
+ 
      
+ 
      
+ 
+ 
+ 
      
+ This release includes the following Code Quality
+ improvements:
+ 
      
+ 
+ 
      
+ 
        
+   
      1. The optimizer produces more 
+       efficient code for std::min/std::max and other similar functions.
        2. 
+   
      2. The X86 backend generates substantially faster code for floating point
+       intensive programs.
        3. 
+   
      3. The PowerPC backend generates more efficient code in many common
+       scenarios.
        4. 
+ 
      
+ 
      
+ 
+ 
+ 
      
+ In this release, the following bugs in the previous release
+ were fixed:
+ 
      
+ 
+ 
      
+ 
+ 
      Bugs fixed in the LLVM Core:
      
+ 
+ 
        
+   
      1. [licm] LICM invalidates alias 
+     analysis info and uses broken information (optimizer crash)
        2. 
+   
      2. [asmwriter] Asmwriter is really 
+     slow for functions with lots of values
        3. 
+   
      3. [anders-aa] Andersen's AA is 
+     completely broken in LLVM 1.3
        4. 
+   
      4. [bcwriter] Empty compaction 
+     tables defined
        5. 
+   
      5. [X86] llc output for functions 
+     w/certain names tickles GNU 'as' bugs
        6. 
+   
      6. [cbackend] Static globals are 
+       prototyped as 'extern'
        7. 
+ 
      
+ 
+ 
      Bugs in the C/C++ front-end:
      
+ 
+ 
        
+   
      1. [llvmg++] not enough templates are
+     instantiated
        2. 
+   
      2. [llvmg++] Extern const globals 
+     cannot be marked 'constant' if they have nontrivial ctors or dtors
        3. 
+   
      3. [llvmgcc] Crash compiling unnamed 
+     bitfield which does not increase struct size
        4. 
+   
      4. [llvmgcc] llvmgcc emits invalid 
+     constant exprs
        5. 
+   
      5. [llvmg++] Crash initializing 
+     array with constructors in hard EH situations
        6. 
+   
      6. [llvm-gcc] Inline function 
+     redefinitions error due to 'asm' function rename
        7. 
+   
      7. [llvm-gcc] Error when an 
+     implicitly external function is re-declared as static
        8. 
+   
      8. [llvmgcc] Structure field with 
+     non-constant offset crashes llvmgcc
        9. 
+   
      9. [llvmg++] Crash compiling 
+     friend with default argument
        10. 
+ 
      
+ 
+ 
      Bugs fixed in the Sparc V9 back-end:
      
+ 
+ 
        
+   
      1. [sparcv9] regalloc assertion
+     failure with certain indirect calls
        2. 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Portability and Supported Platforms
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      LLVM is known to work on the following platforms:
      
+ 
+ 
        
+ 
      • Intel and AMD machines running Red Hat Linux and FreeBSD (and probably 
+     other unix-like systems).
        • 
+ 
      • Sun UltraSPARC workstations running Solaris 8.
        • 
+ 
      • Intel and AMD machines running on Win32 with the Cygwin libraries (limited
+     support is available for native builds with Visual C++).
        • 
+ 
      • PowerPC-based Mac OS X systems, running 10.2 and above.
        • 
+ 
      
+ 
+ 
      The core LLVM infrastructure uses
+ GNU autoconf to adapt itself
+ to the machine and operating system on which it is built.  However, minor
+ porting may be required to get LLVM to work on new platforms.  We welcome your
+ portability patches and reports of successful builds or error messages.
      
+ 
+ 
+ 
+ 
      
+ 
+ 
+ 
      
+   Known Problems
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      This section contains all known problems with the LLVM system, listed by
+ component.  As new problems are discovered, they will be added to these
+ sections.  If you run into a problem, please check the LLVM bug database and submit a bug if
+ there isn't already one.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Experimental features included with this release
+ 
      
+ 
+ 
      
+ 
+ 
      The following components of this LLVM release are either untested, known to
+ be broken or unreliable, or are in early development.  These components should
+ not be relied on, and bugs should not be filed against them, but they may be
+ useful to some people.  In particular, if you would like to work on one of these
+ components, please contact us on the llvmdev list.
      
+ 
+ 
        
+ 
      • The following passes are incomplete or buggy, and may be removed in future
+     releases: -pgmdep, -memdep, -ipmodref, -cee, -branch-combine,
+     -instloops, -paths, -pre
        • 
+ 
      • The llvm-db tool is in a very early stage of development, but can
+     be used to step through programs and inspect the stack.
        • 
+ 
      • The "iterative scan" register allocator (enabled with -regalloc=iterativescan)
+     is not stable.
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Known problems with the LLVM Build
+ 
      
+ 
+ 
      
+ 
+ 
        
+   
      • 
+   On some platforms, flex and bison may generate warnings.  Usually, these can
+   be safely ignored.
+   
        • 
+ 
      
+ 
+ 
+ 
      
+   Known problems with the LLVM Core
+ 
      
+ 
+ 
      
+ 
+ 
        
+   
      • In the JIT, dlsym on a symbol compiled by the JIT will not work.
+   
        • 
+   
      • The JIT does not use mutexes to protect its internal data structures. As
+   such, execution of a threaded program could cause these data structures to be
+   corrupted.
+   
        • 
+   
      • The lower-invoke pass does not 
+     mark values live across a setjmp as volatile. This missing feature 
+   only affects targets whose setjmp/longjmp libraries do not save and restore 
+   the entire register file.
        • 
+ 
      
+ 
      
+ 
+ 
+ 
      
+   Known problems with the C front-end
+ 
      
+ 
+ 
+ 
      Bugs
      
+ 
+ 
      
+ 
        
+ 
      • C99 Variable sized arrays do not release stack memory when they go out of 
+     scope.  Thus, the following program may run out of stack space:
+ 
        +     for (i = 0; i != 1000000; ++i) {
+       int X[n];
+       foo(X);
+     }
+ 
        • 
+ 
+ 
      • Initialization of global union variables can only be done with the largest union member.
        • 
+ 
+ 
      
+ 
      
+ 
+ 
+ 
      
+   Notes
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
+ 
      • Inline assembly is not yet supported.
        • 
+ 
+ 
      • "long double" is transformed by the front-end into "double".  There is no
+ support for floating point data types of any size other than 32 and 64
+ bits.
        • 
+     
+ 
      • The following Unix system functionality has not been tested and may not
+ work:
+   
          
+   
        1. sigsetjmp, siglongjmp - These are not turned into the
+       appropriate invoke/unwind instructions.  Note that
+       setjmp and longjmp are compiled correctly.
+   
        2. getcontext, setcontext, makecontext
+       - These functions have not been tested.
+   
        • 
+ 
+ 
      • Although many GCC extensions are supported, some are not.  In particular,
+     the following extensions are known to not be supported:
+   
          
+   
        1. Local Labels: Labels local to a block.
          2. 
+   
        2. Nested Functions: As in Algol and Pascal, lexical scoping of functions.
          3. 
+   
        3. Constructing Calls: Dispatching a call to another function.
          4. 
+   
        4. Extended Asm: Assembler instructions with C expressions as operands.
          5. 
+   
        5. Constraints: Constraints for asm operands.
          6. 
+   
        6. Asm Labels: Specifying the assembler name to use for a C symbol.
          7. 
+   
        7. Explicit Reg Vars: Defining variables residing in specified registers.
          8. 
+   
        8. Vector Extensions: Using vector instructions through built-in functions.
          9. 
+   
        9. Target Builtins:   Built-in functions specific to particular targets.
          10. 
+   
        10. Thread-Local: Per-thread variables.
          11. 
+   
        11. Pragmas: Pragmas accepted by GCC.
          12. 
+   
        
+ 
+   
        The following GCC extensions are partially supported.  An ignored
+   attribute means that the LLVM compiler ignores the presence of the attribute,
+   but the code should still work.  An unsupported attribute is one which is
+   ignored by the LLVM compiler and will cause a different interpretation of
+   the program.
        
+ 
+   
          
+   
        1. Variable Length:
+       Arrays whose length is computed at run time.
          
+       Supported, but allocated stack space is not freed until the function returns (noted above).
          2. 
+ 
+   
        2. Function Attributes:
+ 
+       Declaring that functions have no side effects or that they can never
+       return.
          
+ 
+       Supported: format, format_arg, non_null,
+       noreturn, constructor, destructor,
+       unused,
+       deprecated, warn_unused_result, weak
          
+ 
+       Ignored: noinline,
+       always_inline, pure, const, nothrow,
+       malloc, no_instrument_function, cdecl
          
+ 
+       Unsupported: used, section, alias,
+       visibility, regparm, stdcall,
+       fastcall, all other target specific attributes
          3. 
+    
+   
        3. Variable Attributes:
+       Specifying attributes of variables.
          
+       Supported: cleanup, common, nocommon,
+                         deprecated, transparent_union,
+                         unused, weak
          
+ 
+       Unsupported: aligned, mode, packed,
+                         section, shared, tls_model,
+                         vector_size, dllimport, 
+                         dllexport, all target specific attributes.
          4. 
+ 
+   
        4. Type Attributes:	Specifying attributes of types.
          
+       Supported: transparent_union, unused,
+                         deprecated, may_alias
          
+ 
+       Unsupported: aligned, packed, 
+                         all target specific attributes.
          5. 
+ 
+   
        5. Other Builtins:
+       Other built-in functions.
          
+       We support all builtins which have a C language equivalent (e.g., 
+          __builtin_cos),  __builtin_alloca, 
+          __builtin_types_compatible_p, __builtin_choose_expr,
+          __builtin_constant_p, and __builtin_expect
+          (currently ignored).  We also support builtins for ISO C99 floating
+          point comparison macros (e.g., __builtin_islessequal).
          6. 
+   
        
+ 
+   
        The following extensions are known to be supported:
        
+ 
+   
          
+   
        1. Labels as Values: Getting pointers to labels and computed gotos.
          2. 
+   
        2. Statement Exprs:   Putting statements and declarations inside expressions.
          3. 
+   
        3. Typeof: typeof: referring to the type of an expression.
          4. 
+   
        4. Lvalues: Using ?:, "," and casts in lvalues.
          5. 
+   
        5. Conditionals: Omitting the middle operand of a ?: expression.
          6. 
+   
        6. Long Long: Double-word integers.
          7. 
+   
        7. Complex:   Data types for complex numbers.
          8. 
+   
        8. Hex Floats:Hexadecimal floating-point constants.
          9. 
+   
        9. Zero Length: Zero-length arrays.
          10. 
+   
        10. Empty Structures: Structures with no members.
          11. 
+   
        11. Variadic Macros: Macros with a variable number of arguments.
          12. 
+   
        12. Escaped Newlines:  Slightly looser rules for escaped newlines.
          13. 
+   
        13. Subscripting: Any array can be subscripted, even if not an lvalue.
          14. 
+   
        14. Pointer Arith: Arithmetic on void-pointers and function pointers.
          15. 
+   
        15. Initializers: Non-constant initializers.
          16. 
+   
        16. Compound Literals: Compound literals give structures, unions,
+ or arrays as values.
          17. 
+   
        17. Designated Inits: Labeling elements of initializers.
          18. 
+   
        18. Cast to Union: Casting to union type from any member of the union.
          19. 
+   
        19. Case Ranges: `case 1 ... 9' and such.
          20. 
+   
        20. Mixed Declarations: Mixing declarations and code.
          21. 
+   
        21. Function Prototypes: Prototype declarations and old-style definitions.
          22. 
+   
        22. C++ Comments: C++ comments are recognized.
          23. 
+   
        23. Dollar Signs: Dollar sign is allowed in identifiers.
          24. 
+   
        24. Character Escapes: \e stands for the character <ESC>.
          25. 
+   
        25. Alignment: Inquiring about the alignment of a type or variable.
          26. 
+   
        26. Inline: Defining inline functions (as fast as macros).
          27. 
+   
        27. Alternate Keywords:__const__, __asm__, etc., for header files.
          28. 
+   
        28. Incomplete Enums:  enum foo;, with details to follow.
          29. 
+   
        29. Function Names: Printable strings which are the name of the current function.
          30. 
+   
        30. Return Address: Getting the return or frame address of a function.
          31. 
+   
        31. Unnamed Fields: Unnamed struct/union fields within structs/unions.
          32. 
+   
        32. Attribute Syntax: Formal syntax for attributes.
          33. 
+   
        • 
+ 
+ 
      
+ 
+ 
      If you run into GCC extensions which have not been included in any of these
+ lists, please let us know (also including whether or not they work).
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Known problems with the C++ front-end
+ 
      
+ 
+ 
      
+ 
+ 
      For this release, the C++ front-end is considered to be fully
+ tested and works for a number of non-trivial programs, including LLVM
+ itself.
      
+ 
+ 
      
+ 
+ 
+ 
      Bugs
      
+ 
+ 
      
+ 
+ 
        
+ 
      • The C++ front-end inherits all problems afflicting the C
+     front-end.
        • 
+ 
+ 
      • IA-64 specific: The C++ front-end does not use IA64 ABI compliant layout of v-tables.
+ In particular, it just stores function pointers instead of function
+ descriptors in the vtable.  This bug prevents mixing C++ code compiled with
+ LLVM with C++ objects compiled by other C++ compilers.
        • 
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Notes
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
+ 
      • The C++ front-end is based on a pre-release of the GCC 3.4 C++ parser.  This
+ parser is significantly more standards compliant (and picky) than prior GCC
+ versions.  For more information, see the C++ section of the GCC 3.4 release notes.
        • 
+ 
+ 
      • Destructors for local objects are not always run when a longjmp is
+     performed. In particular, destructors for objects in the longjmping
+     function and in the setjmp receiver function may not be run.
+     Objects in intervening stack frames will be destroyed, however (which is
+     better than most compilers).
        • 
+ 
+ 
      • The LLVM C++ front-end follows the Itanium C++ ABI.
+     This document, which is not Itanium specific, specifies a standard for name
+     mangling, class layout, v-table layout, RTTI formats, and other C++
+     representation issues.  Because we use this API, code generated by the LLVM
+     compilers should be binary compatible with machine code generated by other
+     Itanium ABI C++ compilers (such as G++, the Intel and HP compilers, etc).
+     However, the exception handling mechanism used by LLVM is very
+     different from the model used in the Itanium ABI, so exceptions will not
+     interact correctly. 
        • 
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Known problems with the X86 back-end
+ 
      
+ 
+ 
      
+ 
+ 
        
+   
      • none yet
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Known problems with the SparcV9 back-end
+ 
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
+ 
+ 
      
+   Known problems with the PowerPC back-end
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
      • none yet
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Known problems with the C back-end
+ 
      
+ 
+ 
      
+ 
+ 
        
+ 
+ 
      • The C back-end produces code that violates the ANSI C Type-Based Alias
+ Analysis rules.  As such, special options may be necessary to compile the code
+ (for example, GCC requires the -fno-strict-aliasing option).  This
+ problem probably cannot be fixed.
        • 
+ 
+ 
      • Zero arg vararg functions are not 
+ supported.  This should not affect LLVM produced by the C or C++ 
+ frontends.
        • 
+ 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Additional Information
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      A wide variety of additional information is available on the LLVM web page,
+ including mailing lists and publications describing algorithms and components
+ implemented in LLVM.  The web page also contains versions of the API
+ documentation which is up-to-date with the CVS version of the source code.  You
+ can access versions of these documents specific to this release by going into
+ the "llvm/doc/" directory in the LLVM tree.
      
+ 
+ 
      If you have any questions or comments about LLVM, please feel free to contact
+ us via the mailing
+ lists.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   The LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/SourceLevelDebugging.html
diff -c /dev/null llvm-www/releases/1.4/docs/SourceLevelDebugging.html:1.1
*** /dev/null	Thu Dec  9 16:19:07 2004
--- llvm-www/releases/1.4/docs/SourceLevelDebugging.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,1116 ----
+ 
+ 
+ 
+   Source Level Debugging with LLVM
+   
+ 
+ 
+ 
+ 
      Source Level Debugging with LLVM
      
+ 
+ 
+   
+     
+ 
+ 
      
+ 
+ 
+ A leafy and green bug eater
+ 
      
+ 
+ 
      
+   
      Written by Chris Lattner
      
+ 
      
+ 
+ 
+ 
+ 
      Introduction
       
+ 
+ 
      
+ 
+ 
      This document is the central repository for all information pertaining to
+ debug information in LLVM.  It describes the user
+ interface for the llvm-db tool, which provides a 
+ powerful source-level debugger
+ to users of LLVM-based compilers.  It then describes the various components that make up the debugger and the
+ libraries which future clients may use.  Finally, it describes the actual format that the LLVM debug information takes,
+ which is useful for those interested in creating front-ends or dealing directly
+ with the information.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Philosophy behind LLVM debugging information
+ 
      
+ 
+ 
      
+ 
+ 
      The idea of the LLVM debugging information is to capture how the important
+ pieces of the source-language's Abstract Syntax Tree map onto LLVM code.
+ Several design aspects have shaped the solution that appears here.  The
+ important ones are:
      
+ 
+ 
        
+ 
      • Debugging information should have very little impact on the rest of the
+ compiler.  No transformations, analyses, or code generators should need to be
+ modified because of debugging information.
        • 
+ 
+ 
      • LLVM optimizations should interact in well-defined and
+ easily described ways with the debugging information.
        • 
+ 
+ 
      • Because LLVM is designed to support arbitrary programming languages,
+ LLVM-to-LLVM tools should not need to know anything about the semantics of the
+ source-level-language.
        • 
+ 
+ 
      • Source-level languages are often widely different from one another.
+ LLVM should not put any restrictions of the flavor of the source-language, and
+ the debugging information should work with any language.
        • 
+ 
+ 
      • With code generator support, it should be possible to use an LLVM compiler
+ to compile a program to native machine code and standard debugging formats.
+ This allows compatibility with traditional machine-code level debuggers, like
+ GDB or DBX.
        • 
+ 
+ 
      
+ 
+ 
      The approach used by the LLVM implementation is to use a small set of intrinsic functions to define a mapping
+ between LLVM program objects and the source-level objects.  The description of
+ the source-level program is maintained in LLVM global variables in an implementation-defined format (the C/C++ front-end
+ currently uses working draft 7 of the Dwarf 3 standard).
      
+ 
+ 
      When a program is debugged, the debugger interacts with the user and turns
+ the stored debug information into source-language specific information.  As
+ such, the debugger must be aware of the source-language, and is thus tied to a
+ specific language of family of languages.  The LLVM
+ debugger is designed to be modular in its support for source-languages.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Debugging optimized code
+ 
      
+ 
+ 
      
+ 
+ 
      An extremely high priority of LLVM debugging information is to make it
+ interact well with optimizations and analysis.  In particular, the LLVM debug
+ information provides the following guarantees:
      
+ 
+ 
        
+ 
+ 
      • LLVM debug information always provides information to accurately read the
+ source-level state of the program, regardless of which LLVM optimizations
+ have been run, and without any modification to the optimizations themselves.
+ However, some optimizations may impact the ability to modify the current state
+ of the program with a debugger, such as setting program variables, or calling
+ function that have been deleted.
        • 
+ 
+ 
      • LLVM optimizations gracefully interact with debugging information.  If they
+ are not aware of debug information, they are automatically disabled as necessary
+ in the cases that would invalidate the debug info.  This retains the LLVM
+ features making it easy to write new transformations.
        • 
+ 
+ 
      • As desired, LLVM optimizations can be upgraded to be aware of the LLVM
+ debugging information, allowing them to update the debugging information as they
+ perform aggressive optimizations.  This means that, with effort, the LLVM
+ optimizers could optimize debug code just as well as non-debug code.
        • 
+ 
+ 
      • LLVM debug information does not prevent many important optimizations from
+ happening (for example inlining, basic block reordering/merging/cleanup, tail
+ duplication, etc), further reducing the amount of the compiler that eventually
+ is "aware" of debugging information.
        • 
+ 
+ 
      • LLVM debug information is automatically optimized along with the rest of the
+ program, using existing facilities.  For example, duplicate information is
+ automatically merged by the linker, and unused information is automatically
+ removed.
        • 
+ 
+ 
      
+ 
+ 
      Basically, the debug information allows you to compile a program with
+ "-O0 -g" and get full debug information, allowing you to arbitrarily
+ modify the program as it executes from the debugger.  Compiling a program with
+ "-O3 -g" gives you full debug information that is always available and
+ accurate for reading (e.g., you get accurate stack traces despite tail call
+ elimination and inlining), but you might lose the ability to modify the program
+ and call functions where were optimized out of the program, or inlined away
+ completely.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Future work
+ 
      
+ 
+ 
      
+ 
      There are several important extensions that could be eventually added to the
+ LLVM debugger.  The most important extension would be to upgrade the LLVM code
+ generators to support debugging information.  This would also allow, for
+ example, the X86 code generator to emit native objects that contain debugging
+ information consumable by traditional source-level debuggers like GDB or
+ DBX.
      
+ 
+ 
      Additionally, LLVM optimizations can be upgraded to incrementally update the
+ debugging information, new commands can be added to the
+ debugger, and thread support could be added to the debugger.
      
+ 
+ 
      The "SourceLanguage" modules provided by llvm-db could be
+ substantially improved to provide good support for C++ language features like
+ namespaces and scoping rules.
      
+ 
+ 
      After working with the debugger for a while, perhaps the nicest improvement
+ would be to add some sort of line editor, such as GNU readline (but one that is
+ compatible with the LLVM license).
      
+ 
+ 
      For someone so inclined, it should be straight-forward to write different
+ front-ends for the LLVM debugger, as the LLVM debugging engine is cleanly
+ separated from the llvm-db front-end.  A new LLVM GUI debugger or IDE
+ would be nice.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Using the llvm-db tool
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      The llvm-db tool provides a GDB-like interface for source-level
+ debugging of programs.  This tool provides many standard commands for inspecting
+ and modifying the program as it executes, loading new programs, single stepping,
+ placing breakpoints, etc.  This section describes how to use the debugger.
      
+ 
+ 
      llvm-db has been designed to be as similar to GDB in its user
+ interface as possible.  This should make it extremely easy to learn
+ llvm-db if you already know GDB.  In general, llvm-db
+ provides the subset of GDB commands that are applicable to LLVM debugging users.
+ If there is a command missing that make a reasonable amount of sense within the
+ limitations of llvm-db, please report it as
+ a bug or, better yet, submit a patch to add it.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Limitations of llvm-db
+ 
      
+ 
+ 
      
+ 
+ 
      llvm-db is designed to be modular and easy to extend.  This
+ extensibility was key to getting the debugger up-and-running quickly, because we
+ can start with simple-but-unsophisicated implementations of various components.
+ Because of this, it is currently missing many features, though they should be
+ easy to add over time (patches welcomed!).  The biggest inherent limitations of
+ llvm-db are currently due to extremely simple debugger backend (implemented in
+ "lib/Debugger/UnixLocalInferiorProcess.cpp") which is designed to work without
+ any cooperation from the code generators.  Because it is so simple, it suffers
+ from the following inherent limitations:
      
+ 
+ 
        
+ 
+ 
      • Running a program in llvm-db is a bit slower than running it with
+ lli (i.e., in the JIT).
        • 
+ 
+ 
      • Inspection of the target hardware is not supported.  This means that you
+ cannot, for example, print the contents of X86 registers.
        • 
+ 
+ 
      • Inspection of LLVM code is not supported.  This means that you cannot print
+ the contents of arbitrary LLVM values, or use commands such as stepi.
+ This also means that you cannot debug code without debug information.
        • 
+ 
+ 
      • Portions of the debugger run in the same address space as the program being
+ debugged.  This means that memory corruption by the program could trample on
+ portions of the debugger.
        • 
+ 
+ 
      • Attaching to existing processes and core files is not currently
+ supported.
        • 
+ 
+ 
      
+ 
+ 
      That said, the debugger is still quite useful, and all of these limitations
+ can be eliminated by integrating support for the debugger into the code
+ generators, and writing a new InferiorProcess
+ subclass to use it.  See the future work section for ideas
+ of how to extend the LLVM debugger despite these limitations.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   A sample llvm-db session
+ 
      
+ 
+ 
      
+ 
+ 
      TODO: this is obviously lame, when more is implemented, this can be much
+ better.
      
+ 
+ 
      + $ llvm-db funccall
+ llvm-db: The LLVM source-level debugger
+ Loading program... successfully loaded 'funccall.bc'!
+ (llvm-db) create
+ Starting program: funccall.bc
+ main at funccall.c:9:2
+ 9 ->            q = 0;
+ (llvm-db) list main
+ 4       void foo() {
+ 5               int t = q;
+ 6               q = t + 1;
+ 7       }
+ 8       int main() {
+ 9 ->            q = 0;
+ 10              foo();
+ 11              q = q - 1;
+ 12
+ 13              return q;
+ (llvm-db) list
+ 14      }
+ (llvm-db) step
+ 10 ->           foo();
+ (llvm-db) s
+ foo at funccall.c:5:2
+ 5 ->            int t = q;
+ (llvm-db) bt
+ #0 ->   0x85ffba0 in foo at funccall.c:5:2
+ #1      0x85ffd98 in main at funccall.c:10:2
+ (llvm-db) finish
+ main at funccall.c:11:2
+ 11 ->           q = q - 1;
+ (llvm-db) s
+ 13 ->           return q;
+ (llvm-db) s
+ The program stopped with exit code 0
+ (llvm-db) quit
+ $
+ 
      
+ 
+ 
      
+ 
+ 
+ 
+ 
+ 
      
+   Starting the debugger
+ 
      
+ 
+ 
      
+ 
+ 
      There are three ways to start up the llvm-db debugger:
      
+ 
+ 
      When run with no options, just llvm-db, the debugger starts up
+ without a program loaded at all.  You must use the file command to load a program, and the set args or run
+ commands to specify the arguments for the program.
      
+ 
+ 
      If you start the debugger with one argument, as llvm-db
+ <program>, the debugger will start up and load in the specified
+ program.  You can then optionally specify arguments to the program with the set args or run
+ commands.
      
+ 
+ 
      The third way to start the program is with the --args option.  This
+ option allows you to specify the program to load and the arguments to start out
+ with.   Example use: llvm-db --args ls /home
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Commands recognized by the debugger
+ 
      
+ 
+ 
      
+ 
+ 
      FIXME: this needs work obviously.  See the GDB documentation for
+ information about what these do, or try 'help [command]' within
+ llvm-db to get information.
      
+ 
+ 
      
+ 
      General usage:
      
+ 
        
+ 
      • help [command]
        • 
+ 
      • quit
        • 
+ 
      • file [program]
        • 
+ 
      
+ 
+ 
      Program inspection and interaction:
      
+ 
        
+ 
      • create (start the program, stopping it ASAP in main)
        • 
+ 
      • kill
        • 
+ 
      • run [args]
        • 
+ 
      • step [num]
        • 
+ 
      • next [num]
        • 
+ 
      • cont
        • 
+ 
      • finish
        • 
+ 
+ 
      • list [start[, end]]
        • 
+ 
      • info source
        • 
+ 
      • info sources
        • 
+ 
      • info functions
        • 
+ 
      
+ 
+ 
      Call stack inspection:
      
+ 
        
+ 
      • backtrace
        • 
+ 
      • up [n]
        • 
+ 
      • down [n]
        • 
+ 
      • frame [n]
        • 
+ 
      
+ 
+ 
+ 
      Debugger inspection and interaction:
      
+ 
        
+ 
      • info target
        • 
+ 
      • show prompt
        • 
+ 
      • set prompt
        • 
+ 
      • show listsize
        • 
+ 
      • set listsize
        • 
+ 
      • show language
        • 
+ 
      • set language
        • 
+ 
      • show args
        • 
+ 
      • set args [args]
        • 
+ 
      
+ 
+ 
      TODO:
      
+ 
        
+ 
      • info frame
        • 
+ 
      • break
        • 
+ 
      • print
        • 
+ 
      • ptype
        • 
+ 
+ 
      • info types
        • 
+ 
      • info variables
        • 
+ 
      • info program
        • 
+ 
+ 
      • info args
        • 
+ 
      • info locals
        • 
+ 
      • info catch
        • 
+ 
      • ... many others
        • 
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Architecture of the LLVM debugger
+ 
      
+ 
+ 
+ 
      
+ 
      The LLVM debugger is built out of three distinct layers of software.  These
+ layers provide clients with different interface options depending on what pieces
+ of they want to implement themselves, and it also promotes code modularity and
+ good design.  The three layers are the Debugger
+ interface, the "info" interfaces, and the llvm-db tool itself.
      
+ 
      
+ 
+ 
+ 
      
+   The Debugger and InferiorProcess classes
+ 
      
+ 
+ 
      
+ 
      The Debugger class (defined in the include/llvm/Debugger/ directory)
+ is a low-level class which is used to maintain information about the loaded
+ program, as well as start and stop the program running as necessary.  This class
+ does not provide any high-level analysis or control over the program, only
+ exposing simple interfaces like load/unloadProgram,
+ create/killProgram, step/next/finish/contProgram, and
+ low-level methods for installing breakpoints.
      
+ 
+ 
      
+ The Debugger class is itself a wrapper around the lowest-level InferiorProcess
+ class.  This class is used to represent an instance of the program running under
+ debugger control.  The InferiorProcess class can be implemented in different
+ ways for different targets and execution scenarios (e.g., remote debugging).
+ The InferiorProcess class exposes a small and simple collection of interfaces
+ which are useful for inspecting the current state of the program (such as
+ collecting stack trace information, reading the memory image of the process,
+ etc).  The interfaces in this class are designed to be as low-level and simple
+ as possible, to make it easy to create new instances of the class.
+ 
      
+ 
+ 
      
+ The Debugger class exposes the currently active instance of InferiorProcess
+ through the Debugger::getRunningProcess method, which returns a
+ const reference to the class.  This means that clients of the Debugger
+ class can only inspect the running instance of the program directly.  To
+ change the executing process in some way, they must use the interces exposed by
+ the Debugger class.
+ 
      
+ 
      
+ 
+ 
+ 
      
+   The RuntimeInfo, ProgramInfo, and SourceLanguage classes
+ 
      
+ 
+ 
      
+ 
      
+ The next-highest level of debugger abstraction is provided through the
+ ProgramInfo, RuntimeInfo, SourceLanguage and related classes (also defined in
+ the include/llvm/Debugger/ directory).  These classes efficiently
+ decode the debugging information and low-level interfaces exposed by
+ InferiorProcess into a higher-level representation, suitable for analysis by the
+ debugger.
+ 
      
+ 
+ 
      
+ The ProgramInfo class exposes a variety of different kinds of information about
+ the program objects in the source-level-language.  The SourceFileInfo class
+ represents a source-file in the program (e.g. a .cpp or .h file).  The
+ SourceFileInfo class captures information such as which SourceLanguage was used
+ to compile the file, where the debugger can get access to the actual file text
+ (which is lazily loaded on demand), etc.  The SourceFunctionInfo class
+ represents a... FIXME: finish.  The ProgramInfo class provides interfaces
+ to lazily find and decode the information needed to create the Source*Info
+ classes requested by the debugger.
+ 
      
+ 
+ 
      
+ The RuntimeInfo class exposes information about the currently executed program,
+ by decoding information from the InferiorProcess and ProgramInfo classes.  It
+ provides a StackFrame class which provides an easy-to-use interface for
+ inspecting the current and suspended stack frames in the program.
+ 
      
+ 
+ 
      
+ The SourceLanguage class is an abstract interface used by the debugger to
+ perform all source-language-specific tasks.  For example, this interface is used
+ by the ProgramInfo class to decode language-specific types and functions and by
+ the debugger front-end (such as llvm-db to
+ evaluate source-langauge expressions typed into the debugger.  This class uses
+ the RuntimeInfo & ProgramInfo classes to get information about the current
+ execution context and the loaded program, respectively.
+ 
      
+ 
+ 
      
+ 
+ 
+ 
      
+   The llvm-db tool
+ 
      
+ 
+ 
      
+ 
      
+ The llvm-db is designed to be a debugger providing an interface as similar to GDB as reasonable, but no more so than that.
+ Because the Debugger and info classes implement all of the heavy lifting and
+ analysis, llvm-db (which lives in llvm/tools/llvm-db) consists
+ mainly of of code to interact with the user and parse commands.  The CLIDebugger
+ constructor registers all of the builtin commands for the debugger, and each
+ command is implemented as a CLIDebugger::[name]Command method.
+ 
      
+ 
      
+ 
+ 
+ 
+ 
      
+   Short-term TODO list
+ 
      
+ 
+ 
      
+ 
+ 
      
+ FIXME: this section will eventually go away.  These are notes to myself of
+ things that should be implemented, but haven't yet.
+ 
      
+ 
+ 
      
+ Breakpoints: Support is already implemented in the 'InferiorProcess'
+ class, though it hasn't been tested yet.  To finish breakpoint support, we need
+ to implement breakCommand (which should reuse the linespec parser from the list
+ command), and handle the fact that 'break foo' or 'break file.c:53' may insert
+ multiple breakpoints.  Also, if you say 'break file.c:53' and there is no
+ stoppoint on line 53, the breakpoint should go on the next available line.  My
+ idea was to have the Debugger class provide a "Breakpoint" class which
+ encapsulated this messiness, giving the debugger front-end a simple interface.
+ The debugger front-end would have to map the really complex semantics of
+ temporary breakpoints and 'conditional' breakpoints onto this intermediate
+ level. Also, breakpoints should survive as much as possible across program
+ reloads.
+ 
      
+ 
+ 
      
+ UnixLocalInferiorProcess.cpp speedup: There is no reason for the debugged
+ process to code gen the globals corresponding to debug information.  The
+ IntrinsicLowering object could instead change descriptors into constant expr
+ casts of the constant address of the LLVM objects for the descriptors.  This
+ would also allow us to eliminate the mapping back and forth between physical
+ addresses that must be done.
      
+ 
+ 
      
+ Process deaths: The InferiorProcessDead exception should be extended to
+ know "how" a process died, i.e., it was killed by a signal.  This is easy to
+ collect in the UnixLocalInferiorProcess, we just need to represent it.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Debugging information format
+ 
      
+ 
+ 
+ 
      
+ 
+ 
      LLVM debugging information has been carefully designed to make it possible
+ for the optimizer to optimize the program and debugging information without
+ necessarily having to know anything about debugging information.  In particular,
+ the global constant merging pass automatically eliminates duplicated debugging
+ information (often caused by header files), the global dead code elimination
+ pass automatically deletes debugging information for a function if it decides to
+ delete the function, and the linker eliminates debug information when it merges
+ linkonce functions.
      
+ 
+ 
      To do this, most of the debugging information (descriptors for types,
+ variables, functions, source files, etc) is inserted by the language front-end
+ in the form of LLVM global variables.  These LLVM global variables are no
+ different from any other global variables, except that they have a web of LLVM
+ intrinsic functions that point to them.  If the last references to a particular
+ piece of debugging information are deleted (for example, by the
+ -globaldce pass), the extraneous debug information will automatically
+ become dead and be removed by the optimizer.
      
+ 
+ 
      The debugger is designed to be agnostic about the contents of most of the
+ debugging information.  It uses a source-language-specific
+ module to decode the information that represents variables, types,
+ functions, namespaces, etc: this allows for arbitrary source-language semantics
+ and type-systems to be used, as long as there is a module written for the
+ debugger to interpret the information.
      
+ 
+ 
      To provide basic functionality, the LLVM debugger does have to make some
+ assumptions about the source-level language being debugged, though it keeps
+ these to a minimum.  The only common features that the LLVM debugger assumes
+ exist are source files, and program objects.  These abstract objects are
+ used by the debugger to form stack traces, show information about local
+ variables, etc.
      
+ 
+ 
      This section of the documentation first describes the representation aspects
+ common to any source-language.  The next section
+ describes the data layout conventions used by the C and C++ front-ends.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Anchors for global objects
+ 
      
+ 
+ 
      
+ 
      One important aspect of the LLVM debug representation is that it allows the
+ LLVM debugger to efficiently index all of the global objects without having the
+ scan the program.  To do this, all of the global objects use "anchor" globals of
+ type "{}", with designated names.  These anchor objects obviously do
+ not contain any content or meaning by themselves, but all of the global objects
+ of a particular type (e.g., source file descriptors) contain a pointer to the
+ anchor.  This pointer allows the debugger to use def-use chains to find all
+ global objects of that type.
      
+ 
+ 
      So far, the following names are recognized as anchors by the LLVM
+ debugger:
      
+ 
+ 
      +   %llvm.dbg.translation_units = linkonce global {} {}
+   %llvm.dbg.globals         = linkonce global {} {}
+ 
      
+ 
+ 
      Using anchors in this way (where the source file descriptor points to the
+ anchors, as opposed to having a list of source file descriptors) allows for the
+ standard dead global elimination and merging passes to automatically remove
+ unused debugging information.  If the globals were kept track of through lists,
+ there would always be an object pointing to the descriptors, thus would never be
+ deleted.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   
+      Representing stopping points in the source program
+   
+ 
      
+ 
+ 
      
+ 
+ 
      LLVM debugger "stop points" are a key part of the debugging representation
+ that allows the LLVM to maintain simple semantics for debugging optimized code.  The basic idea is that the
+ front-end inserts calls to the %llvm.dbg.stoppoint intrinsic function
+ at every point in the program where the debugger should be able to inspect the
+ program (these correspond to places the debugger stops when you "step"
+ through it).  The front-end can choose to place these as fine-grained as it
+ would like (for example, before every subexpression evaluated), but it is
+ recommended to only put them after every source statement that includes
+ executable code.
      
+ 
+ 
      Using calls to this intrinsic function to demark legal points for the
+ debugger to inspect the program automatically disables any optimizations that
+ could potentially confuse debugging information.  To non-debug-information-aware
+ transformations, these calls simply look like calls to an external function,
+ which they must assume to do anything (including reading or writing to any part
+ of reachable memory).  On the other hand, it does not impact many optimizations,
+ such as code motion of non-trapping instructions, nor does it impact
+ optimization of subexpressions, code duplication transformations, or basic-block
+ reordering transformations.
      
+ 
+ 
      An important aspect of the calls to the %llvm.dbg.stoppoint
+ intrinsic is that the function-local debugging information is woven together
+ with use-def chains.  This makes it easy for the debugger to, for example,
+ locate the 'next' stop point.  For a concrete example of stop points, see the
+ example in the next section.
      
+ 
+ 
      
+ 
+ 
+ 
+ 
      
+   Object lifetimes and scoping
+ 
      
+ 
+ 
      
+ 
      In many languages, the local variables in functions can have their lifetime
+ or scope limited to a subset of a function.  In the C family of languages, for
+ example, variables are only live (readable and writable) within the source block
+ that they are defined in.  In functional languages, values are only readable
+ after they have been defined.  Though this is a very obvious concept, it is also
+ non-trivial to model in LLVM, because it has no notion of scoping in this sense,
+ and does not want to be tied to a language's scoping rules.
      
+ 
+ 
      In order to handle this, the LLVM debug format uses the notion of "regions"
+ of a function, delineated by calls to intrinsic functions.  These intrinsic
+ functions define new regions of the program and indicate when the region
+ lifetime expires.  Consider the following C fragment, for example:
      
+ 
+ 
      + 1.  void foo() {
+ 2.    int X = ...;
+ 3.    int Y = ...;
+ 4.    {
+ 5.      int Z = ...;
+ 6.      ...
+ 7.    }
+ 8.    ...
+ 9.  }
+ 
      
+ 
+ 
      Compiled to LLVM, this function would be represented like this (FIXME: CHECK
+ AND UPDATE THIS):
      
+ 
+ 
      + void %foo() {
+     %X = alloca int
+     %Y = alloca int
+     %Z = alloca int
+     %D1 = call {}* %llvm.dbg.func.start(%lldb.global* %d.foo)
+     %D2 = call {}* %llvm.dbg.stoppoint({}* %D1, uint 2, uint 2, %lldb.compile_unit* %file)
+ 
+     %D3 = call {}* %llvm.dbg.DEFINEVARIABLE({}* %D2, ...)
+     ;; Evaluate expression on line 2, assigning to X.
+     %D4 = call {}* %llvm.dbg.stoppoint({}* %D3, uint 3, uint 2, %lldb.compile_unit* %file)
+ 
+     %D5 = call {}* %llvm.dbg.DEFINEVARIABLE({}* %D4, ...)
+     ;; Evaluate expression on line 3, assigning to Y.
+     %D6 = call {}* %llvm.dbg.stoppoint({}* %D5, uint 5, uint 4, %lldb.compile_unit* %file)
+ 
+     %D7 = call {}* %llvm.region.start({}* %D6)
+     %D8 = call {}* %llvm.dbg.DEFINEVARIABLE({}* %D7, ...)
+     ;; Evaluate expression on line 5, assigning to Z.
+     %D9 = call {}* %llvm.dbg.stoppoint({}* %D8, uint 6, uint 4, %lldb.compile_unit* %file)
+ 
+     ;; Code for line 6.
+     %D10 = call {}* %llvm.region.end({}* %D9)
+     %D11 = call {}* %llvm.dbg.stoppoint({}* %D10, uint 8, uint 2, %lldb.compile_unit* %file)
+ 
+     ;; Code for line 8.
+     %D12 = call {}* %llvm.region.end({}* %D11)
+     ret void
+ }
+ 
      
+ 
+ 
      This example illustrates a few important details about the LLVM debugging
+ information.  In particular, it shows how the various intrinsics used are woven
+ together with def-use and use-def chains, similar to how anchors are used with globals.  This allows
+ the debugger to analyze the relationship between statements, variable
+ definitions, and the code used to implement the function.
      
+ 
+ 
      In this example, two explicit regions are defined, one with the definition of the %D1 variable and one with the
+ definition of %D7.  In the case of
+ %D1, the debug information indicates that the function whose descriptor is specified as an argument to the
+ intrinsic.  This defines a new stack frame whose lifetime ends when the region
+ is ended by the %D12 call.
      
+ 
+ 
      Using regions to represent the boundaries of source-level functions allow
+ LLVM interprocedural optimizations to arbitrarily modify LLVM functions without
+ having to worry about breaking mapping information between the LLVM code and the
+ and source-level program.  In particular, the inliner requires no modification
+ to support inlining with debugging information: there is no explicit correlation
+ drawn between LLVM functions and their source-level counterparts (note however,
+ that if the inliner inlines all instances of a non-strong-linkage function into
+ its caller that it will not be possible for the user to manually invoke the
+ inlined function from the debugger).
      
+ 
+ 
      Once the function has been defined, the stopping point corresponding to line #2 of
+ the function is encountered.  At this point in the function, no local
+ variables are live.  As lines 2 and 3 of the example are executed, their
+ variable definitions are automatically introduced into the program, without the
+ need to specify a new region.  These variables do not require new regions to be
+ introduced because they go out of scope at the same point in the program: line
+ 9.
      
+ 
+ 
      In contrast, the Z variable goes out of scope at a different time,
+ on line 7.  For this reason, it is defined within the
+ %D7 region, which kills the availability of Z before the
+ code for line 8 is executed.  In this way, regions can support arbitrary
+ source-language scoping rules, as long as they can only be nested (ie, one scope
+ cannot partially overlap with a part of another scope).
      
+ 
+ 
      It is worth noting that this scoping mechanism is used to control scoping of
+ all declarations, not just variable declarations.  For example, the scope of a
+ C++ using declaration is controlled with this, and the llvm-db C++
+ support routines could use this to change how name lookup is performed (though
+ this is not implemented yet).
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Object descriptor formats
+ 
      
+ 
+ 
      
+ 
      The LLVM debugger expects the descriptors for program objects to start in a
+ canonical format, but the descriptors can include additional information
+ appended at the end that is source-language specific.  All LLVM debugging
+ information is versioned, allowing backwards compatibility in the case that the
+ core structures need to change in some way.  Also, all debugging information
+ objects start with a tag to indicate what type
+ of object it is.  The source-language is allows to define its own objects, by
+ using unreserved tag numbers.
      
+ 
+ 
      The lowest-level descriptor are those describing the files containing the program source
+ code, as most other descriptors (sometimes indirectly) refer to them.
+ 
      
+ 
      
+ 
+ 
+ 
+ 
      
+   Representation of program objects
+ 
      
+ 
+ 
      
+ 
      
+ The LLVM debugger needs to know about some source-language program objects, in
+ order to build stack traces, print information about local variables, and other
+ related activities.  The LLVM debugger differentiates between three different
+ types of program objects: subprograms (functions, messages, methods, etc),
+ variables (locals and globals), and others.  Because source-languages have
+ widely varying forms of these objects, the LLVM debugger expects only a few
+ fields in the descriptor for each object:
+ 
      
+ 
+ 
      + %lldb.object = type {
+        uint,                  ;; A tag
+        any*,                  ;; The context for the object
+        sbyte*                 ;; The object 'name'
+ }
+ 
      
+ 
+ 
      The first field contains a tag for the descriptor.  The second field contains
+ either a pointer to the descriptor for the containing source file, or it contains a pointer to
+ another program object whose context pointer eventually reaches a source file.
+ Through this context pointer, the
+ LLVM debugger can establish the debug version number of the object.
      
+ 
+ 
      The third field contains a string that the debugger can use to identify the
+ object if it does not contain explicit support for the source-language in use
+ (ie, the 'unknown' source language handler uses this string).  This should be
+ some sort of unmangled string that corresponds to the object, but it is a
+ quality of implementation issue what exactly it contains (it is legal, though
+ not useful, for all of these strings to be null).
      
+ 
+ 
      Note again that descriptors can be extended to include
+ source-language-specific information in addition to the fields required by the
+ LLVM debugger.  See the section on the C/C++
+ front-end for more information.  Also remember that global objects
+ (functions, selectors, global variables, etc) must contain an anchor to the llvm.dbg.globals
+ variable.
      
+ 
      
+ 
+ 
+ 
+ 
      
+   Program object contexts
+ 
      
+ 
+ 
      
+ 
      + Allow source-language specific contexts, use to identify namespaces etc
+ Must end up in a source file descriptor.
+ Debugger core ignores all unknown context objects.
+ 
      
+ 
      
+ 
+ 
+ 
      
+   Debugger intrinsic functions
+ 
      
+ 
+ 
      
+ 
      + Define each intrinsics, as an extension of the language reference manual.
+ 
+ llvm.dbg.stoppoint
+ llvm.dbg.region.start
+ llvm.dbg.region.end
+ llvm.dbg.function.start
+ llvm.dbg.declare
+ 
      
+ 
      
+ 
+ 
+ 
      
+   Values for debugger tags
+ 
      
+ 
+ 
      
+ 
+ 
      Happen to be the same value as the similarly named Dwarf-3 tags, this may
+ change in the future.
      
+ 
+ 
      +   LLVM_COMPILE_UNIT     : 17
+   LLVM_SUBPROGRAM       : 46
+   LLVM_VARIABLE         : 52
+ 
+ 
      
+ 
      
+ 
+ 
+ 
+ 
+ 
      
+   C/C++ front-end specific debug information
+ 
      
+ 
+ 
      
+ 
+ 
      The C and C++ front-ends represent information about the program in a format
+ that is effectively identical to Dwarf 3.0 in terms of
+ information content.  This allows code generators to trivially support native
+ debuggers by generating standard dwarf information, and contains enough
+ information for non-dwarf targets to translate it as needed.
      
+ 
+ 
      The basic debug information required by the debugger is (intentionally)
+ designed to be as minimal as possible.  This basic information is so minimal
+ that it is unlikely that any source-language could be adequately
+ described by it.  Because of this, the debugger format was designed for
+ extension to support source-language-specific information.  The extended
+ descriptors are read and interpreted by the language-specific modules in the debugger if there is
+ support available, otherwise it is ignored.
      
+ 
+ 
      This section describes the extensions used to represent C and C++ programs.
+ Other languages could pattern themselves after this (which itself is tuned to
+ representing programs in the same way that Dwarf 3 does), or they could choose
+ to provide completely different extensions if they don't fit into the Dwarf
+ model.  As support for debugging information gets added to the various LLVM
+ source-language front-ends, the information used should be documented here.
      
+ 
+ 
      
+ 
+ 
+ 
      
+   Program Scope Entries
+ 
      
+ 
+ 
      
+ 
      TODO
      
+ 
      
+ 
+ 
+ 
      
+   Compilation unit entries
+ 
      
+ 
+ 
      
+ 
      
+ Translation units do not add any information over the standard source file representation already
+ expected by the debugger.  As such, it uses descriptors of the type specified,
+ with a trailing anchor.
+ 
      
+ 
      
+ 
+ 
+ 
      
+   Module, namespace, and importing entries
+ 
      
+ 
+ 
      
+ 
      TODO
      
+ 
      
+ 
+ 
+ 
      
+   Data objects (program variables)
+ 
      
+ 
+ 
      
+ 
      TODO
      
+ 
      
+ 
+ 
+ 
+ 
+ 
      
+ 
      
+   Valid CSS!
+   Valid HTML 4.01!
+ 
+   Chris Lattner
      
+   LLVM Compiler Infrastructure
      
+   Last modified: $Date: 2004/12/09 22:18:55 $
+ 
      
+ 
+ 
+ 


Index: llvm-www/releases/1.4/docs/Stacker.html
diff -c /dev/null llvm-www/releases/1.4/docs/Stacker.html:1.1
*** /dev/null	Thu Dec  9 16:19:07 2004
--- llvm-www/releases/1.4/docs/Stacker.html	Thu Dec  9 16:18:55 2004
***************
*** 0 ****
--- 1,1408 ----
+ 
+ 
+ 
+   Stacker: An Example Of Using LLVM
+   
+ 
+ 
+ 
+ 
      Stacker: An Example Of Using LLVM
      
+ 
+ 
        
+   
      1. Abstract
        2. 
+   
      2. Introduction
        3. 
+   
      3. Lessons I Learned About LLVM
+     
          
+       
        1. Everything's a Value!
          2. 
+       
        2. Terminate Those Blocks!
          3. 
+       
        3. Concrete Blocks
          4. 
+       
        4. push_back Is Your Friend
          5. 
+       
        5. The Wily GetElementPtrInst
          6. 
+       
        6. Getting Linkage Types Right
          7. 
+       
        7. Constants Are Easier Than That!
          8. 
+     
        4. 
+   
      4. The Stacker Lexicon
+     
          
+       
        1. The Stack
          2. 
+       
        2. Punctuation
          3. 
+       
        3. Comments
          4. 
+       
        4. Literals
          5. 
+       
        5. Words
          6. 
+       
        6. Standard Style
          7. 
+       
        7. Built-Ins
          8. 
+     
        5. 
+   
      5. Prime: A Complete Example
        6. 
+   
      6. Internal Code Details
+     
          
+       
        1. The Directory Structure 
          2. 
+       
        2. The Lexer
          3. 
+       
        3. The Parser
          4. 
+       
        4. The Compiler
          5. 
+       
        5. The Runtime
          6. 
+       
        6. Compiler Driver
          7. 
+       
        7. Test Programs
          8. 
+       
        8. Exercise
          9. 
+       
        9. Things Remaining To Be Done
          10. 
+     
        7. 
+ 
      
+ 
+ 
      
+   
      Written by Reid Spencer
      
+ 
      
+ 
+ 
+ 
      Abstract
      
+ 
      
+ 
      This document is another way to learn about LLVM. Unlike the 
+ LLVM Reference Manual or 
+ LLVM Programmer's Manual, here we learn
+ about LLVM through the experience of creating a simple programming language
+ named Stacker.  Stacker was invented specifically as a demonstration of
+ LLVM. The emphasis in this document is not on describing the
+ intricacies of LLVM itself but on how to use it to build your own
+ compiler system.
      
+ 
      
+ 
+ 
       Introduction 
      
+ 
      
+ 
      Amongst other things, LLVM is a platform for compiler writers.
+ Because of its exceptionally clean and small IR (intermediate
+ representation), compiler writing with LLVM is much easier than with
+ other system. As proof, I wrote the entire compiler (language definition, 
+ lexer, parser, code generator, etc.) in about four days! 
+ That's important to know because it shows how quickly you can get a new
+ language running when using LLVM. Furthermore, this was the first 
+ language the author ever created using LLVM. The learning curve is 
+ included in that four days.
      
+ 
      The language described here, Stacker, is Forth-like. Programs
+ are simple collections of word definitions, and the only thing definitions
+ can do is manipulate a stack or generate I/O.  Stacker is not a "real" 
+ programming language; it's very simple.  Although it is computationally 
+ complete, you wouldn't use it for your next big project. However, 
+ the fact that it is complete, it's simple, and it doesn't have 
+ a C-like syntax make it useful for demonstration purposes. It shows
+ that LLVM could be applied to a wide variety of languages.
      
+ 
      The basic notions behind stacker is very simple. There's a stack of 
+ integers (or character pointers) that the program manipulates. Pretty 
+ much the only thing the program can do is manipulate the stack and do 
+ some limited I/O operations. The language provides you with several 
+ built-in words that manipulate the stack in interesting ways. To get 
+ your feet wet, here's how you write the traditional "Hello, World" 
+ program in Stacker:
      
+ 
      : hello_world "Hello, World!" >s DROP CR ;
      
+ : MAIN hello_world ;
      
+ 
      This has two "definitions" (Stacker manipulates words, not
+ functions and words have definitions): MAIN and 
+ hello_world. The MAIN definition is standard; it
+ tells Stacker where to start. Here, MAIN is defined to 
+ simply invoke the word hello_world. The
+ hello_world definition tells stacker to push the 
+ "Hello, World!" string on to the stack, print it out 
+ (>s), pop it off the stack (DROP), and
+ finally print a carriage return (CR). Although 
+ hello_world uses the stack, its net effect is null. Well
+ written Stacker definitions have that characteristic. 
      
+ 
      Exercise for the reader: how could you make this a one line program?
      
+ 
      
+ 
+ 
      Lessons I Learned About LLVM
      
+ 
      
+ 
      Stacker was written for two purposes: 
      
+ 
        
+     
      1. to get the author over the learning curve, and
        2. 
+     
      2. to provide a simple example of how to write a compiler using LLVM.
        3. 
+ 
      
+ 
      During the development of Stacker, many lessons about LLVM were
+ learned. Those lessons are described in the following subsections.
      
+ 
      
+ 
+ 
      Everything's a Value!
      
+ 
      
+ 
      Although I knew that LLVM uses a Single Static Assignment (SSA) format, 
+ it wasn't obvious to me how prevalent this idea was in LLVM until I really
+ started using it.  Reading the 
+ Programmer's Manual and Language Reference,
+ I noted that most of the important LLVM IR (Intermediate Representation) C++ 
+ classes were derived from the Value class. The full power of that simple
+ design only became fully understood once I started constructing executable
+ expressions for Stacker.
      
+ 
+ 
      This really makes your programming go faster. Think about compiling code
+ for the following C/C++ expression: (a|b)*((x+1)/(y+1)). Assuming
+ the values are on the stack in the order a, b, x, y, this could be
+ expressed in stacker as: 1 + SWAP 1 + / ROT2 OR *.
+ You could write a function using LLVM that computes this expression like 
+ this: 
      
+ 
+ 
      + Value* 
+ expression(BasicBlock* bb, Value* a, Value* b, Value* x, Value* y )
+ {
+     ConstantSInt* one = ConstantSInt::get(Type::IntTy, 1);
+     BinaryOperator* or1 = BinaryOperator::createOr(a, b, "", bb);
+     BinaryOperator* add1 = BinaryOperator::createAdd(x, one, "", bb);
+     BinaryOperator* add2 = BinaryOperator::createAdd(y, one, "", bb);
+     BinaryOperator* div1 = BinaryOperator::createDiv(add1, add2, "", bb);
+     BinaryOperator* mult1 = BinaryOperator::createMul(or1, div1, "", bb);
+     return mult1;
+ }
+ 
      
+ 
+ 
      "Okay, big deal," you say?  It is a big deal. Here's why. Note that I didn't
+ have to tell this function which kinds of Values are being passed in. They could be
+ Instructions, Constants, GlobalVariables, or
+ any of the other subclasses of Value that LLVM supports.
+ Furthermore, if you specify Values that are incorrect for this sequence of 
+ operations, LLVM will either notice right away (at compilation time) or the LLVM 
+ Verifier will pick up the inconsistency when the compiler runs. In either case 
+ LLVM prevents you from making a type error that gets passed through to the 
+ generated program.  This really helps you write a compiler that 
+ always generates correct code!
      
+ 
      The second point is that we don't have to worry about branching, registers,
+ stack variables, saving partial results, etc. The instructions we create 
+ are the values we use. Note that all that was created in the above
+ code is a Constant value and five operators. Each of the instructions is 
+ the resulting value of that instruction. This saves a lot of time.
      
+ 
      The lesson is this: SSA form is very powerful: there is no difference
+ between a value and the instruction that created it. This is fully
+ enforced by the LLVM IR. Use it to your best advantage.
      
+ 
      
+ 
+ 
      Terminate Those Blocks!
      
+ 
      
+ 
      I had to learn about terminating blocks the hard way: using the debugger 
+ to figure out what the LLVM verifier was trying to tell me and begging for
+ help on the LLVMdev mailing list. I hope you avoid this experience.
      
+ 
      Emblazon this rule in your mind:
      
+ 
        
+     
      • All BasicBlocks in your compiler must be
+ 	terminated with a terminating instruction (branch, return, etc.).
+     
        • 
+ 
      
+ 
      Terminating instructions are a semantic requirement of the LLVM IR. There
+ is no facility for implicitly chaining together blocks placed into a function
+ in the order they occur. Indeed, in the general case, blocks will not be
+ added to the function in the order of execution because of the recursive
+ way compilers are written.
      
+ 
      Furthermore, if you don't terminate your blocks, your compiler code will 
+ compile just fine. You won't find out about the problem until you're running 
+ the compiler and the module you just created fails on the LLVM Verifier.
      
+ 
      
+ 
+ 
      Concrete Blocks
      
+ 
      
+ 
      After a little initial fumbling around, I quickly caught on to how blocks
+ should be constructed. In general, here's what I learned:
+ 
        
+     
      1. Create your blocks early. While writing your compiler, you 
+     will encounter several situations where you know apriori that you will
+     need several blocks. For example, if-then-else, switch, while, and for
+     statements in C/C++ all need multiple blocks for expression in LVVM. 
+     The rule is, create them early.
        2. 
+     
      2. Terminate your blocks early. This just reduces the chances 
+     that you forget to terminate your blocks which is required (go 
+     here for more). 
+     
      3. Use getTerminator() for instruction insertion. I noticed early on
+     that many of the constructors for the Instruction classes take an optional
+     insert_before argument. At first, I thought this was a mistake
+     because clearly the normal mode of inserting instructions would be one at
+     a time after some other instruction, not before. However,
+     if you hold on to your terminating instruction (or use the handy dandy
+     getTerminator() method on a BasicBlock), it can
+     always be used as the insert_before argument to your instruction
+     constructors. This causes the instruction to automatically be inserted in 
+     the RightPlace™ place, just before the terminating instruction. The 
+     nice thing about this design is that you can pass blocks around and insert 
+     new instructions into them without ever knowing what instructions came 
+     before. This makes for some very clean compiler design.
        4. 
+ 
      
+ 
      The foregoing is such an important principal, its worth making an idiom:
      
+ 
      + BasicBlock* bb = new BasicBlock();
+ bb->getInstList().push_back( new Branch( ... ) );
+ new Instruction(..., bb->getTerminator() );
+ 
      
+ 
      To make this clear, consider the typical if-then-else statement
+ (see StackerCompiler::handle_if() method).  We can set this up
+ in a single function using LLVM in the following way: 
      
+ 
      + using namespace llvm;
+ BasicBlock*
+ MyCompiler::handle_if( BasicBlock* bb, SetCondInst* condition )
+ {
+     // Create the blocks to contain code in the structure of if/then/else
+     BasicBlock* then_bb = new BasicBlock(); 
+     BasicBlock* else_bb = new BasicBlock();
+     BasicBlock* exit_bb = new BasicBlock();
+ 
+     // Insert the branch instruction for the "if"
+     bb->getInstList().push_back( new BranchInst( then_bb, else_bb, condition ) );
+ 
+     // Set up the terminating instructions
+     then->getInstList().push_back( new BranchInst( exit_bb ) );
+     else->getInstList().push_back( new BranchInst( exit_bb ) );
+ 
+     // Fill in the then part .. details excised for brevity
+     this->fill_in( then_bb );
+ 
+     // Fill in the else part .. details excised for brevity
+     this->fill_in( else_bb );
+ 
+     // Return a block to the caller that can be filled in with the code
+     // that follows the if/then/else construct.
+     return exit_bb;
+ }
+ 
      
+ 
      Presumably in the foregoing, the calls to the "fill_in" method would add 
+ the instructions for the "then" and "else" parts. They would use the third part
+ of the idiom almost exclusively (inserting new instructions before the 
+ terminator). Furthermore, they could even recurse back to handle_if 
+ should they encounter another if/then/else statement, and it will just work.
      
+ 
      Note how cleanly this all works out. In particular, the push_back methods on
+ the BasicBlock's instruction list. These are lists of type 
+ Instruction (which is also of type Value). To create 
+ the "if" branch we merely instantiate a BranchInst that takes as 
+ arguments the blocks to branch to and the condition to branch on. The 
+ BasicBlock objects act like branch labels! This new 
+ BranchInst terminates the BasicBlock provided 
+ as an argument. To give the caller a way to keep inserting after calling 
+ handle_if, we create an exit_bb block which is
+ returned 
+ to the caller.  Note that the exit_bb block is used as the 
+ terminator for both the then_bb and the else_bb
+ blocks. This guarantees that no matter what else handle_if
+ or fill_in does, they end up at the exit_bb block.
+ 
      
+ 
      
+ 
+ 
      push_back Is Your Friend
      
+ 
      
+ 
      
+ One of the first things I noticed is the frequent use of the "push_back"
+ method on the various lists. This is so common that it is worth mentioning.
+ The "