[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578

--- Comment #40 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Fredrik Hederstierna from comment #38)
> I guess this 'meta-bugreport' have become lightly fuzzy with all kinds of
> CSiBE code size increase issues,
> so maybe better to identify these issues on a more detailed level and create
> smaller specific reports?

It is much better to create smaller specific reports, otherwise IMNSHO it
becomes impossible to track what's going on with these long running bug
reports. 

Conflating multiple issues into one bug report is just going to cause confusion
in the long run.

Thus I'd like to close this bug and if you could please open new bug reports
for each individual issue that still remains open.

> 
> I've done some approaches, like try posting Bug 67507 and Bug 67213. I think
> also the attached source to this issue have some switch-case issue and still
> becomes larger.
> Though I think its better to post that also in a separate issue

Yes please and thanks a lot for all the benchmarking and digging you have been
doing with this.

> 
> I did a new benchmark yesterday on code size for
> 
> arm9_thumb
> arm9_arm
> cortex-m0
> cortex-m3
> 
> using newly built compiler toolchains for
> 
> gcc 4.6.4
> gcc 4.7.4
> gcc 4.8.5
> gcc 4.9.3
> gcc 5.3.0
> gcc 6-20160313 snapshot
> 
> in total 4*6=24 builds. See attached Excel file for results.
> Also you can check out my pre-alpha site at
> 
> http://gcc.hederstierna.com/csibe/
> 
> (my hope is to be able to build a up-to-date arm-size-benchmark, but its
> very pre-alpha still.)
> 
> The results looks good I think. The overall size is getting smaller. So I
> think its ok.
> Though some files miscompiles into large code, we need to dig into these and
> look at the specific files  I think.
> 
> There are though a proposed patch also attached in this issue regarding arm
> register IP,
> that could be used to further analyze why LRA code might increase in
> specific cases I think.
> 
> Do you still think the ip-patch is valid I can rebase it against git master
> and submit patch again in a separate issue?

The policy for patches is posting them at gcc-patches@gcc.gnu.org and reviewing
them on the list there. The reason it has not been reviewed is because no one
ever spotted it.

However, I don't think the IP patch is an appropriate approach to the problem
but the data you have with respect to -ffixed-ip might help understand what's
going on with the register allocator. Off the top of my head it sounds odd that
we have this problem - In Thumb state IP is available for register allocation
quite late in the "order" already and the compiler should prefer the low
registers as much as possible.


> 
> Best Regards, Fredrik