There is an optimization which the Greenhills compiler does for mips16. I have not looked at it myself ,but it was recounted to me. The basic idea is that if you have a large struct, rather than reference each element from the base of the struct, it's possible to chose some optimal point(s) that are not at the beginning of the struct and use as the base to reference elements of the struct. This particularly occurs in some of the codec code where there are large structs with many fields. This allows them to use shorter versions of some of the instructions. There are many 16/32 bit pairs of instructions in mips16, with the difference being the magnitude of the offset. Some have 5 bit fields that are shifted left 2 bits, yielding an effective 128 byte offset. There are lots of ways to optimize this problem. You can for example keep moving the base pointer, have more than one base pointer, etc. Is there such optimization already built into llvm? Tia. Reed
This sounds similar to what the LocalStackSlotAllocation pass does (lib/CodeGen/LocalStackSlotAllocation.cpp). -Jim On Feb 7, 2013, at 4:56 PM, reed kotler <rkotler at mips.com> wrote:> There is an optimization which the Greenhills compiler does for mips16. > > I have not looked at it myself ,but it was recounted to me. > > The basic idea is that if you have a large struct, rather than reference each element from the base of the struct, it's possible to chose some optimal point(s) that are not at the beginning of the struct and use as the base to reference elements of the struct. > > This particularly occurs in some of the codec code where there are large structs with many fields. > > This allows them to use shorter versions of some of the instructions. > There are many 16/32 bit pairs of instructions in mips16, with the difference being the magnitude of the offset. > > Some have 5 bit fields that are shifted left 2 bits, yielding an effective 128 byte offset. > > There are lots of ways to optimize this problem. > > You can for example keep moving the base pointer, have more than one base pointer, etc. > > Is there such optimization already built into llvm? > > Tia. > > Reed > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 02/07/2013 05:28 PM, Jim Grosbach wrote:> This sounds similar to what the LocalStackSlotAllocation pass does (lib/CodeGen/LocalStackSlotAllocation.cpp). > > -Jimexactly but this is for structs but maybe you are saying that i can reuse those ideas for structs. i'm going to turn on the localstackallocation soon . maybe i need to study that and write something similar for plain structs.> > On Feb 7, 2013, at 4:56 PM, reed kotler <rkotler at mips.com> wrote: > >> There is an optimization which the Greenhills compiler does for mips16. >> >> I have not looked at it myself ,but it was recounted to me. >> >> The basic idea is that if you have a large struct, rather than reference each element from the base of the struct, it's possible to chose some optimal point(s) that are not at the beginning of the struct and use as the base to reference elements of the struct. >> >> This particularly occurs in some of the codec code where there are large structs with many fields. >> >> This allows them to use shorter versions of some of the instructions. >> There are many 16/32 bit pairs of instructions in mips16, with the difference being the magnitude of the offset. >> >> Some have 5 bit fields that are shifted left 2 bits, yielding an effective 128 byte offset. >> >> There are lots of ways to optimize this problem. >> >> You can for example keep moving the base pointer, have more than one base pointer, etc. >> >> Is there such optimization already built into llvm? >> >> Tia. >> >> Reed >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev