search for: formatted_raw_ostream

Building on OS X 10.7.1 with the standard toolchain, I have seen the following linker warnings going back a number of versions in trunk whenever I build an executable linked with LLVM: ld: warning: direct access in llvm::fouts() to global weak symbol llvm::formatted_raw_ostream::~formatted_raw_ostream() means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. ld: warning: direct access in llvm::ferrs() to global weak symbol llvm::formatted_raw_ostream::~formatted...

...te: > Building on OS X 10.7.1 with the standard toolchain, I have seen the > following linker warnings going back a number of versions in trunk > whenever I build an executable linked with LLVM: > > ld: warning: direct access in llvm::fouts() to global weak > symbol llvm::formatted_raw_ostream::~formatted_raw_ostream() means the > weak symbol cannot be overridden at runtime. This was likely caused by > different translation units being compiled with different visibility > settings. > ld: warning: direct access in llvm::ferrs() to global weak > symbol llvm::formatted...

...ts into asm > output. This one > adds comment information to MachineInstructions and outputs it in the > generated AsmPrinters. This includes TableGen work to trigger the > comment > output in the right places. A couple of things are important to discuss: + dynamic_cast<formatted_raw_ostream &>(O) << Comment(*c); We're trying to eliminate rtti, please don't add new uses of it. Switching all of the asmprinter to statically use formatted_raw_ostream would be appropriate. +++ include/llvm/CodeGen/MachineInstr.h (working copy) @@ -46,6 +46,9 @@ MachineBasic...

Here's the first of several patches to get comments into asm output. This one adds comment information to MachineInstructions and outputs it in the generated AsmPrinters. This includes TableGen work to trigger the comment output in the right places. Please review and comment. -Dave -------------- next part -------------- A non-text attachment was

On Sunday 12 July 2009 18:56, Chris Lattner wrote: > A couple of things are important to discuss: > > + dynamic_cast<formatted_raw_ostream &>(O) << Comment(*c); > > We're trying to eliminate rtti, please don't add new uses of it. > Switching all of the asmprinter to statically use > formatted_raw_ostream would be appropriate. To separate comments, would it be ok to commit this bit as-is and follow it...

Hi, Compiling on PP64/FreeBSd, I get several of these: /usr/home/kparzysz/bld.lv/tools/llvm-mc/Release+Asserts/llvm-mc.o: In function `llvm::formatted_raw_ostream::~formatted_raw_ostream()': llvm-mc.cpp:(.text.startup.main+0xe4): undefined reference to `LLVMInitializeARM64TargetInfo' llvm-mc.cpp:(.text.startup.main+0x154): undefined reference to `LLVMInitializeARM64TargetMC' llvm-mc.cpp:(.text.startup.main+0x194): undefined reference to `LLVMI...

...> > adds comment information to MachineInstructions and outputs it in the > > generated AsmPrinters. This includes TableGen work to trigger the > > comment > > output in the right places. > > A couple of things are important to discuss: > > + dynamic_cast<formatted_raw_ostream &>(O) << Comment(*c); > > We're trying to eliminate rtti, please don't add new uses of it. > Switching all of the asmprinter to statically use > formatted_raw_ostream would be appropriate. I was attempting to reduce the number of files affected, but if you want thi...

...unning the code generator to test for a crash: <cbe>*** Debugging code generator crash! Error running tool: /usr/local/bin/llc -o bugpoint-test-program.bc.cbe.c -march=c -f bugpoint-test-program.bc llc: CBackend.cpp:487: llvm::raw_ostream&<unnamed>::CWriter::printSimpleType(llvm::formatted_raw_ostream&, const llvm::Type*, bool, const std::string&): Assertion `NumBits <= 128 && "Bit widths > 128 not implemented yet"' failed. 0 llc 0x09017572 1 llc 0x090173e7 2 0x0044a400 __kernel_sigreturn + 0 3 0x0044a424 __kernel_vsyscall +...

...This is super useful when trying to debug very large codes. I have had debug output consume GBs of disk space. This avoids that problem but it only works if all current debug output goes to the new stream. As I said, by default there is no change in behavior. dbgs() works very similarly to the formatted_raw_ostream in that it uses errs() underneath to do the actual output and only does the circular buffering and delayed output if requested. > > My intent is to have dbgs() == errs() when debug mode is disabled. > > Do you know why DOUT was removed? Yes and no. I know the reasons given for remo...

