Hi All, My target has some instructions requiring register pairs. I decided to give a try to the PBQP allocator : it is working fine in 99% of the cases, but I am stumbling on the following issue. Instruction 'MPQD' takes 3 register operands inputs, with the constraint that operands 0 and 2 must be consecutive registers. Operand 1 has no particular constraint. It has no output register. So we have something like MPQD R_n, R_x, R_n+1. I have derived from PBQPBuilder to add the MPQD constraint. It happens sometimes that the code for register allocation looks like this : ... MPQD %vreg80, %vreg79, %vreg80; GR16:%vreg80,%vreg79 ... Operands 0 & 2 have been coalesced and I can no longer set the constraint. I tried to add a pass right before register allocation, to catch those case and insert a copy for operand 2, but the copy gets coalesced away. What would be the appropriate way to handle this case ? Thanks, -- Arnaud de Grandmaison -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110606/9b2fcea9/attachment.html>
On Jun 6, 2011, at 7:07 AM, Arnaud Allard de Grandmaison wrote:> Hi All, > > My target has some instructions requiring register pairs. I decided to give a try to the PBQP allocator : it is working fine in 99% of the cases, but I am stumbling on the following issue. > > Instruction ‘MPQD’ takes 3 register operands inputs, with the constraint that operands 0 and 2 must be consecutive registers. Operand 1 has no particular constraint. It has no output register. So we have something like MPQD R_n, R_x, R_n+1. > > I have derived from PBQPBuilder to add the MPQD constraint. > > It happens sometimes that the code for register allocation looks like this : > ... > MPQD %vreg80, %vreg79, %vreg80; GR16:%vreg80,%vreg79 > ... > Operands 0 & 2 have been coalesced and I can no longer set the constraint. > > I tried to add a pass right before register allocation, to catch those case and insert a copy for operand 2, but the copy gets coalesced away. > > What would be the appropriate way to handle this case ?You would need to run your pass after coalescing, but before PBQP runs. There is currently no standard hook for inserting passes in that location, but it may make sense for PBQP to offer such a hook since it can support many strange constraints. /jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110606/bcd25a98/attachment.html>
Thanks Jakob, I will try that. -- Arnaud de Grandmaison ________________________________ From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: Monday, June 06, 2011 4:24 PM To: Arnaud Allard de Grandmaison Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] PBQP & register pairing On Jun 6, 2011, at 7:07 AM, Arnaud Allard de Grandmaison wrote: Hi All, My target has some instructions requiring register pairs. I decided to give a try to the PBQP allocator : it is working fine in 99% of the cases, but I am stumbling on the following issue. Instruction 'MPQD' takes 3 register operands inputs, with the constraint that operands 0 and 2 must be consecutive registers. Operand 1 has no particular constraint. It has no output register. So we have something like MPQD R_n, R_x, R_n+1. I have derived from PBQPBuilder to add the MPQD constraint. It happens sometimes that the code for register allocation looks like this : ... MPQD %vreg80, %vreg79, %vreg80; GR16:%vreg80,%vreg79 ... Operands 0 & 2 have been coalesced and I can no longer set the constraint. I tried to add a pass right before register allocation, to catch those case and insert a copy for operand 2, but the copy gets coalesced away. What would be the appropriate way to handle this case ? You would need to run your pass after coalescing, but before PBQP runs. There is currently no standard hook for inserting passes in that location, but it may make sense for PBQP to offer such a hook since it can support many strange constraints. /jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110606/691e074f/attachment.html>