thr3ads.net - llvm dev - [LLVMdev] strange dbgs() behavior: unable to print floats in machine backend [Nov 2012]

If this information is useful, please help other people find it:
Share via:

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

head link

[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

head link

[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>

Reasonably Related Threads

Search for more reasonably related threads

llvm dev - Nov 2012 - [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] strange dbgs() behavior: unable to print floats in machine backend

Reasonably Related Threads