Bjorn De Sutter
2012-Nov-27 07:47 UTC
[LLVMdev] strange dbgs() behavior: unable to print floats in machine backend
Hi, that solved my problem on trunk as well, thanks. Strange that you have to include this though. Bjorn On 27 Nov 2012, at 00:00, Daniel Prokesch <daniel.prokesch at gmail.com> wrote:> Hi, > > I accidentally stumbled upon your post. > I observed similar behaviour whenever I did not include > > #include "llvm/Support/Debug.h" > #include "llvm/Support/raw_ostream.h" > > I'm working on release 3.1 though. > > hth, Daniel > > On 11/26/2012 03:00 PM, Bjorn De Sutter wrote: >> Hi, >> >> I am trying to debug my backend, and observe very strange behavior with dbgs(): >> >> In the IfConverter, I have added two debugging lines that print floating-point numbers for the sake of demonstration that such printing works fine. >> >> bool MeetIfcvtSizeLimit(MachineBasicBlock &BB, >> unsigned Cycle, unsigned Extra, >> const BranchProbability &Prediction) const { >> >> dbgs() << "OOPS " << 1.14 << "\n"; >> bool flag = Cycle > 0 && TII->isProfitableToIfCvt(BB, Cycle, Extra, >> Prediction); >> dbgs() << "OOPS " << 1.15 << "\n"; >> return flag; >> } >> >> This method invokes the backend method >> >> bool ADRESInstrInfo::isProfitableToIfCvt(MachineBasicBlock &MBB, unsigned NumCycles, unsigned ExtraPredCycles, >> const BranchProbability &Probability) const { >> dbgs() << "OOPS " << 1.16 << "\n"; >> } >> >> This invocation works as it should (verified with gdb). But when I execute this code fragment, I get >> >> OOPS 1.140000e+00 >> OOPS %physreg1 >> OOPS 1.150000e+00 >> >> So suddenly in the machine backend, the dbgs() ostream (which is still the very same ostream as in the IfConverter, I checked the address with gdb) prints floating point numbers as if they are physical registers. Any idea what is going on or how I can force floating-point numbers to be printed in the backend code? I want to do that to tune my if-predication heuristics ... >> >> By the way, when I step through the isProfitableToIfCvt method, rather than invoking a <<-operator in an ostream class, the constructor of the Twine class is invoked ... >> >> Thanks, >> >> Bjorn De Sutter >> Computer Systems Lab >> Ghent University >> >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Craig Topper
2012-Nov-27 08:05 UTC
[LLVMdev] strange dbgs() behavior: unable to print floats in machine backend
Can you try making the constructor "explicit" for PrintReg in include/llvm/Target/TargetRegisterInfo.h. I think you were getting an implicit conversion there which should probably be fixed anyway. On Mon, Nov 26, 2012 at 11:47 PM, Bjorn De Sutter < bjorn.desutter at elis.ugent.be> wrote:> Hi, > > that solved my problem on trunk as well, thanks. Strange that you have to > include this though. > > Bjorn > > On 27 Nov 2012, at 00:00, Daniel Prokesch <daniel.prokesch at gmail.com> > wrote: > > > Hi, > > > > I accidentally stumbled upon your post. > > I observed similar behaviour whenever I did not include > > > > #include "llvm/Support/Debug.h" > > #include "llvm/Support/raw_ostream.h" > > > > I'm working on release 3.1 though. > > > > hth, Daniel > > > > On 11/26/2012 03:00 PM, Bjorn De Sutter wrote: > >> Hi, > >> > >> I am trying to debug my backend, and observe very strange behavior with > dbgs(): > >> > >> In the IfConverter, I have added two debugging lines that print > floating-point numbers for the sake of demonstration that such printing > works fine. > >> > >> bool MeetIfcvtSizeLimit(MachineBasicBlock &BB, > >> unsigned Cycle, unsigned Extra, > >> const BranchProbability &Prediction) const { > >> > >> dbgs() << "OOPS " << 1.14 << "\n"; > >> bool flag = Cycle > 0 && TII->isProfitableToIfCvt(BB, > Cycle, Extra, > >> Prediction); > >> dbgs() << "OOPS " << 1.15 << "\n"; > >> return flag; > >> } > >> > >> This method invokes the backend method > >> > >> bool ADRESInstrInfo::isProfitableToIfCvt(MachineBasicBlock &MBB, > unsigned NumCycles, unsigned ExtraPredCycles, > >> const BranchProbability > &Probability) const { > >> dbgs() << "OOPS " << 1.16 << "\n"; > >> } > >> > >> This invocation works as it should (verified with gdb). But when I > execute this code fragment, I get > >> > >> OOPS 1.140000e+00 > >> OOPS %physreg1 > >> OOPS 1.150000e+00 > >> > >> So suddenly in the machine backend, the dbgs() ostream (which is still > the very same ostream as in the IfConverter, I checked the address with > gdb) prints floating point numbers as if they are physical registers. Any > idea what is going on or how I can force floating-point numbers to be > printed in the backend code? I want to do that to tune my if-predication > heuristics ... > >> > >> By the way, when I step through the isProfitableToIfCvt method, rather > than invoking a <<-operator in an ostream class, the constructor of the > Twine class is invoked ... > >> > >> Thanks, > >> > >> Bjorn De Sutter > >> Computer Systems Lab > >> Ghent University > >> > >> > >> > >> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121127/bc19e20e/attachment.html>
Bjorn De Sutter
2012-Nov-27 09:38 UTC
[LLVMdev] strange dbgs() behavior: unable to print floats in machine backend
Hi Craig, I updated from the trunk some minutes ago, and thus got the "explicit". PrintReg constructor. When I do not include raw_ostream.h after including Debug.h in the backend cpp files, I now get compilation errors, not only when trying to print floats but also in other places. For example, for the code bool ADRESRegisterInfo::hasReservedCallFrame(const MachineFunction &MF) const { dbgs() << "hasReservedCallFrame() = " << !MF.getFrameInfo()->hasVarSizedObjects() << "\n"; return !MF.getFrameInfo()->hasVarSizedObjects(); } I get llvm[0]: Compiling ADRESRegisterInfo.cpp for Debug+Asserts build /work/llvm/trunk/llvm/lib/Target/ADRES/ADRESRegisterInfo.cpp: In member function 'bool llvm::ADRESRegisterInfo::hasReservedCallFrame(const llvm::MachineFunction&) const': /work/llvm/trunk/llvm/lib/Target/ADRES/ADRESRegisterInfo.cpp:38:83: error: no match for 'operator<<' in 'llvm::operator<<((* & llvm::dbgs()), (* & llvm::Twine(((const char*)"hasReservedCallFrame() = ")))) << !(& MF)->llvm::MachineFunction::getFrameInfo()->llvm::MachineFrameInfo::hasVarSizedObjects()' /work/llvm/trunk/llvm/lib/Target/ADRES/ADRESRegisterInfo.cpp:38:83: note: candidates are: /work/llvm/trunk/llvm/include/llvm/Type.h:412:28: note: llvm::raw_ostream& llvm::operator<<(llvm::raw_ostream&, llvm::Type&) /work/llvm/trunk/llvm/include/llvm/Type.h:412:28: note: no known conversion for argument 2 from 'bool' to 'llvm::Type&' /work/llvm/trunk/llvm/include/llvm/ADT/Twine.h:516:23: note: llvm::raw_ostream& llvm::operator<<(llvm::raw_ostream&, const llvm::Twine&) /work/llvm/trunk/llvm/include/llvm/ADT/Twine.h:516:23: note: no known conversion for argument 2 from 'bool' to 'const llvm::Twine&' /work/llvm/trunk/llvm/include/llvm/CodeGen/MachineOperand.h:685:21: note: llvm::raw_ostream& llvm::operator<<(llvm::raw_ostream&, const llvm::MachineOperand&) /work/llvm/trunk/llvm/include/llvm/CodeGen/MachineOperand.h:685:21: note: no known conversion for argument 2 from 'bool' to 'const llvm::MachineOperand&' /work/llvm/trunk/llvm/include/llvm/Value.h:320:21: note: llvm::raw_ostream& llvm::operator<<(llvm::raw_ostream&, const llvm::Value&) /work/llvm/trunk/llvm/include/llvm/Value.h:320:21: note: no known conversion for argument 2 from 'bool' to 'const llvm::Value&' /work/llvm/trunk/llvm/include/llvm/CodeGen/MachineInstr.h:1017:21: note: llvm::raw_ostream& llvm::operator<<(llvm::raw_ostream&, const llvm::MachineInstr&) /work/llvm/trunk/llvm/include/llvm/CodeGen/MachineInstr.h:1017:21: note: no known conversion for argument 2 from 'bool' to 'const llvm::MachineInstr&' /work/llvm/trunk/llvm/include/llvm/CodeGen/MachineBasicBlock.h:621:14: note: llvm::raw_ostream& llvm::operator<<(llvm::raw_ostream&, const llvm::MachineBasicBlock&) /work/llvm/trunk/llvm/include/llvm/CodeGen/MachineBasicBlock.h:621:14: note: no known conversion for argument 2 from 'bool' to 'const llvm::MachineBasicBlock&' /work/llvm/trunk/llvm/include/llvm/Target/TargetRegisterInfo.h:885:28: note: llvm::raw_ostream& llvm::operator<<(llvm::raw_ostream&, const llvm::PrintReg&) /work/llvm/trunk/llvm/include/llvm/Target/TargetRegisterInfo.h:885:28: note: no known conversion for argument 2 from 'bool' to 'const llvm::PrintReg&' /work/llvm/trunk/llvm/include/llvm/Target/TargetRegisterInfo.h:908:28: note: llvm::raw_ostream& llvm::operator<<(llvm::raw_ostream&, const llvm::PrintRegUnit&) /work/llvm/trunk/llvm/include/llvm/Target/TargetRegisterInfo.h:908:28: note: no known conversion for argument 2 from 'bool' to 'const llvm::PrintRegUnit&' Including the raw_ostream.h fixes this, but that is not a thing I should have to do, right? Best, Bjorn On 27 Nov 2012, at 09:05, Craig Topper <craig.topper at gmail.com> wrote:> Can you try making the constructor "explicit" for PrintReg in include/llvm/Target/TargetRegisterInfo.h. I think you were getting an implicit conversion there which should probably be fixed anyway. > > On Mon, Nov 26, 2012 at 11:47 PM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > Hi, > > that solved my problem on trunk as well, thanks. Strange that you have to include this though. > > Bjorn > > On 27 Nov 2012, at 00:00, Daniel Prokesch <daniel.prokesch at gmail.com> wrote: > > > Hi, > > > > I accidentally stumbled upon your post. > > I observed similar behaviour whenever I did not include > > > > #include "llvm/Support/Debug.h" > > #include "llvm/Support/raw_ostream.h" > > > > I'm working on release 3.1 though. > > > > hth, Daniel > > > > On 11/26/2012 03:00 PM, Bjorn De Sutter wrote: > >> Hi, > >> > >> I am trying to debug my backend, and observe very strange behavior with dbgs(): > >> > >> In the IfConverter, I have added two debugging lines that print floating-point numbers for the sake of demonstration that such printing works fine. > >> > >> bool MeetIfcvtSizeLimit(MachineBasicBlock &BB, > >> unsigned Cycle, unsigned Extra, > >> const BranchProbability &Prediction) const { > >> > >> dbgs() << "OOPS " << 1.14 << "\n"; > >> bool flag = Cycle > 0 && TII->isProfitableToIfCvt(BB, Cycle, Extra, > >> Prediction); > >> dbgs() << "OOPS " << 1.15 << "\n"; > >> return flag; > >> } > >> > >> This method invokes the backend method > >> > >> bool ADRESInstrInfo::isProfitableToIfCvt(MachineBasicBlock &MBB, unsigned NumCycles, unsigned ExtraPredCycles, > >> const BranchProbability &Probability) const { > >> dbgs() << "OOPS " << 1.16 << "\n"; > >> } > >> > >> This invocation works as it should (verified with gdb). But when I execute this code fragment, I get > >> > >> OOPS 1.140000e+00 > >> OOPS %physreg1 > >> OOPS 1.150000e+00 > >> > >> So suddenly in the machine backend, the dbgs() ostream (which is still the very same ostream as in the IfConverter, I checked the address with gdb) prints floating point numbers as if they are physical registers. Any idea what is going on or how I can force floating-point numbers to be printed in the backend code? I want to do that to tune my if-predication heuristics ... > >> > >> By the way, when I step through the isProfitableToIfCvt method, rather than invoking a <<-operator in an ostream class, the constructor of the Twine class is invoked ... > >> > >> Thanks, > >> > >> Bjorn De Sutter > >> Computer Systems Lab > >> Ghent University > >> > >> > >> > >> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > ~Craig-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121127/eeea71ce/attachment.html>
Possibly Parallel Threads
- [LLVMdev] strange dbgs() behavior: unable to print floats in machine backend
- [LLVMdev] strange dbgs() behavior: unable to print floats in machine backend
- [LLVMdev] strange dbgs() behavior: unable to print floats in machine backend
- [LLVMdev] llc debug info
- [LLVMdev] [PATCH] dbgs() Use