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
