[LLVMdev] Loop localize global variables

sundeepk at codeaurora.org sundeepk at codeaurora.org
Tue Jul 21 22:06:48 PDT 2015


Hi Charlie,

My prototype only handles the static case. It's very simple implementation.

It relies on ProcessInternalGlobal in GlobalOpt.cpp to check for the
safety of static variables those can be localized (address-not-taken,
volatile etc). Then I run a LoopPass that pretty much goes through each BB
of the Loop and collects all static variables. It also checks for some
more safety conditions (no calls, inline asm blocks etc). If the static
variable is safe to localize in the loop, it creates alloca, loads from GV
and stores into alloca in the pre-header, load from alloca and store into
GV in the exit block, and replaces all uses of GV in the loop with alloca.

The malloc case you mentioned below is very interesting but I don't follow
why you need a function pass to handle this case.

Thanks,
Sundeep

> ----- Original Message -----
>> From: "Charlie Turner" <charlesturner7c5 at gmail.com>
>> To: sundeepk at codeaurora.org
>> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
>> Sent: Tuesday, July 21, 2015 9:22:04 AM
>> Subject: Re: [LLVMdev] Loop localize global variables
>>
>> Hi Sundeep,
>>
>> I am also interested in the load-store lifting transformation.
>
> I am as well, LICM should certainly be taught to speculatively load/store
> to conditionally-accessed dereferenceable addresses when that is likely to
> be profitable.
>
>>
>> For static globals as-in your example, the transformation in general
>> would rely on a better static global aliasing information that is
>> currently in review http://reviews.llvm.org/D10059
>
> This will help, yes, but the transformation is quite useful regardless.
>
>>
>> For non-static globals, one problem with loop-based analysis alone is
>> that in a popular embedded benchmark suite, you get serious gains if
>> you can localize the globals in code like
>>
>> int *G1;
>> int *G2;
>>
>> foo () {
>>   G1 = malloc(...);
>>   for (...) {
>>        // Lots of stuff with G1 and G2 worth localizing
>>   }
>> }
>>
>> That malloc is very important to consider when doing an alias query
>> because now the aliasing infrastructure knows G1, G2 don't alias, and
>> you won't see it from a loop pass. If you were to try and modify LICM
>> to localize the globals for example, it would have to assume G1 and
>> G2
>> MayAlias.
>
> Why?
>
>  -Hal
>
>> I believe this implies we must use a FunctionPass, and I
>> have a prototype that catches cases like the above, as well as the
>> simpler ones. I can't commit myself however to when that will be
>> ready, so I'm just sharing what I've found out, maybe it's helpful.
>>
>> I'd be interested to hear your thoughts / approach in greater detail.
>>
>> Thanks!
>> --Charlie.
>>
>> On 21 July 2015 at 06:10,  <sundeepk at codeaurora.org> wrote:
>> > typo corrected
>> >
>> >   lcl_var = gbl_var;
>> >   for () {
>> >      ...access lcl_var...
>> >   }
>> >   gbl_var = lcl_var;
>> >
>> >
>> >> Hello all,
>> >>
>> >> I am writing to get some feedback on an optimization that I would
>> >> like to
>> >> upstream. The basic idea is to localize global variables inside
>> >> loops so
>> >> that it can be allocated into registers. For example, transform
>> >> the
>> >> following sequence
>> >>
>> >> static int gbl_var;
>> >> void foo() {
>> >>
>> >>   for () {
>> >>      ...access gbl_var...
>> >>   }
>> >>
>> >> }
>> >>
>> >> into something like
>> >>
>> >> static int gbl_var;
>> >> void foo() {
>> >>   int lcl_var;
>> >>
>> >>   lcl_var = gbl_var;
>> >>   for () {
>> >>      ...access clc_var...
>> >>   }
>> >>   gbl_var = lcl_var;
>> >>
>> >> }
>> >>
>> >> This transformation helps a couple of EEMBC benchmarks on both
>> >> Aarch64 and
>> >> Hexagon backends. I was wondering if there is interest to get this
>> >> optimization upstreamed or if there is a better way of doing this.
>> >>
>> >> Thanks,
>> >> Sundeep
>> >>
>> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> >> hosted by The Linux Foundation
>> >>
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>




More information about the llvm-dev mailing list