search for: globalregistervariables

Hi As part of a requirement that I have, I would like to have some globals reside in registers always. So these variables would not have a home location in memory. I realize the code generated would also need to be aware of this. I do have some ideas on how to change the code appropriately. But right now, I am more concerned about how to fit this requirement (sort of interprocedural) into the

...ore about the motivation. I suspect the solution may end up different if we understand the exact use-case. Sure. This is all about the ghccc. Here the original discussion between Chris Lattner and David Terei who initially implemented the llvm backend for ghc: http://www.nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt Cheers, moritz > — > Mehdi > > > >> >> Cheers, >> Moritz >> >>> On Mar 12, 2017, at 3:41 AM, Matthias Braun <matze at braunis.de> wrote: >>> >>> -mllvm xxx will pass options directly to the llvm libraries though...

...estion, what the difference between this and global register [1]? To me, they both seems to reserve particular register from being used by the compiler. If they're the same, I remember Chris objected to add global register feature in LLVM. Regards, chenwj [1] http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj

Chris recently wrote up a way to do this at http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt On Thu, Jul 16, 2009 at 1:53 PM, shreyas krishnan<shreyas76 at gmail.com> wrote: > Hi >   As part of a requirement that I have, I would like to have some > globals reside in registers always. So these variables would not have > a home location in memory. > I realize the co...

On 10/2/2012 9:36 AM, 陳韋任 (Wei-Ren Chen) wrote: > On Tue, Oct 02, 2012 at 09:23:27AM -0500, Matthew Curtis wrote: >> I'm adding support for -ffixed-<reg> for Hexagon and was wondering if I should >> do it in such a way that other targets get the support as well by default or if >> a given target back-end should have to explicitly opt-in for support. > What

...gisters doesn't actually store anything useful for this function then you can avoid passing it on to the next function so that the register will be free to use during the function. Here is a link to the original discussion about this problem and the solution: http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt You should also check out the GHC calling convention as there is a good chance you could use it to get what you want and not have to modify llvm at all. The calling conventions for X86 are defined in 'lib/Target/X86/X86CallingConv.td' in a very easy to read format. On X86-64 the argum...

Hi all, I'm working on using LLVM as a back-end for the Haskell GHC compiler. As part of that work I have modified LLVM to include a new custom calling convention for performance reasons as outlined previously in a conversation on this mailing list: http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt This custom calling convention on x86-32 needs to handle just 4 parameters, passing them in %ebx, %ebp, %esi, %edi. These are all callee saved registers. To implement the custom calling convention I change llvm in two places: 1) X86CallingConv.td : Add new calling convention. 2) X86Registe...

...nt to spend a lot of time on coding style changes prior to the initial review in case big changes to the code are needed. Best regards, The ErLLVM team [1]: http://www.it.uu.se/research/group/hipe [2]: http://www.erlang.org [3]: http://erllvm.softlab.ntua.gr [4]: http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt [5]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-April/048685.html -- Yiannis Tsiouris Ph.D. student, Software Engineering Laboratory, National Technical University of Athens WWW: http://www.softlab.ntua.gr/~gtsiour -------------- next part -------------- A non-text attachment was scrubbed...

On 04/03/2011 12:43 AM, Frits van Bommel wrote: > On Sat, Apr 2, 2011 at 9:46 PM, Yiannis Tsiouris > <yiannis.tsiouris at gmail.com> wrote: > >> I am not sure i made myself clear about what i want. I was wondering >> if there >> is a way to communicate to LLVM's register allocator and define which >> registers are pre-coloured and should not be used

...hanges prior to the initial review in case big changes to the > code are needed. > > Best regards, > The ErLLVM team > > [1]: http://www.it.uu.se/research/group/hipe > [2]: http://www.erlang.org > [3]: http://erllvm.softlab.ntua.gr > [4]: http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt > [5]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-April/048685.html -- Yiannis Tsiouris Ph.D. student, Software Engineering Laboratory, National Technical University of Athens WWW: http://www.softlab.ntua.gr/~gtsiour

...ied existing allocator. Modification would make sure the already allocated registers are not available. thanks again shrey On Thu, Jul 16, 2009 at 2:05 PM, Jeffrey Yasskin<jyasskin at google.com> wrote: > Chris recently wrote up a way to do this at > http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt > > On Thu, Jul 16, 2009 at 1:53 PM, shreyas krishnan<shreyas76 at gmail.com> wrote: >> Hi >>   As part of a requirement that I have, I would like to have some >> globals reside in registers always. So these variables would not have >> a home location in memo...

...orking on using LLVM as a back-end for the Haskell GHC compiler. As > part of that work I have modified LLVM to include a new custom calling > convention for performance reasons as outlined previously in a > conversation on this mailing list: > > http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt > > This custom calling convention on x86-32 needs to handle just 4 > parameters, passing them in %ebx, %ebp, %esi, %edi. These are all callee > saved registers. To implement the custom calling convention I change > llvm in two places: > > 1) X86CallingConv.td : Add ne...

...e anything > useful for this function then you can avoid passing it on to the next > function so that the register will be free to use during the function. > > Here is a link to the original discussion about this problem and the > solution: > > http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt > > You should also check out the GHC calling convention as there is a > good chance you could use it to get what you want and not have to > modify llvm at all. The calling conventions for X86 are defined in > 'lib/Target/X86/X86CallingConv.td' in a very easy to read form...

...g changes to the > > code are needed. > > > > Best regards, > > The ErLLVM team > > > > [1]: http://www.it.uu.se/research/group/hipe > > [2]: http://www.erlang.org > > [3]: http://erllvm.softlab.ntua.gr > > [4]: http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt > > [5]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-April/048685.html > > -- > Yiannis Tsiouris > Ph.D. student, > Software Engineering Laboratory, > National Technical University of Athens > WWW: http://www.softlab.ntua.gr/~gtsiour -- Yiannis Tsiouris Ph.D. stu...

Hi Matthias, what I’m observing right now is that replacing opt+llc with an clang invocation, and subsequently fewer intermediate files, increases the consumed time with -O0 by 200%. We used to always run opt with -mem2reg -globalopt, and I believe those are not part of -O0 (is there an easy way to list all passes that -OX flags to clang imply for the optimizer and code gen?). Could the IR imply