This is the mail archive of the
mailing list for the GCC project.
Re: Redundant / wasted stack space and instructions
- From: pshortis at dataworx dot com dot au
- To: gcc at gcc dot gnu dot org
- Date: Wed, 16 Apr 2014 16:30:35 +1000
- Subject: Re: Redundant / wasted stack space and instructions
- Authentication-results: sourceware.org; auth=none
- References: <b19e95bfc44080cb29e302860366a18d at dataworx dot com dot au> <534DB766 dot 4030502 at dataworx dot com dot au>
For small micros such as MSP430 & friends and many of the Renasis
some of which only have 2K or ram on board, this could be a real
Although I reproduced the same behaviour on i386 using a stock
I was wondering if there was something missing in my port that
spilling to stack locations, or a cleanup pass that addresses this
The only way to know for sure is to dig through the debugging dumps
understand why any given pseudo register was not assigned to a hard
If you're doing a new port, I would also recommend taking the time
investigate and possibly tune it to utilize LRA. It's been our
experience that LRA, after tuning, produces superior code when
compared to the old reload pass.
The register spilling isn't the problem, this is a situation where
are more variables than registers so spilling is expected.
The problem is that spilled vregs that correspond to stack
that already have appropriate memory available, are spilling to a new
local spill variable.
I've just built the trunk msp430 and h8300 ports and they both spill
correctly to the stack parameters when compiling the same test code...
so I'll hunt through those ports so see if I can find something I've
I have ported to the LRA, however on this register poor CPU it seems
fail to allocate registers in cases where the old reload pass works
fine... maybe my LRA port also has problems :-)
Found it ...
I had left the movsi patterns unimplemented because I was told that if I
did this then gcc would create expands/splits to use 16 bit moves. So, I
removed my movsi patterns and all seemed well.
In comparing the output of the expand pass from the msp430 port and mine
I could see the movsi instructions for the msp430 and the movhi subreg
instructions in mine.
I wondered if using the subreg:HI to split the SI moves into HI moves
was hiding real nature of the moves for reload and future optimizations,
so I reverted to my movsi patterns and ... the spills now resolve back
to the incoming stack parameter slots as desired !
Oh, and I tried using the LRA on this test case and Jeff, you're correct
the generated code is far, far better.