[LLVMdev] Are global variables candiates for register allocation?

Hayden Livingston halivingston at gmail.com
Wed Jul 1 13:13:22 PDT 2015


That really would solve my problem ... so I'll look out for your
potential future change.

For now though, it seems like I'll have to get this part of code
compiled with GCC. Sadness ensues.

On Wed, Jul 1, 2015 at 9:29 AM, Caldarale, Charles R
<Chuck.Caldarale at unisys.com> wrote:
>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hayden Livingston
>> Subject: Re: [LLVMdev] Are global variables candiates for register allocation?
>
>> 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.
>
> The trick we use for our global register variables (with unique values per thread) is to define additional calling conventions that include the registers of interest, thus avoiding having to change the C++ code (compiled with gcc) that invokes our dynamically generated functions.  We attach the appropriate convention to the functions built by LLVM, and also to calls back into our C++ code made by the generated functions.  Entry and exit IR in each function extracts the values as input arguments and returns them as results; outbound calls to C++ code construct the additional arguments from the original input values.  LLVM then takes care of insuring that the registers are correct at the boundaries, even if they are used for other purposes within the function.  (Note that we don't utilize any exception handling, which would likely complicate this somewhat.)
>
> This involves a small amount of change to X86CallingConv.td and some other auxiliary files, which has been trivial to keep up to date with new LLVM releases.  On our to-do list is figuring out some means of registering our calling conventions dynamically; if we ever get around to that, we would submit it for inclusion in trunk.
>
>  - Chuck
>
>




More information about the llvm-dev mailing list