Matthew Fortune <matthew.fort...@imgtec.com> writes: > That sounds OK to me. > > I'm aiming to have an experimental implementation of the calling > convention changes as soon as possible although I am having difficulties > getting the frx calling convention working correctly. > > The problem is that frx needs to treat registers as 64bit sometimes and > 32bit at other times. > a) I need the aliasing that 32bit registers gives me (use of an > even-numbered double clobbers the corresponding odd-numbered > single. This is to prevent both the double and odd numbered single being > used simultaneously. > b) I need the 64bit register layout to ensure that 64bit values in > caller-saved registers are saved as 64-bit (rather than 2x32-bit) and > 32-bit registers are saved as 32-bit and never combined into a 64-bit > save. Caller-save.c flattens the caller-save problem down to look at > only hard registers not modes which is frustrating. > > It looks like caller-save.c would need a lot of work to achieve b) with > 32-bit hard registers but I equally don't know how I could achieve a) > for 64-bit registers. I suspect a) is marginally easier to solve in the > end but have to find a way to say that using reg x as 64-bit prevents > allocation of x+1 as 32-bit despite registers being 64-bit. The easy > option is to go for 64-bit registers and never use odd-numbered > registers for single-precision or double-precision but I don't really > want frx to be limited to that if at all possible. Any suggestions?
Treating it as a limited from of FR0 mode seems best. I don't think there's any practical way of doing (a) without making HARD_REGNO_NREGS be 2 for a DFmode FPR, at which point any wrong assumptions about paired registers in caller-save.c would kick in. We'd only be making this change in the next release cycle, and we really should look to move to LRA for that cycle too. caller-save.c is specific to reload and so wouldn't be a problem. Of course, you might need to do stuff in LRA instead. Thanks, Richard
