lra-remat issues (PR68730)

Bernd Schmidt bschmidt@redhat.com
Thu Feb 4 17:17:00 GMT 2016


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?


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.


Bernd

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rematfix-v3.diff
Type: text/x-patch
Size: 7586 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20160204/2806aadb/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remat-tc.diff
Type: text/x-patch
Size: 1400 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20160204/2806aadb/attachment-0001.bin>


More information about the Gcc-patches mailing list