> On Mar 10, 2022, at 8:54 PM, Xi Ruoyao <xry...@mengyan1223.wang> wrote: > > On Thu, 2022-03-10 at 20:31 +0000, Qing Zhao wrote: > >>>> + SET_HARD_REG_BIT (zeroed_hardregs, HI_REGNUM); >>>> + if (TEST_HARD_REG_BIT (need_zeroed_hardregs, LO_REGNUM)) >>>> + SET_HARD_REG_BIT (zeroed_hardregs, LO_REGNUM); >>>> + else >>>> + emit_clobber (gen_rtx_REG (word_mode, LO_REGNUM)); >>> >>> …I don't think this conditional LO_REGNUM code is worth it. >>> We might as well just add both registers to zeroed_hardregs. >> >> If the LO_REGNUM is NOT in “need_zeroed_hardregs”, adding it to >> “zeroed_hardregs” seems not right to me. >> What’s you mean by “not worth it”? > > It's because the MIPS port almost always treat HI as "a subreg of dword > HI-LO register". A direct "mthi $0" is possible but MIPS backend does > not recognize "emit_move_insn (HI, CONST_0)”.
Why there is “mthi $0” instruction, but there is NO emit_move_insn(HI, CONST_0)? Is such mismatch a bug? If not, why? > In theory it's possible > to emit the mthi instruction explicitly here though, but we'll need to > clear something NOT in need_zeroed_hardregs for MIPS anyway (see below). One question here, is there situation when only HI is cleared but LO is not cleared? > >>> Here too I think we should just do: >>> >>> zeroed_hardregs |= reg_class_contents[ST_REGS] & accessible_reg_set; >>> >>> to include all available FCC registers. >> >> What’s the relationship between “ST_REGs” and FCC? (sorry for the stupid >> question since I am not familiar with the MIPS register set). > > MIPS instruction manual names the 8 one-bit floating condition codes > FCC0, ..., FCC7, but GCC MIPS backend code names the condition codes > ST_REG0, ..., ST_REG7. Maybe it's better to always use the name > "ST_REG" instead of "FCC" then. Okay, I see. So, each ST_REGi register is a 1-bit pseudo register? But physically each of them is 1-bit in a physical register? > >> From the above code, looks like that when any “ST_REGs” is in >> “need_zeroed_hardregs”,FCC need to be cleared? > > Because there is no elegant way to clear one specific FCC bit in MIPS. > A "ctc1 $0, $25" instruction will zero them altogether. If we really > need to clear only one of them (let's say ST_REG3), we'll have to emit > something like > > mtc1 $0, $0 # zero FPR0 to ensure it won't contain sNaN > c.f.s $3, $0, $0 > > Then we'll still need to clobber FPR0 with zero. So anyway we'll have > to clear some registers not specified in need_zeroed_hardregs. So, “c.f.s” instruction can be used to clear ONLY one specific FCC bit? But you have to clear one FPR (floating pointer register?) first to avoid raising exception? My question here is: is there a case when only FCC need to be cleared but no FPR need to be cleared? If NOT, then we can always pick one FPRi before c.f.s to avoid the issue you mentioned (We’ll have to clear some registers not specified in need_zeroed_hardregs). > > And the question is: is it really allowed to return something other than > a subset of need_zeroed_hardregs for a TARGET_ZERO_CALL_USED_REGS hook? Although currently there is no assertion added to force this requirement, I still think that we should keep it. The “need_zeroed_hardregs” is computed based on 1. User’s request from command line option; 2. Data flow info of the routine; 3. Abi info of the target; If zero_call_used_regs target hook return registers out of “need_zeroed_hardregs” set, then it might out of the user’s exception, it should be considered as a bug, I think. Qing > If yes then we'll happily to do so (like how the v2 of the patch does), > otherwise we'd need to clobber those registers NOT in > need_zeroed_hardregs explicitly. > -- > Xi Ruoyao <xry...@mengyan1223.wang> > School of Aerospace Science and Technology, Xidian University
