Merge constant pools for small functions

[Andrew Stubbs]

There is no reason that each ARM function should have its own constant pool; multiple small functions in the same section can share a pool.

E.g.

The following program produces two small constant pools, but both could share one.

 f()
 {
   return 123456789;
 }

 g()
 {
   return 123456789;
 }

[CodeSourcery Tracker ID #798]

[stevenb (steven-gcc)]

This looks like gcc.gnu.org/PR9702 which was filed almost 8 years ago by the CSiBE folks. Apparently this used to be a hard problem. It may still be a hard problem now, but at least GCC has the ability now (GCC 4.6) to view entire compilation units (and more) so the problem should be easier to fix than 8 years ago.

[Andrew Stubbs (ams-codesourcery)]

AFAICT ARM doesn't seem to use the normal GCC constant pools mechanism, but instead implements its own "minipools".

These minipools are created by the TARGET_MACHINE_DEPENDENT_REORG pass (implemented by function arm_reorg). This pass is a per-function pass, so arm_reorg cannot modify the minipools attached to other functions. Is it possible to overcome this limitation?

Another observation: I'm not totally sure, but I think that the current upstream implementation is only capable of creating minipools *after* the reference point (i.e. at positive offsets). For small functions this is fine, but for large functions this might result in multiple minipools (one half way through, and one at the end, say) where only one would be necessary, were negative offsets allowed. There's clearly some small size benefit to be had here, but perhaps not much.

[Paolo (psubiaco-1)]

This is a annoying problem for gcc, because waste rom space defining the same constant multi times
Another example: http://pastebin.com/Ljbm8LSA
the ARM instrcutions ldr Rd,LABEL
is able to to load into Rd a variable within address-space 1020 , so if functions are really small it makes not sense to define the same constant for each functions, but it's better to define the constant only once.
Thanks a lot. Paolo