Richard Sandiford <rdsandif...@googlemail.com> writes: > Matthew Fortune <matthew.fort...@imgtec.com> writes: > > Hi Richard, > > > > As part of implementing the new O32 FPXX ABI I am making use of the > > HARD_REGNO_CALL_PART_CLOBBERED macro to allow odd-numbered > > floating-point registers to be considered as 'normally' callee-saved > > but call clobbered if they are being used to hold SImode or SFmode > > data. The macro is implemented as: > > > > /* Odd numbered single precision registers are not considered call > saved > > for O32 FPXX as they will be clobbered when run on an FR=1 FPU. > */ > > #define HARD_REGNO_CALL_PART_CLOBBERED(REGNO, MODE) > \ > > (TARGET_FLOATXX && ((MODE) == SFmode || (MODE) == SImode) > \ > > && FP_REG_P (REGNO) && (REGNO & 1)) > > Under these conditions the entire value is call-clobbered though. > It might be better to say that the odd-numbered registers are always > call-clobbered (which I think is more accurate) but force them to be > saved by functions that use them. This is in some ways similar to the > way that interrupt handlers save call-clobbered registers.
The problem here is that these registers form the second part of 64-bit call saved registers and therefore have to be marked as call-saved for 64-bit values regardless of their behaviour for 32-bit values. I have tried to simply mark them as call-clobbered and the effect was that 64-bit values ended up being seen as call-clobbered. Approaching this problem from both sides leads to complications as O32 FPXX has a register which behaves differently based on mode. From experimentation I believe this approach to be the neatest and use existing features of GCC. > Maybe some RA heuristics will need tweaking to reflect the extra cost > of these registers, but I imagine that's true either way. Perhaps. I am currently thinking/hoping that simply having them marked as call clobbered will be enough. In terms of the HARD_REGNO_CALL_PART_CLOBBERED macro. I would say that it is poorly named as it gives no indication to GCC internals as to which part of the register is clobbered and which is not. When this macro returns true GCC simply takes that to mean the whole register is clobbered. I'd say that then makes my usage legitimate. If I had time and will power I'd remove the 'PART' from this macro and switch over to having it as the primary source of call-clobbered information in GCC doing away with call_used_regs etc. Having the mode information is quite valuable as we are seeing with SIMD ISA extensions that use this macro. Supporting two sources of call-clobbered data is probably what lead us to the current situation of broken optimisation passes. My concern with this post is not really to focus on my specific usage of HARD_REGNO_CALL_PART_CLOBBERED but instead the issues with the internals of GCC not taking account of it. I would expect with a little work I could show this same optimisation problem for some pre-existing use of the macro. Do you agree with my brief analysis that at least one pass (regcprop) is wrong w.r.t this macro? I should be ready to send the FPXX GCC patch next week which will show the problem directly. Regards, Matthew
