On 2/13/25 14:17, Robin Dapp wrote: >>>> Other thoughts? >>> The docs seem to hint TARGET_SCHED_CAN_SPECULATE_INSN is meant for stuff >>> we can't/don't model in the pipeline, but I have no idea how to model >>> the VL=0 case there. >> Maybe so, but what Edwin is doing looks sensible enough. It wouldn't be >> the first time a hook got (ab)used in ways that weren't part of the >> original intent. > I don't fully understand what's happening. So the hoisting is being done > speculatively here? And it just happens to be "bad" because that might > cause a VL=0 case. But are we sure a lack of speculation cannot cause > such cases?
Exactly. My gut feeling w/o deep dive was this seemed like papering over the issue. BTW what exactly is speculative scheduling ? As in what is it actually trying to schedule ahead ? > Also, why doesn't the vsetvl pass fix the situation? IMHO we need to > understand the problem more thoroughly before changing things. > In the end LCM minimizes the number of vsetvls and inserts them at the > "earliest" point. If that is not sufficient I'd say we need modify > the constraints (maybe on a per-uarch basis)? As far as LCM is concerned it is hoisting the insn to the optimal spot. However there's some additional logic such as in can_use_next_avl_p () which influences if things can be moved around. > On a separate note: How about we move the vsetvl pass after sched2? > Then we could at least rely on LCM doing its work uninhibited and wouldn't > reorder vsetvls afterwards. Bingo ! excellent idea. This would ensure scheduling doesn't undo carefully placed stuff, but .... > Or do we somehow rely on rtl_dce and BB > reorder to run afterwards? ... I have no idea if any of this is in play. > That won't help with the problem here but might with others. Right this needs to be evaluated independently with both icounts and BPI3 runs to see if anything falls out. -Vineet
