[LLVMdev] module level assembly optimization

[Reed Kotler]

I've been understanding the ARM Constant island code better because I'm 
getting ready to do the Mips version.

In effect, it is even fairly well parameterized already. Almost a base 
class and not needing to be just ARM specific.

I don't think it will be difficult at all to merge my version and the 
ARM one into a single class. If we do that, we could create the general 
class and make the Mips and ARM versions be specific classes of this new 
base class.

The real issue is the fact that "sometimes" you really want to be able 
to process a linked list of machine functions.

I'm not really sure if there is any benefit to doing this kind of 
assembly stuff at the mc layer. You just have less information at that 
time. In a machine function you already have the machine instructions so 
you know what is there essentially.

This higher layer has more information in it which could be necessary 
and/or at least helpful. For example, sometimes you need to still use 
register scavenger to do constant work, as we have to do for mips32 long 
branches.

So I think it would be useful to have a new module pass that is sent a 
list of machine functions and it maybe even calls asm printer for those.
Function passes could still be used but we need to guarantee order of 
the functions because we are calculating module level address offsets.

Reed

On 10/17/2013 04:13 AM, Chris Lattner wrote:
>
> On Oct 15, 2013, at 1:30 PM, Rafael Espíndola
> <rafael.espindola at gmail.com <mailto:rafael.espindola at gmail.com>> wrote:
>
>> On 14 October 2013 21:56, reed kotler <rkotler at mips.com
>> <mailto: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?
>>
>> My experience is here consists of only once debugging an issue on the
>> ARM constant island pass, so take my opinion with a grain of salt
>>
>> When looking at the pass, it is easy to notice how much it looks like
>> an assembler doing relaxations. It needs to know exact offsets, adding
>> data to an island changes offsets, etc. It is also easy to notice how
>> hard it is to test a pass like that that is nested deep inside
>> codegen.
>>
>> My thought at the time was that it would be nice to implement the pass
>> in the assembler itself by having codegen use pseudo instructions.
>> Something like
>>
>> .const_island_set_reg r4, 0x12345678
>>
>> The assembler would then be responsible for creating the islands and
>> producing a load (or using something like movw + movt if it was better
>> in that case.
>>
>> The advantages would be
>> * The assembler already naturally handles exact addresses.
>> * It would be much easier to test.
>> * It would work across functions
>
> This would be really great, and a powerful way to make it so that each
> RISC target didn't have to have their own implementation of the same
> thing.  Pulling this off well would require teaching the assembler about
> branches, including how to shorten them (like x86 does) which can be
> more complex for RISC targets.  However, I think this would be really
> great infrastructure to have at the MC level in any case.
>
> -Chris
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>