search for: reg_iterator

...PC/2008-03-18-RegScavengerAssert.ll test/CodeGen/X86/x86-64-ret0.ll Date: Friday 28 March 2008 16:34 From: David Greene <dag at cray.com> To: llvm-commits at cs.uiuc.edu Cc: Chris Lattner <clattner at apple.com> On Tuesday 18 March 2008 23:59, Chris Lattner wrote: > How about using reg_iterators to do this? I assume this only applies > to vregs. If you walk the use_iterator list for the register, you can > very efficiently discard uses in other blocks (check User->getparent() > == MBB). Any uses within the same block are either a) in phi nodes, > in which case they are a...

On Monday 31 March 2008 18:55, Chris Lattner wrote: > On Mon, 31 Mar 2008, Evan Cheng wrote: > >> I just discovered that def_itterator (and presumably, reg_iterator) > >> doesn't > >> include implicit defs, for example at function calls for caller-save > >> physical > >> registers. Guh. I'm not sure if it should or not, but it's certainly > >> necessary information in some cases. Is this expected beha...

On Mon, 31 Mar 2008, Evan Cheng wrote: >> I just discovered that def_itterator (and presumably, reg_iterator) >> doesn't >> include implicit defs, for example at function calls for caller-save >> physical >> registers. Guh. I'm not sure if it should or not, but it's certainly >> necessary information in some cases. Is this expected behavior, or an >> over...

...; > > For non-SSA values, is there some indication of which defs reach which > > uses? I don't need this right now but I can imagine using it in the > > future. > > The reg def/kill/dead flags are all that there is. I just discovered that def_itterator (and presumably, reg_iterator) doesn't include implicit defs, for example at function calls for caller-save physical registers. Guh. I'm not sure if it should or not, but it's certainly necessary information in some cases. Is this expected behavior, or an oversight?...

On Mar 30, 2008, at 11:17 AM, David Greene wrote: > I'm forwarding this to llvmdev so it doesn't get lost in the sea of > commits... reg_iterators are independent of SSA or not. The basic issue is that if you loop over uses or defs of a register, it will return *all* the uses/defs of that register in the current function. If the value is SSA form, it is reasonable to say "give me the first def" and expect it to be the onl...

On Sunday 30 March 2008 01:30:40 pm Chris Lattner wrote: > On Mar 30, 2008, at 11:17 AM, David Greene wrote: > > I'm forwarding this to llvmdev so it doesn't get lost in the sea of > > commits... > > reg_iterators are independent of SSA or not. The basic issue is that > if you loop over uses or defs of a register, it will return *all* the > uses/defs of that register in the current function. If the value is > SSA form, it is reasonable to say "give me the first def" and expect > it t...

...re some indication of which defs reach >>> which >>> uses? I don't need this right now but I can imagine using it in the >>> future. >> >> The reg def/kill/dead flags are all that there is. > > I just discovered that def_itterator (and presumably, reg_iterator) > doesn't > include implicit defs, for example at function calls for caller-save > physical > registers. Guh. I'm not sure if it should or not, but it's certainly > necessary information in some cases. Is this expected behavior, or an > oversight? MachineRegis...

Hi folks, I would like to find out the machine instructions that use some given registers in the reverse order, and I came across these iterators (use_iterator/reg_iterator). However, there are two things I noticed: 1) These iterators seem to traverse the machine function a bit differently from what I get from the machine function dump. In other words, the use_iterator list is not constructed in the same order as the machine function? Maybe from the order that DAG is...

Thanks Quentin. I'm trying to examine from the operands of the return instruction, and then to get the last assignment of those. I thought use_iterator/reg_iterator may suit better than just loop through the machine basicblock in the reverse order. Cheng-Chih On Thu, Sep 25, 2014 at 1:51 PM, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Cheng-Chih, > > On Sep 25, 2014, at 9:14 AM, Yang, Cheng-Chih <Cheng-Chih.Yang at amd.com> &g...

On Mar 30, 2008, at 10:42 PM, David A. Greene wrote: >> SSA form, it is reasonable to say "give me the first def" and expect >> it to be the only def. For multiply defined values like physregs, >> this is not true, because the reg can have multiple defs. > > Gotcha. This is exactly what I want. Thanks for the explanation. > > For non-SSA values, is there

On Mar 31, 2008, at 4:55 PM, Chris Lattner wrote: > On Mon, 31 Mar 2008, Evan Cheng wrote: >>> I just discovered that def_itterator (and presumably, reg_iterator) >>> doesn't >>> include implicit defs, for example at function calls for caller-save >>> physical >>> registers. Guh. I'm not sure if it should or not, but it's >>> certainly >>> necessary information in some cases. Is this exp...

On Tue, 1 Apr 2008, David Greene wrote: > On Tuesday 01 April 2008 10:47, David Greene wrote: >>> reg iterators will return everything that is in the function. If the >>> implicit operands haven't been added to the machieninstrs yet, then they >>> won't be returned. >> >> Hmm...this is definitely NOT true in my copy. During register allocation

On Tuesday 01 April 2008 10:47, David Greene wrote: > > reg iterators will return everything that is in the function. If the > > implicit operands haven't been added to the machieninstrs yet, then they > > won't be returned. > > Hmm...this is definitely NOT true in my copy. During register allocation > these implicit defs are not returned. By then the

Is there any way to discover whether a particular operand of a MachineInst participates in addressing? That is, if the MachineInst references memory, can I tell, given an operand, whether that operand is part of the address calculation for the instruction? Also, is there any reasonable way to get the set of machine instructions to which the output(s) of some machine instruction flows? The

...the rest of the live > range and see > if the output of the defining instruction is used. On mainline, you can use the MachineRegisterInfo class (not MRegisterInfo) to walk all uses and defs (or just one class of them) of any register. Use def_iterator (defs) use_iterator (uses) or reg_iterator (both) to get all uses/defs of a particular register, physical or virtual. -Chris

...> > calculation for the instruction? > > Nope, not that I know of. Ok. > On mainline, you can use the MachineRegisterInfo class (not > MRegisterInfo) to walk all uses and defs (or just one class of them) > of any register. Use def_iterator (defs) use_iterator (uses) or > reg_iterator (both) to get all uses/defs of a particular register, > physical or virtual. Exactly what I need. Thanks! This must have gone in fairly recently. -Dave

On Mon, 2008-04-28 at 21:39 -0500, Lane Schwartz wrote: > On Mon, Apr 28, 2008 at 8:31 PM, Gordon Henriksen > <gordonhenriksen at mac.com> wrote: > > On 2008-04-28, at 21:19, Lane Schwartz wrote: > > > > > On Mon, Apr 28, 2008 at 2:13 PM, Gordon Henriksen <gordonhenriksen at mac.com > > >> stack and discover the return address of each call frame.

On Mon, Apr 28, 2008 at 8:31 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On 2008-04-28, at 21:19, Lane Schwartz wrote: > > > On Mon, Apr 28, 2008 at 2:13 PM, Gordon Henriksen <gordonhenriksen at mac.com > > > wrote: > > > >>> If so, then a Collector plugin would need to have info about every > >>> supported backend