On 5/12/25 14:55, Jeff Law wrote: >>>> 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.
Restore can be observed as the outcome of insn 7 and in the caller. Say after insn 3, frm is 2 (so is a5), but call changes it to 4. W/o restore, insn 7 will restore 2 (NOK), while w/ restore it will restore 4 (OK) > 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. IMHO these are different than above, but perhaps I'm not seeing something here, if so apologies. >>>> - 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. OK understood. Thx, -Vineet
