llvm dev - Jul 2015 - [LLVMdev] Are global variables candiates for register allocation?

Thanks, Reid. I'm not an optimization expert, but as a workaround,
can I do the following:

void myFunction()
{
   int local = global;
   .. use local ...
}

?

On Tue, Jun 30, 2015 at 6:53 PM, Reid Kleckner <rnk at google.com>
wrote:
> This came up in the past for GHC, and we recommended passing it as a
> parameter everywhere, as it lets the register allocator spill it under high
> register pressure.
>
> GCC has support for allocating globals in GPRs and removing that GPR from
> the allocatable set, but LLVM doesn't implement it so far as I know.
>
> On Tue, Jun 30, 2015 at 5:43 PM, Hayden Livingston <halivingston at
gmail.com>
> wrote:
>>
>> I was wondering if global variables can be candidates for register
>> allocation. My use case is a global variable that is used in every
>> function in my program.
>>
>> I'm wondering if it's better to pass it in, or let it stay as a
global.
>>
>> Passing it in will require a bit of work.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

>From a purely theoretical perspective, the compiler has to deal with here.
1. "Is the variable modified by other functions?"
     If so, the compiler must reload the value of global variables after
each call to such a function (or calls that MAY end up in such a function)
2. "is this variable used enough inside the function to warrant it being
placed in a local variable?"
     If so, it can be moved to a register (subject to #1 - if it still has
to be reloaded umpteen times, it's not necessarily meaningful to do so)

It's entirely plausible to come up with code that uses a global variable
and the compiler can allocate a register for it, but also equally possible
to come up with something where the compiler CAN'T use a register.

Using the method of

     int local = global;

would solve #1 above - as the local value won't change other than within
the function.

Making the global(s) into `static` - in other words letting the compiler
know "nothing outside this TU can see this variable" can help with #1
as
well, as the compiler can then analyze this TU and see what is going on
without having to worry that calls outside the TU will modify the variable
unknown to its current knowledge.

On 1 July 2015 at 05:57, Hayden Livingston <halivingston at gmail.com>
wrote:
>  Thanks, Reid. I'm not an optimization expert, but as a workaround,
> can I do the following:
>
> void myFunction()
> {
>    int local = global;
>    .. use local ...
> }
>
> ?
>
> On Tue, Jun 30, 2015 at 6:53 PM, Reid Kleckner <rnk at google.com>
wrote:
> > This came up in the past for GHC, and we recommended passing it as a
> > parameter everywhere, as it lets the register allocator spill it under
> high
> > register pressure.
> >
> > GCC has support for allocating globals in GPRs and removing that GPR
from
> > the allocatable set, but LLVM doesn't implement it so far as I
know.
> >
> > On Tue, Jun 30, 2015 at 5:43 PM, Hayden Livingston <
> halivingston at gmail.com>
> > wrote:
> >>
> >> I was wondering if global variables can be candidates for register
> >> allocation. My use case is a global variable that is used in every
> >> function in my program.
> >>
> >> I'm wondering if it's better to pass it in, or let it stay
as a global.
> >>
> >> Passing it in will require a bit of work.
> >> _______________________________________________
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/8e49f952/attachment.html>

Right, I follow your theory and thought the same.

I have a single TU scenario where the global is just used because we
generate hand assembly at runtime, and want to keep the code written
by hand to be super simple, calls with no parameters. Our scenario is
literally reading a file, which calls this functions hundreds of
thousands of times, and we reset the pointer to the "global" object
every time in the function.

I'll compile and see how it goes.

On Wed, Jul 1, 2015 at 12:40 AM, mats petersson <mats at
planetcatfish.com> wrote:
> From a purely theoretical perspective, the compiler has to deal with here.
>
> 1. "Is the variable modified by other functions?"
>      If so, the compiler must reload the value of global variables after
> each call to such a function (or calls that MAY end up in such a function)
> 2. "is this variable used enough inside the function to warrant it
being
> placed in a local variable?"
>      If so, it can be moved to a register (subject to #1 - if it still has
> to be reloaded umpteen times, it's not necessarily meaningful to do so)
>
> It's entirely plausible to come up with code that uses a global
variable and
> the compiler can allocate a register for it, but also equally possible to
> come up with something where the compiler CAN'T use a register.
>
> Using the method of
>
>      int local = global;
>
> would solve #1 above - as the local value won't change other than
within the
> function.
>
> Making the global(s) into `static` - in other words letting the compiler
> know "nothing outside this TU can see this variable" can help
with #1 as
> well, as the compiler can then analyze this TU and see what is going on
> without having to worry that calls outside the TU will modify the variable
> unknown to its current knowledge.
>
> On 1 July 2015 at 05:57, Hayden Livingston <halivingston at
gmail.com> wrote:
>>
>>  Thanks, Reid. I'm not an optimization expert, but as a workaround,
>> can I do the following:
>>
>> void myFunction()
>> {
>>    int local = global;
>>    .. use local ...
>> }
>>
>> ?
>>
>> On Tue, Jun 30, 2015 at 6:53 PM, Reid Kleckner <rnk at
google.com> wrote:
>> > This came up in the past for GHC, and we recommended passing it as
a
>> > parameter everywhere, as it lets the register allocator spill it
under
>> > high
>> > register pressure.
>> >
>> > GCC has support for allocating globals in GPRs and removing that
GPR
>> > from
>> > the allocatable set, but LLVM doesn't implement it so far as I
know.
>> >
>> > On Tue, Jun 30, 2015 at 5:43 PM, Hayden Livingston
>> > <halivingston at gmail.com>
>> > wrote:
>> >>
>> >> I was wondering if global variables can be candidates for
register
>> >> allocation. My use case is a global variable that is used in
every
>> >> function in my program.
>> >>
>> >> I'm wondering if it's better to pass it in, or let it
stay as a global.
>> >>
>> >> Passing it in will require a bit of work.
>> >> _______________________________________________
>> >> 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
>
>