...a crash: <cbe>*** Debugging code > generator crash! > > Error running tool: > /usr/local/bin/llc -o bugpoint-test-program.bc.cbe.c -march=c -f > bugpoint-test-program.bc > llc: CBackend.cpp:487: > llvm::raw_ostream&<unnamed>::CWriter::printSimpleType(llvm::formatted_raw_ostream&, > const llvm::Type*, bool, const std::string&): Assertion `NumBits <= 128 > && "Bit widths > 128 not implemented yet"' failed. try the -llc-safe option. It will use llc to compile code rather than gcc, and llc does handle arbitrary sized integers. Ci...

...ying to debug > very large codes. I have had debug output consume GBs of disk space. > This avoids that problem but it only works if all current debug > output goes to the new stream. > > As I said, by default there is no change in behavior. dbgs() works > very similarly to the formatted_raw_ostream in that it uses errs() > underneath to do the actual output and only does the circular buffering > and delayed output if requested. It seems like there is better ways to handle this (i.e. split the input into smaller chunks) but I'm not opposed to the general idea. >> The problem...

...OBJ) { printf( "Error creating output file\n" ); return false; } // Build up all of the passes that we want to do to the module. PassManager PM; PM.add(new TargetData(module)); // Override default to generate verbose assembly. Target.setAsmVerbosityDefault(true); { formatted_raw_ostream FOS_S(Out_S->os()); formatted_raw_ostream FOS_OBJ(Out_OBJ->os()); // Ask the target to add backend passes as necessary. bool NoVerify = true; if (Target.addPassesToEmitFile(PM, FOS_S, FileType_S, NoVerify)) { printf( "target does not support generation of this file type!...

...016ec3b1 llvm::PMTopLevelManager::schedulePass(llvm::Pass*) + 983 9 llc 0x00000000016f2990 10 llc 0x00000000016f0e91 llvm::PassManager::add(llvm::Pass*) + 39 11 llc 0x00000000011c119b llvm::LLVMTargetMachine::addPassesToEmitFile(llvm::PassManagerBase&, llvm::formatted_raw_ostream&, llvm::TargetMachine::CodeGenFileType, bool, void const*, void const*) + 1705 12 llc 0x00000000008c08b5 13 llc 0x00000000008bf8cd main + 237 14 libc.so.6 0x00007f986687576d __libc_start_main + 237 15 llc 0x00000000008bf229 ===== What my modulePass doe...

...size and restore it in > > releaseStream? > > Oh, I think this code is just wrong. I'll rework it. No, it's right. It's not transferring the buffer at all. It's just setting the buffer size of the held stream when we release it. This code is identical to the code in formatted_raw_ostream. -Dave

On Jul 13, 2009, at 9:31 AM, David Greene wrote: >> A couple of things are important to discuss: >> >> + dynamic_cast<formatted_raw_ostream &>(O) << Comment(*c); >> >> We're trying to eliminate rtti, please don't add new uses of it. >> Switching all of the asmprinter to statically use >> formatted_raw_ostream would be appropriate. > > I was attempting to reduce the number of files affe...

...have to take the opcode into account. > It's a > lot of work, at the very least. Vector vs scalar should also be pretty simple, just look at the reg class and the VT's involved. It should all be target independent, probably less than a dozen lines. After the conversion to formatted_raw_ostream, we can discuss the best way to do this. It would be helpful if you gave an example of the output you wanted. >>> - Tag instructions with an ID of the tblgen pattern that generated >>> them. This >>> is super useful for debugging. >> >> this would also be...

...etPassConfig::addCGRegAlloc(llvm::CallGraphSCCPass*) + 47 8 llc 0x0000000000f3d7df llvm::TargetPassConfig::addMachinePasses() + 719 9 llc 0x0000000000e5a3af 10 llc 0x0000000000e5994c llvm::LLVMTargetMachine::addPassesToEmitFile(llvm::PassManagerBase&, llvm::formatted_raw_ostream&, llvm::TargetMachine::CodeGenFileType, bool, void const*, void const*) + 92 11 llc 0x00000000005f6002 main + 4946 12 libc.so.6 0x00007f020a98a76d __libc_start_main + 237 13 llc 0x00000000005f4bd1 Stack dump: 0. Program arguments: llc --debug -cgregalloc=cg Abor...

On Oct 31, 2012, at 1:41 PM, Madhusudan C.S <madhusudancs at gmail.com> wrote: > I have spent last 4 weeks trying to figure out how to implement > Interprocedural Register Allocation. I must admit that I was really > overwhelmed with LLVM's codebase while trying to figure this out :) > There is so much to know! I think I have reached a point where I > have some sort of

On Monday 13 July 2009 11:40, Chris Lattner wrote: > > I was attempting to reduce the number of files affected, but if you > > want this change I'll go ahead and do it. > > Makes sense, thanks. Please do it as a separate patch from the other > changes though since it will be large and mechanical. Ok, no problem. > > - Tag instructons with source line information

...t.setAsmVerbosityDefault(true); //if (RelaxAll) { // if (FileType != TargetMachine::CGFT_ObjectFile) // errs() << argv[0] // << ": warning: ignoring -mc-relax-all because filetype != obj"; // else // Target.setMCRelaxAll(true); //} //{ // formatted_raw_ostream FOS(Out->os()); // Ask the target to add backend passes as necessary. // if (Target.addPassesToEmitFile(PM, FOS, FileType, OLvl, NoVerify)) { // errs() << argv[0] << ": target does not support generation of this" // << " file type!\n&quot...