llvm dev - May 2012 - [LLVMdev] handleMoveIntoBundle assertion

Hi,

I have a custom scheduler/bundler running just after coalescing as 
proposed by the current infrastructure of machine schedulers. Btw, great 
thanks for this cool stuff !
I'm running into problems when I want to update the LI information of an 
instruction. I call handleMoveIntoBundle() to make its LI begins from 
the packet header but the following assertion is raised:

"Can't have two defs for the same variable exiting a bundle." in 
moveExitingFromInto()

IIUC, handleMoveIntoBundle collects entering, internal and exiting live 
ranges from the bundle and group all this information into BundleRanges. 
Then it collects the same information for the incoming instruction and 
add it to the current BundleRanges while updating its live ranges.
I found that entering, internal and exiting live ranges of the packet 
are not cleared before collecting the same information for the incoming 
instruction. The attached patch fix it.
Unfortunately, I can't provide a test case but it can be easily tested 
by calling handleMoveIntoBundle() with 2 arbitrary MI's where the packet 
contains a register def.

Ivan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: handleMoveIntoBundle.patch
Type: text/x-patch
Size: 536 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120526/6c6f9a7b/attachment.bin>

Hi again,

Just forgot to add PATCH prefix to my message! Could you please review it ?

Ivan

Le 26/05/2012 00:52, Ivan Llopard a écrit :
> Hi,
>
> I have a custom scheduler/bundler running just after coalescing as 
> proposed by the current infrastructure of machine schedulers. Btw, 
> great thanks for this cool stuff !
> I'm running into problems when I want to update the LI information of 
> an instruction. I call handleMoveIntoBundle() to make its LI begins 
> from the packet header but the following assertion is raised:
>
> "Can't have two defs for the same variable exiting a bundle."
in
> moveExitingFromInto()
>
> IIUC, handleMoveIntoBundle collects entering, internal and exiting 
> live ranges from the bundle and group all this information into 
> BundleRanges. Then it collects the same information for the incoming 
> instruction and add it to the current BundleRanges while updating its 
> live ranges.
> I found that entering, internal and exiting live ranges of the packet 
> are not cleared before collecting the same information for the 
> incoming instruction. The attached patch fix it.
> Unfortunately, I can't provide a test case but it can be easily tested 
> by calling handleMoveIntoBundle() with 2 arbitrary MI's where the 
> packet contains a register def.
>
> Ivan

Hi Ivan,

I'm just looking into it now. Thanks for working on this.

- Lang.

On Tue, May 29, 2012 at 6:50 AM, Ivan Llopard <ivanllopard at gmail.com>
wrote:
> Hi again,
>
> Just forgot to add PATCH prefix to my message! Could you please review it ?
>
> Ivan
>
> Le 26/05/2012 00:52, Ivan Llopard a écrit :
> > Hi,
> >
> > I have a custom scheduler/bundler running just after coalescing as
> > proposed by the current infrastructure of machine schedulers. Btw,
> > great thanks for this cool stuff !
> > I'm running into problems when I want to update the LI information
of
> > an instruction. I call handleMoveIntoBundle() to make its LI begins
> > from the packet header but the following assertion is raised:
> >
> > "Can't have two defs for the same variable exiting a
bundle." in
> > moveExitingFromInto()
> >
> > IIUC, handleMoveIntoBundle collects entering, internal and exiting
> > live ranges from the bundle and group all this information into
> > BundleRanges. Then it collects the same information for the incoming
> > instruction and add it to the current BundleRanges while updating its
> > live ranges.
> > I found that entering, internal and exiting live ranges of the packet
> > are not cleared before collecting the same information for the
> > incoming instruction. The attached patch fix it.
> > Unfortunately, I can't provide a test case but it can be easily
tested
> > by calling handleMoveIntoBundle() with 2 arbitrary MI's where the
> > packet contains a register def.
> >
> > Ivan
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120529/4125065a/attachment.html>