On 02/04/2016 12:17 PM, Bernd Schmidt wrote:
In this PR, we have, at an intermediate stage during LRA (before create_cands):

(insn 420 (set (reg:HI 276 [orig:132 g.2_118 ] [132])
        (reg:HI 132 [ g.2_118 ])) 88 {*movhi_internal}
     (nil))
[....]
(insn 436 (set (reg/v:HI 290 [orig:87 g ] [87])
        (reg/v:HI 87 [ g ]))

(insn 14 (set (reg/v:HI 88 [ l ])
        (reg/v:HI 290 [orig:87 g ] [87]))

(insn 15 (set (reg/v:HI 87 [ g ])
        (reg:HI 276 [orig:132 g.2_118 ] [132]))

During create_cands, we recognize 420 as a potential candidate, and when we reach insn 15, we select it as insn2, and create a new candidate for register 87. Later, in do_remat, that candidate is chosen when processing insn 436: we choose to use register 132 instead of register 87:

   436: r290:HI=r87:HI
     REG_DEAD r87:HI
   Inserting rematerialization insn before:
     441: r290:HI=r132:HI

This is kind of bad, because the equivalencing insn (#15) comes later.

After a few false starts, I came up with the patch below, which keeps track of not just the candidate insn, but also an activation insn, and chooses candidates only if they are both available and active. Besides passing a new arg to create_cand, the changes in create_cands are mostly cosmetic to make the function less confusing. This was bootstrapped and tested on x86_64-linux. Ok?

The patch looks ok for me.  Thanks for working on the PR, Bernd.

As an aside - I have some doubts about whether the liveness calculations in that file are completely safe. I see lots of direct register number comparisons in functions like input_regno_present_p, which is fine for pseudos, but if hard regs are involved I can't quite convince myself that the code is safe in the presence of overlaps. For now I've left it alone, but for gcc-7 this code should be reworked IMO.

I can not see that liveness calculation is wrong (hard registers modes are not present in lra insn regs, e.g. if insn refers double-word hard reg because of its mode, the two hard regs are present in lra insn regs). But it would be nice if you look at this code when you have time and willingness.

Reply via email to