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