Displaying 20 results from an estimated 300 matches similar to: "[LLVMdev] Possible VirtRegMap Bug"
2008 May 30
0
[LLVMdev] Possible VirtRegMap Bug
On May 27, 2008, at 5:36 PM, David Greene wrote:
> I've been playing around with spillers and found that the
> SimpleSpiller fails
> badly on a particular code.
>
> The problem arises because SimpleSpiller does the test
> VRM.isAssignedReg(virtReg) which is implemented as:
>
> 00183 bool isAssignedReg(unsigned virtReg) const {
> 00184 if
2017 Jun 05
3
VirtRegMap invariant: no reserved physical registers?
Hey all,
I've found a bug in either the PBQP register allocator or in VirtRegRewriter.
I'm observing this assertion in VirtRegRewriter::rewrite() fail:
unsigned VirtReg = MO.getReg();
unsigned PhysReg = VRM->getPhys(VirtReg);
...
assert(!MRI->isReserved(PhysReg) && "Reserved register assignment");
Indeed there is a case where
2008 Jun 02
1
[LLVMdev] Possible VirtRegMap Bug
On Friday 30 May 2008 15:13, Evan Cheng wrote:
> No, every vr is assigned a physical register. It needs to know how
> what physical register to reload it, for example. Looks like
> SimpleSpiller has bit-rotted. There really isn't a good reason to fix
> it. Unless you want to use it, I'll just remove it.
No, don't remove it! It's a valuable debugging tool. I've
2009 Jan 13
2
[LLVMdev] Possible bug in the ARM backend?
Hi again,
2009/1/13 Evan Cheng <evan.cheng at apple.com>:
>
>
> On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com>
> wrote:
>
>> 2009/1/13 Evan Cheng <echeng at apple.com>:
>>>
>>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>>>
>>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
2009 Jun 03
2
[LLVMdev] Removing SimpleRewriter (formerly SimpleSpiller)
Hi all,
Is anyone still using SimpleRewriter (formerly known as
SimpleSpiller)? A quick check with the test suite suggests that it's
badly broken. If it's not being used I'd like to remove it as part of
my tidy-up of the register allocator.
- Lang.
2009 Jun 04
0
[LLVMdev] Removing SimpleRewriter (formerly SimpleSpiller)
I vote for execution of SimpleRewriter.
Evan
On Jun 3, 2009, at 1:34 PM, Lang Hames wrote:
> Hi all,
>
> Is anyone still using SimpleRewriter (formerly known as
> SimpleSpiller)? A quick check with the test suite suggests that it's
> badly broken. If it's not being used I'd like to remove it as part of
> my tidy-up of the register allocator.
>
> - Lang.
>
2009 Jun 04
2
[LLVMdev] Removing SimpleRewriter (formerly SimpleSpiller)
On Jun 3, 2009, at 5:51 PM, Evan Cheng wrote:
> I vote for execution of SimpleRewriter.
Yeah, go ahead and axe it: Off with its head!
-Chris
>
>
> Evan
>
> On Jun 3, 2009, at 1:34 PM, Lang Hames wrote:
>
>> Hi all,
>>
>> Is anyone still using SimpleRewriter (formerly known as
>> SimpleSpiller)? A quick check with the test suite suggests that it's
2011 Nov 30
2
[LLVMdev] Register allocation in two passes
Thanks for all the hints Jakob, I've added the following piece of code
after the spill code handling inside selectOrSplit() (ignoring some control
logic):
for (LiveIntervals::const_iterator I = LIS->begin(), E = LIS->end(); I !=
E;
++I)
{
unsigned VirtReg = I->first;
if ((TargetRegisterInfo::isVirtualRegister(VirtReg))
&& (VRM->getPhys(VirtReg)
2008 Feb 07
1
[LLVMdev] [PATCH] fix warning: 'NumFolded' defined but not used
lib/CodeGen/RegAllocLocal.cpp:38: warning: 'NumFolded' defined but not used
This has been introduced because of r46821.
However, maybe removing just the variable isn't enought,
because the comments in the section that got modified
by 46821 are not optimal:
if (PhysReg) { // Register is available, allocate it!
assignVirtToPhysReg(VirtReg, PhysReg);
} else { // No
2011 Oct 07
3
[LLVMdev] VirtRegRewriter.cpp: LocalRewriter::ProcessUses()
Hi,
I think I've found a bug in this method.
I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16.
For the def-operand, with a subregindex, an implicit-use operand was added with this code:
VirtUseOps.insert(VirtUseOps.begin(), MI.getNumOperands());
MI.addOperand(MachineOperand::CreateReg(VirtReg,
2009 Oct 29
1
[LLVMdev] request for help writing a register allocator
I'm having no luck getting my register allocator to work. I'm trying to
do it using the "indirect" approach; i.e., using a VirtRegMap, with calls
to assignVirt2Phys, assignVirt2StackSlot, etc. and a call to a "spiller"
at the end.
As a warm-up exercise (before implementing register allocation via graph
coloring) I'm trying to implement a very simple scheme in
2012 Nov 15
0
[LLVMdev] problem trying to write an LLVM register-allocation pass
Hi Susan,
Jakob just pointed me to 'MachineOperand::substPhysReg(unsigned preg, const
TargetRegisterInfo& TRI)'. That substitutes the given physreg for a virtreg
operand, taking the subregister index into account. That is what my
examples have been doing manually. Using substPhysReg would allow you to
tidy the Gcra code up slightly.
- Lang.
On Thu, Nov 15, 2012 at 11:21 AM, Lang
2009 Jan 13
0
[LLVMdev] Possible bug in the ARM backend?
On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com
> wrote:
> 2009/1/13 Evan Cheng <echeng at apple.com>:
>>
>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>>
>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>>> Predecessors according to CFG: 0x8fdac90 (#0)
>>> %R0<def> = MOVi 0, 14, %reg0,
2011 Nov 30
0
[LLVMdev] Register allocation in two passes
On Nov 30, 2011, at 12:17 PM, Borja Ferrer wrote:
> Thanks for all the hints Jakob, I've added the following piece of code after the spill code handling inside selectOrSplit() (ignoring some control logic):
>
> for (LiveIntervals::const_iterator I = LIS->begin(), E = LIS->end(); I != E;
> ++I)
> {
> unsigned VirtReg = I->first;
> if
2011 Nov 29
0
[LLVMdev] Register allocation in two passes
On Nov 29, 2011, at 10:24 AM, Borja Ferrer wrote:
> Yes, I want the register to be allocatable when there are no stack frames used in the function so it can be used for other purposes. In fact, I looked at how other backends solve this problem, but they are all too conservative by always reserving the register which in my case it is not a good solution because of the performance impact of not
2011 Oct 12
0
[LLVMdev] VirtRegRewriter.cpp: LocalRewriter::ProcessUses()
On Oct 7, 2011, at 8:14 AM, Jonas Paulsson wrote:
> Hi,
>
> I think I've found a bug in this method.
>
> I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16.
>
> For the def-operand, with a subregindex, an implicit-use operand was added with this code:
>
>
2012 Nov 15
1
[LLVMdev] problem trying to write an LLVM register-allocation pass
Thanks Lang, I'll try substPhysReg.
I did try your latest code, and although it made the assembler errors go
away, now some of my tests produce bad output when executed. I need to
look into that some more... (I did change my "usedPregSet" to be ALL
pregs used in the whole function, not just those in the current
instruction, so the problem should not be the erroneous
2011 Nov 29
2
[LLVMdev] Register allocation in two passes
Yes, I want the register to be allocatable when there are no stack frames
used in the function so it can be used for other purposes. In fact, I
looked at how other backends solve this problem, but they are all too
conservative by always reserving the register which in my case it is not a
good solution because of the performance impact of not having this register
available.
I find very interesting
2009 Jan 13
2
[LLVMdev] Possible bug in the ARM backend?
2009/1/13 Evan Cheng <echeng at apple.com>:
>
> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>
>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:
>> Predecessors according to CFG: 0x8fdac90 (#0)
>> %R0<def> = MOVi 0, 14, %reg0, %reg0
>> *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4)
>> [0x8fc2d68 + 0]
2012 Sep 10
0
[LLVMdev] Assert in LiveInterval update
On Sep 10, 2012, at 2:26 AM, Lang Hames <lhames at gmail.com> wrote:
> I've got a good test case that I'm working on at the moment. I noticed something odd though: Is '0' a valid register unit? I'm seeing a LiveInterval with li->reg == 0 show up, which previously wasn't valid. We have a few checks around the place to disregard the '0' physreg - could