On 8/7/23 08:44, Manolis Tsamis wrote:
I have sent out a new v4 of this
(https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626502.html).
In the new version I both restore the INSN_CODE as mentioned here and
I also call recog when I commit the offset change (because there may
be a change from no offset to some offsets).
I have also removed the driver function as per Vineet's suggestion.
Last thing I have fixed a nasty bug with REG_EQUIV's that resulted in
failing bootstrap on AArch64.
The offending sequence looked like this (in 'simplified RTX'):
(set (reg/f:DI 3 x3)
(plus:DI (reg/f:DI 2 x2)
(const_int 8 [0x8])))
(set (reg/f:DI 19 x19)
(plus:DI (reg/f:DI 3 x3)
(reg:DI 19 x19)))
...
(set (reg:TI 2 x2)
(mem:TI (reg/f:DI 0 x0)))
(expr_list:REG_DEAD (reg/f:DI 0 x0)
(expr_list:REG_EQUIV (mem:TI (reg/f:DI 19 x19))
(nil)))
(set (mem:TI (reg/f:DI 19 x19))
(reg:TI 2 x2))
(expr_list:REG_DEAD (reg/f:DI 19 x19)
(expr_list:REG_DEAD (reg:TI 2 x2)
(nil)))
Were the first instruction (x3 = x2 + 8) was folded in the address
calculation of the last one, resulting in (mem:TI (plus:DI (reg/f:DI
19 x19) (const_int 8 [0x8])), but then the previous REG_EQUIV was
incorrect due to the modified runtime value of x19.
For now I opted to treat REG_EQ/EQUIV notes as uses that we cannot
handle, so if any of them are involved we don't fold offsets. Although
it would may be possible to improve this in the future, I think it's
fine for now and the reduction of folded insns is a small %.
I have tested v4 with a number of benchmarks and large projects on
x64, aarch64 and riscv64 without observing any issues. The x86
testsuite issue still exists as I don't have a satisfactory solution
to it yet.
Any feedback for the changes is appreciated!
Thanks for the explanation. You could just remove the REG_EQUIV note.
It's not used much after allocation & reloading. Or just ignoring those
insns as you've done seems reasonable as well. I doubt one approach is
clear better than the other.
jeff
