similar to: [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

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

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)

It takes a lot of sweat to generate a composite plot with R ... sigh. I though I was almost done when I met the umpteenth hurdle. I cannot place a nice title on the 2nd plot (raw signal) on the layout. I do not have control on where either the "main" option of "plot" function, or "title", place the text string which keeps dysplaying chopped from above. I also tried

Hi all I was wondering if someone could help me. I have to estimate some parameters, so I am using the function nlm. Inside this function I have to integrate, hence I am using the function adapt. I don't understand why it is giving the following warnings: At the beginning: Warning: a final empty element has been omitted the part of the args list of 'c' being evaluated was:

Hi all, If you have an out of tree target and use the IfConverter be aware of a new API call "getPredictationCost“ that you might want to implement: After commit r191671: IfConverter: Use TargetSchedule for instruction latencies For targets that have instruction itineraries this means no change. Targets that move over to the new schedule model will be able to use the new

Hello! The if-converter tries to match 'Simple' patterns looking like this: // Simple (split, no rejoin): // EBB // | \_ // | | // | TBB---> exit // | // FBB The IfConverter::ValidSimple method (lib/CodeGen/IfConversion.cpp:461) checks if TBB matches this pattern. It basically does this by simply checking if AnalyseBranch fails on

Hi Jacob, At this point, I suspect there is a problem with maintaining liveness information during branch folding. Here is what I see: I have a basic block ready for branch optimization, that computes a predicate p10 on which a conditional branch depends. Notice that this is in the stage with physical registers. BB#2: derived from LLVM BB %while.cond.preheader Live Ins: %R3 %R5

On Tue, Jan 10, 2017 at 2:31 AM, Peter A Jonsson <pj at sics.se> wrote: > Hi Kyle, > > my apologies for mailing you directly but it seems new user creation is > disabled on the llvm bugzilla. > > We sometime lose edges during IfConversion of diamonds and it’s not > obvious how to reproduce on an upstream target. The documentation for > HasFallThrough says *may*

Dear all, I use the clang frontend to produce the control flow graph of a C program through this command: clang -Xclang -analyze -Xclang -analyzer-checker=debug.DumpCFG test.c The produced information contains all the basic blocks identified by labels, e.g. B1, B2, etc. along with their predecessors and successors. Is there a way to get the starting address of each of these basic block? I would

Evan, et al., I've come across a small issue when using the if conversion pass in PPC to generate conditional returns. Here's a small example: ** Before if conversion ** BB#0: derived from LLVM BB %entry %R3<def> = LI 0 %CR0<def> = CMPLWI %R3, 0 BCC 68, %CR0, <BB#3> Successors according to CFG: BB#3(16) BB#1(16) BB#1: derived from LLVM BB

On Wed, Oct 31, 2012 at 09:13:43PM +0100, Bjorn De Sutter wrote: > Hi all, > > I am working on a CGRA backend (something like a 2D VLIW), and we also absolutely need predication. I extended the IfConversion pass to allow it to be executed multiple times and to predicate already predicated code. This is necessary to predicate code with nested conditional statements. At this point, we

On Dec 17, 2009, at 4:08 PM, David Greene wrote: > Here's an example patch of how dbgs() will be used. Essentially I > will > replace uses of errs() with dbgs(). I believe this is the correct > thing > to do because: > > - With #define NDEBUG, dbgs() == errs() > > - With debugging and -debug-buffer-size=0 (the default), dbgs() just > passes output to

On Dec 21, 2009, at 8:42 AM, David Greene wrote: > On Monday 21 December 2009 10:14, Török Edwin wrote: >> On 2009-12-21 18:06, David Greene wrote: >>> On Saturday 19 December 2009 00:16, Chris Lattner wrote: >>>>> Or I think I can just assume (Yikes!) that if the signal handler is >>>>> invoked it will really be a circular_raw_ostream since the

When using "DEBUG( dbgs() << "whatever" );" Do I need to insert a line terminator. Like "DEBUG( dbgs() << "whatever" << std::endl );" Thanks Jeff Kunkel

On Dec 17, 2009, at 4:02 PM, David Greene wrote: > Here's the patch to provide dbgs(). By default it works just like > errs(). > When -debug-buffer-size=N (N > 0) is set, it buffers output sent to > it and > dumps it at program termination via a signal handler. > > Please review. Thanks! > > -Dave > > Index:

On Dec 18, 2009, at 6:36 PM, David Greene wrote: >>> +// Signal handlers - dump debug output on termination. >>> +static void debug_user_sig_handler(void *Cookie) >>> +{ >>> + llvm::circular_raw_ostream *logout = >>> + dynamic_cast<llvm::circular_raw_ostream *>(&llvm::dbgs()); >> >> Please do not use dynamic_cast, we're

On 2009-12-21 18:06, David Greene wrote: > On Saturday 19 December 2009 00:16, Chris Lattner wrote: > > >>> Or I think I can just assume (Yikes!) that if the signal handler is >>> invoked it will really be a circular_raw_ostream since the handler >>> should (!) only be set up in debug mode. >>> >>> That scares me a bit, though. >>>

On Monday 21 December 2009 10:14, Török Edwin wrote: > On 2009-12-21 18:06, David Greene wrote: > > On Saturday 19 December 2009 00:16, Chris Lattner wrote: > >>> Or I think I can just assume (Yikes!) that if the signal handler is > >>> invoked it will really be a circular_raw_ostream since the handler > >>> should (!) only be set up in debug mode. >

On Friday 18 December 2009 19:56, Chris Lattner wrote: > > +// -debug-buffer-size - This is a command line op0tion to set the > > size > > +// of the debug stream circular buffer. The value is the number of > > +// characters to save. > > +static cl::opt<unsigned> > > +DebugBufferSize("debug-buffer-size", > > +