On 4/8/25 02:12, Robin Dapp wrote: >> However we still see lift up using those blocks - the earliest set computed >> contained the supposedly elided bbs. >> >> Try lift up 0. >> >> earliest: >> Edge(bb 16 -> bb 17): n_bits = 3, set = {1 } >> >> Try lift up 1. >> >> earliest: >> Edge(bb 15 -> bb 16): n_bits = 3, set = {1 } >> >> And subsequently the earliest set is used for rest of the algorithm. > Funny, might be a similar issue as in PR119547. There the lift doesn't > consider "transparent" either and I worked around it manually by checking > live_in etc. > > Can you try whether the following helps? It does for PR119547. > > diff --git a/gcc/config/riscv/riscv-vsetvl.cc > b/gcc/config/riscv/riscv-vsetvl.cc > index 53b064e36a3..1821698e6df 100644 > --- a/gcc/config/riscv/riscv-vsetvl.cc > +++ b/gcc/config/riscv/riscv-vsetvl.cc > @@ -3002,6 +3002,9 @@ pre_vsetvl::earliest_fuse_vsetvl_info (int iter) > || bitmap_count_bits (e) != 1) > continue; > > + if (!bitmap_bit_p (m_transp[eg->src->index], expr_index)) > + continue; > +
Yay ! It does work. Awesome. I've uploaded the further reduced test to PR/119533 > If not we might need the transparency check in the other cases still. > > There is fallout but just a single test > > gcc.target/riscv/rvv/vsetvl/avl_single-68.c > > Here the issue is that we want to lift vsetvl into a block that is not > transparent WRT the vsetvl. It could still be lifted, though, because the > conflicting register is only ever used as AVL operand in vsetvls and not by > other insns. This special case we don't consider when computing transparency > (as it might be compute-heavy). > > We could consider it here, though. What we'd need to do is check whether > only the avl operand (not vl) is set in the block and its uses are only > vsetvls. Then we could still perform the lift. But maybe let's rather defer > that as an optimization and live with the regression? Yes something to consider for gcc-16 Thx, -Vineet