This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: LRA reloads of subregs
- From: Vladimir Makarov <vmakarov at redhat dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 4 Sep 2015 23:45:01 -0400
- Subject: Re: LRA reloads of subregs
- Authentication-results: sourceware.org; auth=none
- References: <20150903 dot 153356 dot 310079122256057627 dot davem at davemloft dot net> <55E9A415 dot 1060400 at redhat dot com> <20150904 dot 112731 dot 703645514395767529 dot davem at davemloft dot net> <20150904 dot 180205 dot 138101724910768041 dot davem at davemloft dot net>
On 09/04/2015 09:02 PM, David Miller wrote:
From: David Miller <davem@davemloft.net>
Date: Fri, 04 Sep 2015 11:27:31 -0700 (PDT)
From: Vladimir Makarov <vmakarov@redhat.com>
Date: Fri, 4 Sep 2015 10:00:54 -0400
I don't think we should add a new LRA code calling process_address
before adding insns for further processing. LRA just needs to get
operands from insns to make them valid. So again I'd try to make insn
recognizable for LRA first and only if it does not work then think
about other solutions in case when such change creates other problems
(it is hard for me to predict LRA behaviour definitely just reading
source files and not knowing sparc port well).
I've taken some time to see exactly what is going on here, perhaps
you can give me some guidance, I'm quite happy to implement anything
:-)
Ok, if modifying constraint/insn definitions does not work, then you
could try to split the 1st loop in
lra-constraints.c::curr_insn_transform onto 2 loops: one with processing
subregs and another one with the rest of the original loop code. Then
you need to put the new loop processing subregs after the loop
processing addresses. I think it will work. Of course the change will
need a lot of testing on other platforms (at least on x86/x86-64).
We start with:
(insn 1100 1099 1101 14 (set (reg:SI 3376)
(ior:SI (subreg:SI (reg:QI 287) 0)
(subreg:SI (reg:QI 289) 0))) x.c:104 234 {iorsi3}
(expr_list:REG_DEAD (reg:QI 289)
(expr_list:REG_DEAD (reg:QI 287)
(nil))))
LRA emits, in curr_insn_transform():
(set (reg:SI 13423) (subreg:SI (reg:QI 287) 0))
LRA then spills the subreg onto the stack, which gives us:
(insn 18631 1099 1100 14 (set (reg:SI 13423)
(subreg:SI (mem/c:QI (plus:SI (reg/f:SI 101 %sfp)
(const_int -14269 [0xffffffffffffc843])) [0 %sfp+-14269 S1 A8]) 0)) x.c:104 63 {*movsi_insn}
(expr_list:REG_DEAD (reg:QI 287)
(nil)))
And this is where we run into trouble in simplify_operand_subreg(),
which seems to force reloads for all SUBREGs of MEM.
Normally, if there were no SUBREG here, LRA would run
process_address() over the MEMs in this instruction and all would be
well.
It is also the case that I cannot do anything special in the SPARC
move emitter to handle this, as address validization is disabled when
lra_in_progress is true.