https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #15 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 managed to write a run test now which makes debugging and reducing the test simpler. I think your patch largely achieves the right thing but I'm just not sure about the use of "transparent" for that. Usually transparent deals with input operands so we can move a vsetvl around if its inputs are not modified in the block. It's not unreasonable to use the same mechanism for the output as well but I need to think about it some more (whether it doesn't conflict with other things in the pass). My current hunch is that we don't verify that lifting up vsetvls into vsetvl-free blocks is conflict free, i.e. that a vsetvl's output is not already used in the block. Currently experimenting based on that hypothesis. If that works we might get away with a smaller change.
