On 3/31/25 3:43 PM, Vineet Gupta wrote:
But what state is in play that caused it to want to insert something?
That's what needs to be understood here. I don't see anything in bb64
that requires vsetvl to be in any particular state. So why did vsetvl
insertion think that it needed to insert anything on the edge to bb64?
emit vsetvl (phase 4), sweeps thru all BBs and if they have any vsetvl info
(local or global) it visits all edges (including abnormal) and inserts the
vsetvl on edge.
So if there is a block local need, then it gets inserted on the incoming
edge(s).
It seems local would be when a BB needs vsetvl functionally (due to presence of
a V insn) vs. a global case being said BB part part of control flow eventually
leading to a BB with local vsetvl need.
And if that's the case then you can't simply skip an abnormal edge. You
have to do something sensible.
That "something sensible" has traditionally been to ensure there is
never a need propagated to an edge since you can't insert on an abnormal
critical edge.
So there is no real criteria for insertion here, its insert on every edge.
If there is a need in the block, then every path to the block must have
the right value. That's precisely my point. You can't simply skip an
edge in this case.
What needs to happen is you need to find a way to ensure there is no
need at the start of the block that has incoming abnormal/EH edges.
This is a classic problem in LCM algorithms.
See "prune_expressions" in gcse.cc. I think the moral equivalent for
vsetvl generation is to conceptually kill every vsetvl at the entry
point to any block that as an incoming abnormal edge. That should push
the insertion point into the block instead of to the incoming edges.
Jeff
