Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] MachineRegisterInfo use_iterator/reg_iterator?"
2014 Sep 25
2
[LLVMdev] MachineRegisterInfo use_iterator/reg_iterator?
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,
2008 Mar 31
5
[LLVMdev] reg_iterator Caveats
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
2008 Apr 01
0
[LLVMdev] reg_iterator Caveats
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
2008 Mar 31
2
[LLVMdev] reg_iterator Caveats
On Monday 31 March 2008 00:57, Chris Lattner wrote:
> 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
2008 Mar 31
0
[LLVMdev] reg_iterator Caveats
On Mar 31, 2008, at 2:53 PM, David Greene wrote:
> On Monday 31 March 2008 00:57, Chris Lattner wrote:
>> 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
2008 Jan 11
2
[LLVMdev] Classifying Operands & Def/Use Chains
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
2008 Jan 11
0
[LLVMdev] Classifying Operands & Def/Use Chains
On Jan 11, 2008, at 2:00 PM, David Greene wrote:
> 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?
Nope, not that I know of.
> Also, is there any
2008 Jan 11
1
[LLVMdev] Classifying Operands & Def/Use Chains
On Friday 11 January 2008 16:36, Chris Lattner wrote:
> On Jan 11, 2008, at 2:00 PM, David Greene wrote:
> > 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
>
2008 Apr 01
2
[LLVMdev] reg_iterator Caveats
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
2008 Apr 01
0
[LLVMdev] reg_iterator Caveats
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
2008 Apr 01
0
[LLVMdev] reg_iterator Caveats
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
2008 Mar 30
2
[LLVMdev] reg_iterator Caveats
I'm forwarding this to llvmdev so it doesn't get lost in the sea of commits...
-Dave
---------- Forwarded Message ----------
Subject: Re: [llvm-commits] [llvm] r48521 - in /llvm/trunk:
include/llvm/CodeGen/LiveVariables.h lib/CodeGen/LiveVariables.cpp
test/CodeGen/PowerPC/2008-03-18-RegScavengerAssert.ll
test/CodeGen/X86/x86-64-ret0.ll
2008 Mar 31
2
[LLVMdev] reg_iterator Caveats
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
2008 Mar 31
0
[LLVMdev] reg_iterator Caveats
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
2008 Mar 30
0
[LLVMdev] reg_iterator Caveats
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
2009 Jul 17
2
[LLVMdev] Bug in LiveIntervals? Please Examine
In LiveIntervals::processImplicitDefs() we have this:
for (MachineRegisterInfo::use_iterator UI = mri_->use_begin(Reg),
UE = mri_->use_end(); UI != UE; ) {
MachineOperand &RMO = UI.getOperand();
MachineInstr *RMI = &*UI;
++UI;
MachineBasicBlock *RMBB = RMI->getParent();
if (RMBB == MBB)
continue;
const
2014 Sep 30
2
[LLVMdev] Custom pass that runs before EmitStartOfAsmFile()?
Hi all,
I'm trying to write a custom module-level pass that runs before AsmPrinter::EmitStartOfAsmFile(), since I'd like to have some processed information available once entering this function.
Looking through "Writing an LLVM pass" documentation, it's not clear to me if this is possible. I've also tried putting the pass in different orders (addPreISel, addIRPasses,
2014 Aug 15
2
[LLVMdev] Default/initial values for function arguments?
Hi guys,
I’m trying to figure out a way to assign initial values to function arguments. For a function in IR:
define i32 @main (i32 %0, i32 %1)
{
%tmp = add i32 %0, %1
...
}
I would like to make sure %0 has some initial value (e.g. i32 0) under some circumstances. Is there any easy way to do this? I understand that %0 comes from a live-in value which is defined from outside of the function. I
[LLVMdev] [llvm-commits] [PATCH] MachineRegisterInfo: Don't emit the same livein copy more than once
2012 Feb 14
0
[LLVMdev] [llvm-commits] [PATCH] MachineRegisterInfo: Don't emit the same livein copy more than once
Hi Tom,
I'm pretty sure this function should only ever be called once, by
SelectionDAG. Do you know where the second call is coming from in your code?
Cheers,
Lang.
On Mon, Feb 13, 2012 at 7:03 PM, Stellard, Thomas <Tom.Stellard at amd.com>wrote:
> This patch seems to have been lost on the llvm-commits mailing list.
> Would someone be able to review it?
>
> Thanks,
>
2012 Apr 10
1
[LLVMdev] Bug in MachineRegisterInfo ?
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 ();