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>