Hello Richard, Jeff,
I checked both.
- The aarch64 backend uses the load double only for stacking operations.
This, I have. This functionality is provided by gcc via the
load_multiple construct.
If you define it, gcc will use it for stack and unstack operations.
- The ARM has a peephole2 optimizer. This has the problem that it is run
after the
register allocation, and if the register allocation needs to change
for the optimization
to be done, the pattern fails. I tried that, I got that working, but
... I dont like it.
- I found another way, which would work in theory:
a. Add it to the "movsi"
1. Make a "define_expand" of the movsi, which does the following:
a. For the 'normal' case, it calls a define_insn "movsi_internal"
b. It maintains a per-function history of past calls to self.
c. For every call to movsi, it looks in the history if it finds a
'partner'
with which it can create a "load double"
d. If it finds one, it starts going back in the insn-list, and do
checking
if the replacement is appropriate. It mainly means no in-between
jumps and labels, no in-between modification of the address
register,
not too far back.
e. If the checking is successful, it replaces the /previous/
movsi with the load double.
For now, I will park this, and do as in aarch64. I might try it later.
Best Regards,
Henri.
On 02/03/2020 06:10 PM, Richard Earnshaw (lists) wrote:
On 03/02/2020 15:49, Jeff Law wrote:
On Mon, 2020-02-03 at 15:50 +0100, Henri Cloetens wrote:
Hello all,
I have a question on the peephole2 optimizer.
- My target has a "load double" instruction:
- It does an indexed load of a 64-bit operand to two 32-bit
registers.
- The requirement is that the registers are adjacant
(Ri and Ri+1), and that the offset for the second load is 4
byte more
than for the first load.
- I can not find a way to describe this in gcc. I tried
"load_multiple", and this is OK, but gcc only calls that for stack
pushing.
I tried the vector facility, but this does not work either.
- I tried to write a peephole2 optimizer, and this works out OK, it
manages to recognize the sequence, ... but the peephole2
optimizer is
run AFTER register allocation, and the optimization needs to be
done
BEFORE, as there are constraints on the 2 registers, Ri and Ri+1.
Any suggestions ?. Is there any way to run peephole2 BEFORE register
allocation ?.
I suggest looking at ldp/stp support in the aarch64 backend.
jeff
Closer would be the ldrd/strd support when generating code for Arm
(not thumb); that has a similar restriction on register pairs being
adjacent.
Summary, it's hard; and GCC's infrastructure does not support it
particularly well.
R.
