search for: isdebugged

...t loop, it is nice to be able to tell which callbacks are "debugged" currently, either via `debug()` or `debugonce()`. Gabor > Best, > Tomas > On 04/28/2018 01:57 PM, G?bor Cs?rdi wrote: > > debugonce() sets a different flag (RSTEP), and this is not queried by > > isdebugged(), and it is also not unset by undebug(). > > > > Is this expected? If yes, is there a way to query and unset the RSTEP flag > > from R code? > > > > ? f <- function() { } > > ? debugonce(f) > > ? isdebugged(f) > > [1] FALSE > > > > ? u...

debugonce() sets a different flag (RSTEP), and this is not queried by isdebugged(), and it is also not unset by undebug(). Is this expected? If yes, is there a way to query and unset the RSTEP flag from R code? ? f <- function() { } ? debugonce(f) ? isdebugged(f) [1] FALSE ? undebug(f) Warning message: In undebug(f) : argument is not being debugged ? f() debugging in: f(...

...a breakpoint in say gdb. undebugonce() would make no sense in this context, because it is done implicitly. undebugonce() would only make sense if you called debugonce() but then changed your mind before running that function, but, that does not seem like a common use case worth supporting. Re isdebugged(), I think the current semantics is already problematic. The name of the function and its existence makes it tempting to believe it tells us whether a given function is being run in a debugger currently, but it is not what isdebugged() does, the debugger can be entered by other means, including...

> > Is it a function to list all functions set with debug() or trace()? > Best, > Phillipe, As Thomas noted, R does not currently allow testing whether a function is being debugged. However, it is possible to add this feature. I'm attaching a patch to the end of this message that adds a new internal function "isdebug" which tests if its (only) argument is a

This is kind of a dumb question: I know you can use isdebugged() to find out if a specific function is flagged for debugging, but is there a way to list all the functions that are flagged for debugging? Thanks, Andrew [[alternative HTML version deleted]]

Hi list, Is there a function that can let me know which functions are being debugged? I know I'm probably not doing a very good job of keeping track of things, but it does get messier when you dig into different layers of a function. I know there is "isdebugged", but it only works on one function at a time. Thanks! ...Tao [[alternative HTML version deleted]]

Hi Quentin, On 08/19/14 18:58, Quentin Colombet wrote: [...] > It seems that you will have to debug further the *** Bad machine code: Instruction loads from dead spill slot *** before we can be of any help. Yes, I've done some more digging. Sorry for the long mail... I get: Inline spilling aN40_0_7:%vreg1954 [5000r,5056r:0)[5056r,5348r:1) 0 at 5000r 1 at 5056r At this point I have

debug(fun) marks "fun" for debugging, it makes sure that whenever "fun" is called, the debugger is entered undebug(fun) removes this mark; it won't stop any current debugging of that function isdebugged(fun) tells whether this mark is set or not; it does not tell whether "fun" is currently running in a debugger/browser debugonce(func) adds a different mark to the function, one that makes sure the first time "fun" is called, the debugger is entered; this is the same as when...

...tionWithTrace" # Original definition: # function() "hello" # # ## (to see the tracing code, look at body(object)) `untrace()` has the same behavior. This is inconsistent with how debug works : foo <- function() "hello" debug2 <- function(fun) debug(fun) debug2(foo) isdebugged(foo) # [1] TRUE This can be worked around by defining : trace2 <- function(fun) eval.parent(substitute(trace(fun, quote(print("!!!"))) but I believe the current behavior is undesired and it'd be better to make it behave as `debug()`, or to throw an error. Best, Antoine [[alt...

Hi Quentin, On 08/15/14 19:01, Quentin Colombet wrote: [...] >> The question is: How should true subregister definitions be >> expressed so that they do not interfere with each other? See the >> detailed problem description below. > > We do have a limitation in our current liveness tracking for > sub-register. Therefore, I am not sure that is possible. > >

...## (to see the tracing code, look at body(object)) >> >> `untrace()` has the same behavior. >> >> This is inconsistent with how debug works : >> >> foo <- function() "hello" >> debug2 <- function(fun) debug(fun) >> debug2(foo) >> isdebugged(foo) >> # [1] TRUE >> >> This can be worked around by defining : >> >> trace2 <- function(fun) eval.parent(substitute(trace(fun, >> quote(print("!!!"))) >> >> but I believe the current behavior is undesired and it'd be better to make...

2015-04-28 10:15 GMT-07:00 Hal Finkel <hfinkel at anl.gov>: > > ------------------------------ > > *From: *"Alex L" <arphaman at gmail.com> > *To: *"LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > *Sent: *Tuesday, April 28, 2015 11:56:42 AM > *Subject: *[LLVMdev] RFC: Machine Level IR text-based serialization format > >

Hi,   For a custom target, there is a pass to perform memory dependence analysis, where, i need to get memory pointer for "load instruction". I want to check the pointer alias behavior. I am getting this by considering the memoperands for the load instruction.   For "load instruction", Machine Instruction dumps as below:   vr12<def> = LD_Iri %vr2<kill>, 0;

To get this out first: I'd love to have a way to serialize machine-IR! I often spend a lot of time trying to create .ll files in a way that the machine-IR still looks a certain way when it finally hits the relevant passes in codegen. It would be so much easier to just specify the machine IR immediately before the pass I'm interested in. For that use case it is worth keeping the following

Hi, I wanted to see the non-debug uses of register 0 (Noreg) and so, I wrote the following piece of code. ***** MRI = &MF.getRegInfo(); if (!MRI->use_nodbg_empty(0)) { for (MachineRegisterInfo::use_nodbg_iterator ri = MRI->use_nodbg_begin(0), re = MRI->use_nodbg_end(); ri != re; ++ri) { MachineInstr *UseMI = &*ri; UseMI->dump ();

...ect)) > >> > >> `untrace()` has the same behavior. > >> > >> This is inconsistent with how debug works : > >> > >> foo <- function() "hello" > >> debug2 <- function(fun) debug(fun) > >> debug2(foo) > >> isdebugged(foo) > >> # [1] TRUE > >> > >> This can be worked around by defining : > >> > >> trace2 <- function(fun) eval.parent(substitute(trace(fun, > >> quote(print("!!!"))) > >> > >> but I believe the current behavior is u...

> On Aug 24, 2015, at 4:46 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Here is the snippet that matters: > > void > InstrEmitter::AddRegisterOperand(MachineInstrBuilder &MIB, > SDValue Op, > unsigned IIOpNum, > const MCInstrDesc *II, >

Quentin, This is the issue. Somewhere prior to the constrainRegClass, it's assigning the GPRBase sub class of GPR to the MOV instruction, so it can't constrain it to Base and hence has to add the COPY. Now I just need to find out why it is ignoring the TableGen defined GPRBase for the MOV MI in favor of it's sub class GPR. Thanks. On Mon, Aug 24, 2015 at 8:34 PM, Ryan Taylor

Hi Ryan, > On Aug 24, 2015, at 6:49 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Quentin, > > I apologize for the spamming here but in getVR (where VReg is assigned an RC), it calls: > > const TargetRegisterClass *RC = TLI->getRegClassFor(Op.getSimpleValueType()); > VReg = MRI->createVirtualRegister(RC); > > My question is why is it using the

> On Aug 24, 2015, at 1:30 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I'm trying to do something like this: > > // Dst = NewVReg's reg class > // *II = MCInstrDesc > // IIOpNum = II Operand Num > > if (TRI->getCommonSubClass(DstRC, TRI->getRegClass(II->OpInfo[IIOpNum].RegClass)) == DstRC) > MRI->setRegClass(VReg, DstRC); >