I don't want to seperate VSETVL PASS into 2 seperate PASS. I want make everything cleaner.
Another example is VSETVL PASS can do the branch prediction: https://godbolt.org/z/K44r98E5v In function "f", you can see we put the hoist vsetvl from a more likely block (i !=cond) outside the loop, then eliminate the vsetvl of this block. (Branch prediction is not that perfect in VSETVL PASS, I plan to optimize more when GCC 14 is open). "f2" function is the normal fuse that we do in Phase 3. juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-04-12 05:14 To: Richard Biener; juzhe.zhong CC: gcc-patches; kito.cheng; palmer Subject: Re: [PATCH] RISC-V: Fix PR108279 On 4/11/23 02:55, Richard Biener wrote: > > Just to throw in a comment here - I think you should present LCM > with something it can identify as the same for compatible vsetvl and > then it should just work? OTOH if "compatible" is not transitive > that's not possible (but then I can't quickly make up an example > where it wouldn't be). I'm not sure it's that simple. Or at least not with a single iteration of LCM. One problem is that kills may affecting one setting, but not the other. I couldn't mentally come up with a single pass LCM to handle the case Juzhe was handling. ie, you may have two compatible settings where you can unify them and hoist the compatible setting to a less executed point. But the transp set for one of two compatible settings may be different for the other compatible setting because of vector instructions in a block. What was starting to form was a two pass approach. One which worked with individual vsetvl settings, another which worked on unified vsetvl settings. It wasn't clear to me which ordering would be better, but I didn't work through the likely scenarios -- it was clear this wasn't the time to introduce that kind of conceptual change. jeff
