[LLVMdev] [PATCH] handleMoveIntoBundle assertion

[Lang Hames]

Patch looks good. Committed in r157632. Thanks Ivan!

- Lang.

On Tue, May 29, 2012 at 11:00 AM, Lang Hames <lhames at gmail.com> wrote:

> 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/62769e9e/attachment.html>