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

Reply via email to