Re: [PCH] constant pools rewrite

[Richard Earnshaw <rearnsha at arm dot com>]

> Some targets have limited register sets and limited addressing modes.  Thumb
> and mips16 are good examples of this.  It is so difficult to reach a per
> file constant pool that it is impractical.  You have to use per function
> constant pools, and you have to make sure that the constant pools go in the
> same section as the function.  In some cases, not even this is good enough,
> because if the function is too big, you won't be able to reach it unless
> it is inline.  Again, thumb and mips16 have this problem.  Since the generic
> constant pool code doesn't support inline constant pools, the arm and mips
> backends need their own code.  I don't remember which came first, but I'm
> pretty sure one was originally a copy of the other.  They have probably
> diverged since then.  There may be other targets with a copy of this code 
> also.


The SH code came first; the original implementation on the ARM was a copy 
I made of that.  Since then the ARM variant has been re-written at least a 
couple of times.  The current incarnation should be fairly MI and supports 
both forward and back-ward relative loads, merging of common entries, 
hiding of pools behind branches (when possible) and sorting of the entries 
to increase the degree of freedom of location of the pool when some 
instructions have a more limited range than others.

It would be an interesting project to see if that code could be cleaned up 
and made into an completely MI file that was used by the other ports 
requiring this sort of constant pool.

R.