Hi!
On Fri, Oct 23, 2020 at 05:15:08PM +1030, Alan Modra wrote:
> The problem starts with fwprop creating
> (insn 9 4 0 2 (set (mem:V8HI (and:DI (plus:DI (reg/v/f:DI 121 [ vpp ])
> (const_int 12 [0xc]))
> (const_int -16 [0xfffffffffffffff0])) [0 MEM <vector(8) short
> int> [(void *)_4 & -16B]+0 S16 A128])
> (reg/v:V8HI 120 [ vp1 ])) "pixel.c":6:10 1237 {vsx_movv8hi_64bit}
> which is finally thrown out as invalid by lra. lra of course does that
> by reloading the entire address.
While it could/should just reload that 12 into a reg :-( Could you
investigate doing that? Is there any reason we should not?
> Now at the time the AND stripping was added (git commit 850e8d3d56d),
> rs6000_legitimate_address looked a lot simpler. This patch allows
> through just those addresses that were legitimate in those simpler
> days. (legitimate_small_data_p, legitimate_constant_pool_address_p,
> legitimate_lo_sum_address_p, and legitimate_offset_address_p did get
> to look at the inside of an AND address, but I'm fairly certain
> small_data, constant_pool and lo_sum addresses would never be wrapped
> in an AND, and offset_address_p of that time excluded altivec modes.)
>
> Regstrapped powerpc64le-linux power8 and power10, with tests on
> powerpc64-linux -m64/-m32 still running. OK assuming they pass?
I would be much happier if this was performance tested. But, it is okay
for trunk. Thanks!
Segher
