Jeff Law <jeffreya...@gmail.com> writes: > On 11/8/23 02:40, Richard Sandiford wrote: >> Lehua Ding <lehua.d...@rivai.ai> writes: >>> Hi, >>> >>> These patchs try to support subreg coalesce feature in >>> register allocation passes (ira and lra). >> >> Thanks a lot for the series. This is definitely something we've >> needed for a while. >> >> I probably won't be able to look at it in detail for a couple of weeks >> (and the real review should come from Vlad anyway), but one initial >> comment: > Absolutely agreed on the above. > > The other thing to ponder. Jivan and I have been banging on Joern's > sub-object tracking bits for a totally different problem in the RISC-V > space. But there may be some overlap. > > Essentially Joern's code tracks liveness for a few chunks in registers. > bits 0..7, bits 8..15, bits 16..31 and bits 32..63. This includes > propagating liveness from the destination through to the sources. SO > for example if we have > > (set (reg:SI dest) (plus:SI (srcreg1:SI) (srcreg2:SI))) > > If we had previously determined that only bits 0..15 were live in DEST, > then we'll propagate that into the source registers. > > The goal is to ultimately transform something like > > (set (dest:mode) (any_extend:mode (reg:narrower_mode))) > > into > > (set (dest:mode) (subreg:mode (reg:narrower_mode))) > > Where the latter typically will get simplified and propagated away. > > > Joern's code is a bit of a mess, but Jivan and I are slowly untangling > it from a correctness standpoint. It'll also need the usual cleanups.
Ah, nice! How configurable are the bit ranges? We might be able to use something similar to track lanes in a vector operation, to detect the dead code in: ins v0.b[4], w0 ... ins v0.b[4], w1 It sounds like the bit ranges you have now would do that for some common/useful cases, even if it doesn't handle the general case. Maybe dead lanes are better tracked at the gimple level though, not sure. (But AArch64 might need to lower lane operations more than it does now if we want gimple to handle it.) Richard
