This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [MIPS] Optimizing stack frames for codesize


Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
>> 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.

OK.  Was that with all of MIPS, microMIPS and MIPS16?

I wouldn't have expected any benefit for plain MIPS, and the negative
offsets would probably pessimise the handling of large frames.  If there
are improvements for plain MIPS it'd be interesting to see an example.
If not, we should probably leave it as-is.

If it's a win for microMIPS then that sounds like a good sign.  I wouldn't
have expected the LRA transition to affect the number of spills for microMIPS
too much.  So if it's a win there now, hopefully it will be for LRA too.

But if you saw an improvement for MIPS16, were the results run against a
tree with:

2013-07-11  Steve Ellcey  <sellcey@mips.com>

	* config/mips/mips.c (mips_conditional_register_usage): Do not
	use t[0-7] registers in MIPS16 mode when optimizing for size.

applied?  That patch deliberately encouraged spills to stack over spills
to non-MIPS16 registers, so I think results against current mainline
will emphasise them too much.

Sorry, I realise I'm probably being inconsistent by thinking that that
patch was OK to go in pre-LRA but this one isn't.  But we definitely want
to be able to revert to using temporary registers as spill space if possible,
so I'm hoping Steve's patch will only end up being temporary.  And it sounds
from PR58461 like reenabling the registers is already on your radar, thanks.
On the other hand, switching to negative frame offsets should be a
longer-term change, so I'd rather we did it based on post-LRA results.

>> 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.

Thanks.  Let me know if there's anything I can help with.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]