https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #16 from Robin Dapp <rdapp at gcc dot gnu.org> --- > Yes, it is precisely the issue I have encountered in cvtScale8s64f (actually > in cvt_64f). After the commit 34ae3a99, the default value of > LOGICAL_OP_NON_SHORT_CIRCUIT has changed from 0 into 1, it will change cfg > structure of cvt_64f function. > Go back to this issue itself, can you help to review the lcm algorithm of > risc-v vsetvl pass? I think I have found the root cause of this issue and > described it in my patch. But my understanding of the lcm algorithm is not > sufficient and the patch may be incorrect. I stand corrected, we already use transparency in the way you're describing. We just fail to consider it in the uplift phase of the vsetvl pass. So all the data should already be there and we could just do + if (!bitmap_bit_p (m_transp[eg->src->index], expr_index)) + continue; This will cause one regression where we would need to work a bit harder to relax transparency in case the conflicting register is only used for vsetvls (and not for other computations). The patch I posted does a similar thing slightly differently.
