[LLVMdev] Are global variables candiates for register allocation?

[Hayden Livingston]

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