similar to: [LLVMdev] Register allocation code owner

On May 17, 2010, at 6:21 PM, Chris Lattner wrote: > > On May 17, 2010, at 5:43 PM, Jakob Stoklund Olesen wrote: > >> As you may have noticed, I have been working on a fast register allocator in the last week. The new allocator is intended to replace the local allocator for debug builds. > > This is great work Jakob! What is required and when do you think you'll be

I tried using this flag and it gave me errors on code that otherwise assembles and runs just fine (using the version of Gcra.cpp that Lang wrote). So I'm wondering if I should really be using the flag? I'm using it like this: llc -verify-machineinstrs -load Debug/lib/P4.so -regalloc=gc xxx.bc Susan On 11/15/2012 01:13 PM, Jakob Stoklund Olesen wrote: > > On Nov 15, 2012, at

On Oct 31, 2012, at 1:41 PM, Madhusudan C.S <madhusudancs at gmail.com> wrote: > I have spent last 4 weeks trying to figure out how to implement > Interprocedural Register Allocation. I must admit that I was really > overwhelmed with LLVM's codebase while trying to figure this out :) > There is so much to know! I think I have reached a point where I > have some sort of

Ok, I've found that marking tiny live intervals as not spillable inside VirtRegAuxInfo::CalculateWeightAndHint is not playing nicely with very constrained regclasses, in my case a regclass composed of only one register. As a workaround, instead of marking them as not spillable, I've marked them with a very high spill cost and the regalloc is able to compile the function with good code

Hi Jakob, On Thu, Oct 4, 2012 at 2:31 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Oct 4, 2012, at 2:27 PM, "Madhusudan C.S" <madhusudancs at gmail.com> > wrote: > > Basically, the PrologEpilogInsertion pass will add a bit mask to >> MachineModuleInfo describing which registers are clobbered by the function >> being compiled. Later,

On May 24, 2011, at 8:22 AM, Jonas Paulsson wrote: > Hi (Jakob), > > in reference to the prior message below, I have the following follow-up questions, as I also need a scheduling pass > prior to regalloc. I need to do this in order to set VLIW-flags, so that the RA is aware of several MI's > per cycle with a redefined LiveRange::overlap-function. On a multiple-issue cycle, a

On Jan 7, 2013, at 4:58 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Hello Jakob, > > Did you get a chance to take a look into this, and if not, can you do it when you get some spare time? It's not likely I'll have time to look at this in the near future. I'd recommend you do it yourself. /jakob > 2012/12/19 Borja Ferrer <borja.ferav at gmail.com>

I looked at SplitKit, but I am not sure how to best do it, so it would be great if you could take a look. /Jonas On 2015-04-21 19:35, Quentin Colombet wrote: >> On Apr 21, 2015, at 7:40 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> >> >>> On Apr 21, 2015, at 05:39, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: >>> >>>

Hello Jakob, Did you get a chance to take a look into this, and if not, can you do it when you get some spare time? Thanks! 2012/12/19 Borja Ferrer <borja.ferav at gmail.com> > We did something like this back when the register allocator couldn't split >> live ranges. >> > > Yes, I remember the isWinToJoinCrossClass() function, removed here: > >

On Jan 9, 2013, at 10:46 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Ok, I've found that marking tiny live intervals as not spillable inside VirtRegAuxInfo::CalculateWeightAndHint is not playing nicely with very constrained regclasses, in my case a regclass composed of only one register. > As a workaround, instead of marking them as not spillable, I've marked them

On May 18, 2010, at 8:23 AM, Daniel Dunbar wrote: > You mention some potential issues on ARM, should we sort those out > before we enable it in Clang? It's somewhat more convenient to have > things be consistent. Sure, I'll be testing some ARM code today. There is also Evan's new REG_SEQUENCE instruction to verify. > I propose that at some point you just replace the old

Hi Jonas, I won’t have time to look at it this week after all. I’ll try to do that next week. If you do not hear back from me by end of next, do not hesitate to ping me! Cheers, -Quentin > On Apr 22, 2015, at 9:32 AM, Quentin Colombet <qcolombet at apple.com> wrote: > >> >> On Apr 21, 2015, at 11:49 PM, Jonas Paulsson <jonas.paulsson at ericsson.com

Hi Jakob, I have been trying to learn how the CodeGen passes work and I am playing around with the -debug-pass option. I tried implementing a bare CallGraphSCCPass based Pass in the CodeGen which basically does nothing for now. I mostly tried to replicate what RegAlloc passes do. I did this instead of modifying the existing RegAlloc passes to use CallGraphSCCPass because that was becoming way too

Hi (Jakob), in reference to the prior message below, I have the following follow-up questions, as I also need a scheduling pass prior to regalloc. I need to do this in order to set VLIW-flags, so that the RA is aware of several MI's per cycle with a redefined LiveRange::overlap-function. On a multiple-issue cycle, a register that gets killed can be reused by another MI - these live ranges do

Hi Jakob, Jonas et al, Jakob wrote: [...] > Jonas wrote: > [...] > > What's more, setting the GPR_CR class to 'not-spillable' would probably do the trick here as we > > basically do not want to do this, and I would not have to pre-allocate. But there is probably a > > better way, or? > > I am sorry, I simply don't understand what you are asking

See http://llvm.org/bugs/show_bug.cgi?id=4668 and http://llvm.org/bugs/show_bug.cgi?id=5010. The basic description of the issue (from http://llvm.org/bugs/show_bug.cgi?id=4668#c5): "The fundamental problem is we can't spill a register once it's fixed to a physical register." >From discussion on IRC: [17:14] <_sabre_> efriedma: sounds like a RA bug in linscan [17:14]

> On Apr 21, 2015, at 05:39, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > > Could it then be that the RegisterCoalescer should split live ranges when LIS->shrinkToUses() return true? Why does it not do that, when the verifier demands this? I think it should. That's an oversight.

On Sep 28, 2011, at 3:08 PM, Chris Lattner wrote: > > On Sep 27, 2011, at 12:11 AM, Leo Romanoff wrote: > >> >> >> It is true that names are not always reflecting the essense. But on the other hand, there is a lot of ongoing research on register allocation (and compilers in general) and it looks like more and more such efforts choose LLVM as a platform for

On Jun 21, 2011, at 9:23 AM, Jim Grosbach wrote: > > On Jun 21, 2011, at 8:51 AM, Jakob Stoklund Olesen wrote: > >> In the past, I've seen some pushback on the list against adding more register classes. You can see it in the code as well, TargetLowering::getRegClassForInlineAsmConstraint() returns a vector of registers instead of a real register class. >> >> What

On Sep 27, 2011, at 12:11 AM, Leo Romanoff wrote: > > > It is true that names are not always reflecting the essense. But on the other hand, there is a lot of ongoing research on register allocation (and compilers in general) and it looks like more and more such efforts choose LLVM as a platform for experimentation. Quite some results and comparisons are published. So, it would be nice