[LLVMdev] optimizing references within a struct

[Jim Grosbach]

On Feb 7, 2013, at 5:31 PM, reed kotler <rkotler at mips.com> wrote:

> On 02/07/2013 05:28 PM, Jim Grosbach wrote:
>> This sounds similar to what the LocalStackSlotAllocation pass does (lib/CodeGen/LocalStackSlotAllocation.cpp).
>> 
>> -Jim
> exactly but this is for structs but maybe you are saying that i can reuse those ideas for structs.

A bit of both. The pass runs after isel, so there's no concept of "structs" left in the code. It's purely looking at frame index references and trying to avoid repeated materializations of frame reference pointers (when the offset is out of range for a direct FP or SP relative addressing mode).

Now, the more general problem include global value references, which this pass doesn't know anything about. In that case, some of the same ideas may apply. If you're interested in looking into that, I suggest also looking at the GlobalMerge pass, as it would expose potentially significant additional opportunities there.

-Jim

> 
> 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
>