[LLVMdev] PBQP & CalcSpillWeights

[Lang Hames]

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