> From: Richard Sandiford [mailto:rdsandif...@googlemail.com] > Matthew Fortune <matthew.fort...@imgtec.com> writes: > > I have been looking at using the FRAME_GROWS_DOWNWARD macro to > change > > the layout of a frame such that spill slots end up closer to the stack > > pointer. This is useful as it leads to more spill/reload instructions > > being encodable with 16bit instructions for mips16 and micromips, the > > same is likely to be true for other compressed instruction sets in > > other archs. > > > > Currently FRAME_GROWS_DOWNWARD is only set when > flag_stack_protect for > > mips as it is a prerequisite for stack protection. I can?t think of > > any drawback to having the frame grow downward unconditionally for > > mips16 and micromips. I don?t believe there is any impact on > > performance or debug regardless of the way a frame is populated. I?m > > tempted to suggest changing this for all mips ISAs but I feel I must > > be missing some important point. > > I suppose the main potential disadvantage for MIPS16 is that it becomes > harder to predict before register allocation whether a particular access will > be extended or unextended. E.g. at the moment, a frame address will look > like: > > (mem (plus (reg $frame) (const_int X))) > > and using X to decide the cost of an address will give a reasonably good > indication of whether the final $sp-based address will be extended. > With FRAME_GROWS_DOWNWARD it becomes: > > (mem (plus (reg $frame) (const_int -X))) > > with larger X indicating smaller final offsets, and with the final offset > changing each time the frame grows. That includes each time a spill slot is > added. > > That isn't a problem for microMIPS (if it's a problem at all), because we > don't > take the length into account while optimising. We only do that for MIPS16.
That's an interesting point. I'll try and look into what impact that may have. > But in reality, the only reason it's the way it is now is because > !FRAME_GROWS_DOWNWARD is the traditional behaviour, probably from > well before MIPS16 was added. AFAIK no-one has measured whether > changing it makes things worse or better. So when -fstack-protect support > was added, we just made the minimal change. > > If you have time to benchmark it then let's go with whatever turns out best. I have already done some investigation (only with bare metal tools so far) and that shows that growing the frame downward almost universally improves code size. This is looking at the detail of function level size comparison as well as overall library sizes. I have not done any performance analysis as yet. > However, I think it'd be better to get the LRA transition done first, > including > fixing the spilling of MIPS16 registers into temporary non-MIPS16 registers > rather than the stack. At the moment we're using stack reloads far more > than we ought to, which I think would skew the figures a bit. I would like to get the LRA transition in progress but I was/am under the impression that I'd have to do this for all ISAs/variants of MIPS at the same time rather than just mip16 and as such it will take time to test sufficiently. Regards, Matthew
