Hi Lang,> From memory your target is not public, so I won't be able to reproduce > the crash myself. Is that correct?Correct.> If that's the case, I could add functionality to dump the PBQP graphs > during allocation. I think they should give me enough information to > debug the issue. Would you be able to share the PBQP graphs?I can share the pbqp graph if you send me a patch with the added functionality you want. On my side, I already checked the node cost for this register, which is correctly set to inf for spill, as well as the edge costs, and they look ok. I also attached my target's pbqp related file in case you want to double check what I did. This is llvm-3.0 based. It comprises 2 passes : the FemtoPBQPBuilder, plus a FemtoPairablepass, which undo some of the coalescer's work. The insertRegCopy may specifically need a double check, as I am not 100% sure to have updated correctly the LiveInterval information. In terms of registers, the Femto target is simplistic : a single register class GR16, for data and pointers, all i16. It has 16 registers, R0 to R15; R15 is used as stack pointer, and R14 potentialy as framepointer. A pair is constituted from a register + its successor, i.e. (R0, R1), (R1,R2), (R2, R3), ... are valid pairs. This is an instruction encoding constraint, as we only have 16bits wide instructions. Pairs involving R15 are never allowed, those with R14 may be allowed, depending on each function. Most instructions have no pairing constraints, and do not appear here, being handled by the PBQPBuilder default base class. A few instructions have 1 or 2 pairs of registers, and are all handled by the 2 passes above. Thanks for your help, -- Arnaud de Grandmaison Senior CPU engineer Business Unit Digital Tuner Parrot S.A. 174, quai de Jemmapes 75010 Paris - France Phone: +33 1 48 03 84 59 -------------- next part -------------- A non-text attachment was scrubbed... Name: FemtoRegisterAllocator.cpp Type: text/x-c++src Size: 17631 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120326/07c07e0e/attachment.cpp>
Hi Arnaud, Thanks for attaching those files. I'll take a look at them. Commit r153483 adds an option to the PBQP allocator, "-pbqp-dump-graphs", to dump the PBQP graph for each round of each function in a compilation unit. The generated files are named "<module id>.<function>.<round>.pbqpgraph", and contain a simple text representation of the PBQP graph. The PBQP allocator has been stable for some time - I think this patch should apply cleanly to the 3.0 version. Can you run the failing test case through the allocator with this patch applied, passing the "-regalloc=pbqp -pbqp-dump-graphs -debug-only=regalloc" options. I'll need to take a look at the last graph dumped before the assertion is triggered. Cheers, Lang. On Mon, Mar 26, 2012 at 7:35 AM, Arnaud de Grandmaison <arnaud.allarddegrandmaison at parrot.com> wrote:> Hi Lang, > >> From memory your target is not public, so I won't be able to reproduce >> the crash myself. Is that correct? > Correct. > >> If that's the case, I could add functionality to dump the PBQP graphs >> during allocation. I think they should give me enough information to >> debug the issue. Would you be able to share the PBQP graphs? > I can share the pbqp graph if you send me a patch with the added functionality > you want. On my side, I already checked the node cost for this register, which > is correctly set to inf for spill, as well as the edge costs, and they look > ok. > > I also attached my target's pbqp related file in case you want to double check > what I did. This is llvm-3.0 based. It comprises 2 passes : the > FemtoPBQPBuilder, plus a FemtoPairablepass, which undo some of the coalescer's > work. The insertRegCopy may specifically need a double check, as I am not 100% > sure to have updated correctly the LiveInterval information. > > In terms of registers, the Femto target is simplistic : a single register > class GR16, for data and pointers, all i16. It has 16 registers, R0 to R15; > R15 is used as stack pointer, and R14 potentialy as framepointer. A pair is > constituted from a register + its successor, i.e. (R0, R1), (R1,R2), (R2, R3), > ... are valid pairs. This is an instruction encoding constraint, as we only > have 16bits wide instructions. Pairs involving R15 are never allowed, those > with R14 may be allowed, depending on each function. > > Most instructions have no pairing constraints, and do not appear here, being > handled by the PBQPBuilder default base class. A few instructions have 1 or 2 > pairs of registers, and are all handled by the 2 passes above. > > Thanks for your help, > -- > Arnaud de Grandmaison > Senior CPU engineer > Business Unit Digital Tuner > > Parrot S.A. > 174, quai de Jemmapes > 75010 Paris - France > Phone: +33 1 48 03 84 59
Hi Lang, I have reduced the testcase as much as possible. The log of the run and the dumped graphes are attached. Cheers, -- Arnaud de Grandmaison On Tuesday, March 27, 2012 01:20:35 Lang Hames wrote:> Hi Arnaud, > > Thanks for attaching those files. I'll take a look at them. > > Commit r153483 adds an option to the PBQP allocator, > "-pbqp-dump-graphs", to dump the PBQP graph for each round of each > function in a compilation unit. The generated files are named "<module > id>.<function>.<round>.pbqpgraph", and contain a simple text > representation of the PBQP graph. The PBQP allocator has been stable > for some time - I think this patch should apply cleanly to the 3.0 > version. > > Can you run the failing test case through the allocator with this > patch applied, passing the "-regalloc=pbqp -pbqp-dump-graphs > -debug-only=regalloc" options. I'll need to take a look at the last > graph dumped before the assertion is triggered. > > Cheers, > Lang. > > On Mon, Mar 26, 2012 at 7:35 AM, Arnaud de Grandmaison > > <arnaud.allarddegrandmaison at parrot.com> wrote: > > Hi Lang, > > > >> From memory your target is not public, so I won't be able to reproduce > >> the crash myself. Is that correct? > > > > Correct. > > > >> If that's the case, I could add functionality to dump the PBQP graphs > >> during allocation. I think they should give me enough information to > >> debug the issue. Would you be able to share the PBQP graphs? > > > > I can share the pbqp graph if you send me a patch with the added > > functionality you want. On my side, I already checked the node cost for > > this register, which is correctly set to inf for spill, as well as the > > edge costs, and they look ok. > > > > I also attached my target's pbqp related file in case you want to double > > check what I did. This is llvm-3.0 based. It comprises 2 passes : the > > FemtoPBQPBuilder, plus a FemtoPairablepass, which undo some of the > > coalescer's work. The insertRegCopy may specifically need a double > > check, as I am not 100% sure to have updated correctly the LiveInterval > > information. > > > > In terms of registers, the Femto target is simplistic : a single > > register > > class GR16, for data and pointers, all i16. It has 16 registers, R0 to > > R15; R15 is used as stack pointer, and R14 potentialy as framepointer. > > A pair is constituted from a register + its successor, i.e. (R0, R1), > > (R1,R2), (R2, R3), ... are valid pairs. This is an instruction encoding > > constraint, as we only have 16bits wide instructions. Pairs involving > > R15 are never allowed, those with R14 may be allowed, depending on each > > function. > > > > Most instructions have no pairing constraints, and do not appear here, > > being handled by the PBQPBuilder default base class. A few instructions > > have 1 or 2 pairs of registers, and are all handled by the 2 passes > > above. > > > > Thanks for your help, > > -- > > Arnaud de Grandmaison > > Senior CPU engineer > > Business Unit Digital Tuner > > > > Parrot S.A. > > 174, quai de Jemmapes > > 75010 Paris - France > > Phone: +33 1 48 03 84 59-------------- next part -------------- A non-text attachment was scrubbed... Name: invalid-spill.tar.gz Type: application/x-compressed-tar Size: 6984 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120327/1a996a3b/attachment.bin>