[LLVMdev] module level assembly optimization

Chris Lattner clattner at apple.com
Thu Oct 17 04:13:37 PDT 2013


On Oct 15, 2013, at 1:30 PM, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:

> On 14 October 2013 21:56, 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?
> 
> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131017/e01bee93/attachment.html>


More information about the llvm-dev mailing list