On 10/15/2013 01:30 PM, Rafael Espíndola 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 > > Then again, it is entirely possible I missed something that mandates > this pass being in codegen. > > Cheers, > RafaelI agree with you 100%. I think it should be an assembler function too, as should long branch optimization. In fact the earliest pdp-11 unix compilers did long branch optimization in the assembler. Moving this to the assembler would require some community buy in. To do this in the assembler and not create any issues, I think you would need to serialize one the asmstreamer interfaces and have a way to edit the instruction stream parts. Then you could play it back through asm printer. Reed
On 10/15/2013 01:39 PM, reed kotler wrote:> On 10/15/2013 01:30 PM, Rafael Espíndola 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 >> >> Then again, it is entirely possible I missed something that mandates >> this pass being in codegen. >> >> Cheers, >> Rafael > I agree with you 100%. > > I think it should be an assembler function too, as should long branch > optimization. > In fact the earliest pdp-11 unix compilers did long branch optimization > in the assembler. > > Moving this to the assembler would require some community buy in. > > To do this in the assembler and not create any issues, I think you would > need to serialize one the asmstreamer interfaces and have a way > to edit the instruction stream parts. > > Then you could play it back through asm printer. > > Reed >I thought about serializing asmprinter for this purpose but that code would really belong in the target independent code and that would require a proposal to the community and I don't know what kind of response there would be. Certainly, it would be generally useful.> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Probably for now, I will start with the LLVM ARM model for constant islands. Another possibility would be to process all the machine code for the module in one pass. There are some advantages to having all the basic block information still intact. I think that Jim Grosbach said that this was needed for ARM. Reed On 10/15/2013 01:49 PM, reed kotler wrote:> On 10/15/2013 01:39 PM, reed kotler wrote: >> On 10/15/2013 01:30 PM, Rafael Espíndola 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 >>> >>> Then again, it is entirely possible I missed something that mandates >>> this pass being in codegen. >>> >>> Cheers, >>> Rafael >> I agree with you 100%. >> >> I think it should be an assembler function too, as should long branch >> optimization. >> In fact the earliest pdp-11 unix compilers did long branch optimization >> in the assembler. >> >> Moving this to the assembler would require some community buy in. >> >> To do this in the assembler and not create any issues, I think you would >> need to serialize one the asmstreamer interfaces and have a way >> to edit the instruction stream parts. >> >> Then you could play it back through asm printer. >> >> Reed >> > > I thought about serializing asmprinter for this purpose but that code > would really belong in the target independent code and that would > require a proposal to the community and I don't know what kind of > response there would be. > > Certainly, it would be generally useful. >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev