[LLVMdev] module level assembly optimization

[reed kotler]

On 10/15/2013 11:05 AM, Eric Christopher wrote:
> On Mon, Oct 14, 2013 at 6:56 PM, reed kotler <rkotler at mips.com> wrote:
>> I would like to do constant pools over an entire module instead of just on a
>> per function basis as constant islands does it now.
>>
>> It seems there are two options for this:
>>
>> 1) collect the machine functions with their machine instructions for the
>> whole module, edit them as needed and then
>> call asmprinter for them one at a time.
>>
>> 2) collect all the instruction streams and store them in lists, one per
>> section and put them all out at the end.
>>
>> There are possibly other kinds of module level optimizations that could
>> benefit from this.
>>
>> Some of this might be better done by moving this functionality into target
>> independent code but I think I could do it all
>> without such changes.
>>
>> Any thoughts?
>>
> Two questions:
>
> a) what do you think you'll gain over per-function,
> b) how are you going to handle constants out of range on a module level?
>
> -eric
You make some good points.

We have actually been further discussing this inside of 
Mips/Imagination. One of the guys here has done a module
level constant island for another architecture.

We've discussed some further improvements to his scheme and have come up 
with something that can work and later be extended, using
the current model for constant islands that llvm uses for ARM.

I will create some module level statistics on missed possibilities so 
that we can evaluate how much better things could have
been if we had module level optimizations. One big win is that often you 
need to load the 32 bit address of something
and these addresses can be placed in a constant island, i.e. printf, 
sin, cos, etc.. So it's possible to have a lot of references to
such things. Recreating them inline on a true risc machine can be 
expensive. How much we save? I have no statistics on this
for Mips since we have never had a constant island compiler (gcc does 
something simple with one pool at the end of the function).

If we decide that there is something there, then the following steps 
would be something like:

1) When a function is compiled, remember where the constant islands for 
it where. New functions can reference those places.
2) Delay putting out the constant island that is at the end of the 
function. When the next function appears, see if it is small enough to
where this earlier constant island could have been put at the end of 
this new function. This make things work when you have lots of small
functions and you keep moving the pool further down in the stream.
3) It's also possible to create a module pass to collect module level 
statistics
that tells you whether something in you constant pool will occur later.  
You can decide if it will be beneficial to move a constant from one pool
to another. Well...many ideas. The point is that we have a lot of room 
that we can grow into in order to do better pooling, while starting with the
basic scheme of a per function.


So there is a lot of room that we can improve things, starting with the 
basic model that already exists in LLVM so that is the plan for how
I intend to proceed.

Reed