On 4/1/25 10:46 PM, Heinrich Schuchardt wrote:
On 4/1/25 20:15, Vineet Gupta wrote:
On 3/31/25 23:48, Heinrich Schuchardt wrote:
On 3/30/25 01:49, Vineet Gupta wrote:
changes since v2
- dump log sanfu
---
vsetvl phase4 uses LCM guided info to insert VSETVL insns.
It has an additional loop to insert missing vsetvls on certain edges.
Currently it asserts/aborts on encountering EDGE_ABNORMAL.
When enabling go frontend with V enabled, libgo build hits the assert.
It seems to be safe to just skip the abnormal edge.
Hello Vineet,
Is there a test case where only following an abnormal edge between code
blocks would require to call VSETVL?
In the sketched code below following the exception would require VSETVL
to be called while the edge from the try block to the finally block
would not require this.
try {
for (..) {
uint16_t vectorizable math
if (condition)
throw exception
uint16_t vectorizable math
}
for (..) {
uint8_t vectorizable math
}
} catch exception {
} finally
for (..) {
uint8_t vectorizable math
}
}
Yeah we are going to run testsuite with -fnon-call-exceptions to find
such cases.
But I'd argue, there is no need to optimize vsetvl for such esoteric
cases (vs.
code complexity trade-off).
After all we'd just endup with an extra VSETVL in the finally block.
Thx,
-Vineet
My worry is not superfluous vsetvl statements but missing ones on
abnormal edges.
Your patch sounds to me like:
Ignore abnormal edges. Never insert vsetvl statements there.
We need to test that on an abnormal edge we are inserting a vsetvl
instruction when needed.
As abnormal edges typically don't connect two vectorized code-blocks
with different vsetvl requirements this requires analyzing generated
code for this specific scenario.
Which is what Vineet, Robin, myself and others discussed at length in
this morning's patch review meeting. It's a classic problem with LCM
based algorithms.
We can't just ignore the edge. What we instead need to do is ensure the
algorithm never wants to insert on these problematical edges. This is
typically handled by "killing" expressions so that they don't propagate
to these problem edges.
jeff
