On 5/10/25 9:55 PM, Vineet Gupta wrote:
On 5/10/25 07:17, Jeff Law wrote:
On 5/9/25 2:27 PM, Vineet Gupta wrote:
This showed up when debugging the testcase for PR119164.
RISC-V FRM mode-switching state machine has special handling for transitions
to and from a call_insn as FRM needs to saved/restored around calls (any
call is considered potentially FRM clobbering). Consider the following
canonical example where insns 2, 4, 6 come are due to user code, while
the rest of frm save/restore insns 1, 3, 5, 7 need to be generated for the
ABI semantics.
test_float_point_frm_static:
1: frrm a5 <--
2: fsrmi 2
3: fsrm a5 <--
4: call normalize_vl
5: frrm a5 <--
6: fsrmi 3
7: fsrm a5 <--
Not the focus of this series, but isn't the frrm@5 unnecessary?
It is necessary. Any function call can potentially change frm. Assuming
normalize_vl does, we need to read the latest "global" so that the restore in
insn 7 does the right thing.
But if there isn't a use between the call and the next assignment to
FRM, then the restore (or lack thereof) can't be observed and it need
not be emitted.
Eliding the restore in this case is no different than caller register
restores when the register allocator put a value that is live across
calls into a caller saved register.
It's also no different than how we manage SI->DI extensions on rv64. If
you can't observe that an SI mode value isn't sign extended to DI, then
it's safe to elide the extension.
- For abnormal edges, insert_insn_end_basic_block () is called, which
by design on encountering call_insn as last in BB, inserts new insn
BEFORE the call, not after.
Right. In theory we're not supposed to be asking for insertion on
abnormals anyway. It would be interesting to know if that's still
happening or if it's legacy from the late 90s when we first started
lighting up LCM algorithms and made all the common mistakes WRT abnormals.
Well the RISC-V code was looping thru all the edges and handling regular and
abnormal edges.
When I added the debug prints there, it was sometimes hitting the abnormal edge
case and putting before call, not after.
I was referring to the generic code to put stuff before the call. I'd
have to do some digging, but I wouldn't be at all surprised if that code
exists only because we made those class mistakes when bringing up the
LCM optimizers eons ago. If that's the case then those paths shouldn't
be taken and some asserts would probably help avoid difficult to
discover/debug problems.
Jeff
