search for: regallocator

Hi, While investigating a performance issue with an internal codebase I came across what looks to be poor register allocation. I have constructed a small(ish) reproducible which demonstrates the issue (see test.ll attached). I have spent some time going through the register allocator to understand what is happening. I have also experimented with some small changes to try and improve the

Hi LLVM, I ran into a case where RegAlloc would insert a spill across instruction that had same register for output operand and implicit-def. The effect this had was that spill code would immediately overwrite the output result. Is this the expected result of setting up MyInst this way? In other words, does RegAlloc know to not insert spill in case it sees that output reg is same as one of

Hi Quentin, MyInst is a custom instruction that has implicit-defs of fixed registers. The implicit-defs are seen at the end of Instruction Selection. I'd like to add a report, but I am working on an out-of-tree backend based on 7.0. I can try to help reduce the testcase down. Filed https://bugs.llvm.org/show_bug.cgi?id=41790 Regards, Kevin On 2019-05-07 3:45 p.m., Quentin Colombet wrote:

On 11/23/07, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > Hi, Sanjiv, > > those passes operate on the whole machine function. Each machine > function contains many basic blocks. If a program has many functions, the > register allocator will be called as many times, i.e it does not do > interprocedural allocation. > > best, > >

Thanks again. One more question here: Since the regalloc works once per function, do I stil have access to the Call graph? Just saving information between regalloc passes for different functions may not be enough for my case. I will need to maintain the regalloc info of various passes in the call graph order. Anyways thanks for your inputs. I will get back if I need to learn more. Sanjiv On Nov

Great! I thought I had to look at our pipeline at O0 to make sure optimized regalloc was supported (https://bugs.llvm.org/show_bug.cgi?id=33022 <https://bugs.llvm.org/show_bug.cgi?id=33022> in mind). Glad I was wrong, it saves me some time. > On May 22, 2017, at 12:51 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > >> On 22 May 2017, at 09:09, Diana Picus

Dear Anton, you can add your register allocator strait iin the "lib/CodeGen/Passes.cpp", and then 're-make' it: "makellvm llc", on the top of lib/CodeGen. It is faster than running make from LLVMOBJDIR. The problem is that it only add to llc the changes on the lib/CodeGen directory. If you change other parts, a make from LLVMOBJDIR will synchronize it. Try adding

Hello, I'm trying to evaluate the different register allocation algorithms on LLVM using the same level of optimizations. Using version 3.3 the current register allocators available to use are "basic, fast, greedy and pbqp". However, I'm facing the following issues: 1) I can't run basic and PBQP allocators using the command line flags of the dragonegg

Hi Kristof, Thanks for the measurements. > On May 24, 2017, at 6:00 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > >> >> On 23 May 2017, at 21:48, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Great! >> I thought I had to look at our pipeline at O0 to make sure optimized regalloc was

Hi, again, I think you can do it in the same way that the other allocators have been coded, i.e extend RA, register the pass and so forth. I am not sure about the best way to pass information among a run of RegAlloc to the other, maybe the other guys in the list could suggest something. Yet, you can always dump it into a file, and read it again, everytime it is necessary. Remember that

On Thu, 3 Aug 2006, Jim Laskey wrote: > To force the load/linking of your register allocator into the llc/lli tools, > add your create function's global declaration to "Passes.h" and add a > "pseudo" call line to "llvm/Codegen/LinkAllCodegenComponents.h" . Another note: with this new functionality you should be able to dynamically load register

Hi! I've did what Jim Laskey wrote but llc didn't reckognize my regalloc option. So I moved my allocator implementation into seperate folder within CodeGen and wrote separate makefile for it (like in "Writing an LLVM pass" tutorial). But when I run "make" from LLVMOBJDIR it doesn't enter the RegAlloc directory and when linking llc an error like

Hi! I developed a register allocator within LLVM and now I need to test its efficiency. Can I do this using llvm-test package? Do llvm tests check all available regalloc options automatically? If not, then what modifications should I do to the test files? It would be great if I could test my algo along with linearscan and compare the results. Thanks. Tony. -- "Nae king! Nae quin! Nae

Hello, I noticed the following interesting code sequence while compiling a piece of code with the backend I'm developing. Probably this issue is for Jakob, but anyways this is what I'm getting: STDWPtrQRr <fi#12>, 0, %R25R24; mem:ST2[FixedStack12](align=1) STDWPtrQRr <fi#12>, 0, %R25R24; mem:ST2[FixedStack12](align=1) STDWPtrQRr <fi#13>, 0, %R23R22;

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 27, 2012, at 10:20 AM, Borja Ferrer wrote: > Hello, > > I noticed the following interesting code sequence while compiling a piece of code with the backend I'm developing. Probably this issue is for Jakob, but anyways this is what I'm getting: > > STDWPtrQRr <fi#12>, 0, %R25R24; mem:ST2[FixedStack12](align=1) > STDWPtrQRr <fi#12>, 0, %R25R24;

Hi Kristof, Thanks for going back so fast! > On May 24, 2017, at 12:57 PM, Kristof Beyls <kristof.beyls at arm.com> wrote: > >> >> On 24 May 2017, at 19:31, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Hi Kristof, >> >> Thanks for the measurements. >> >>> On May 24, 2017, at

> Hi! > > I developed a register allocator within LLVM and now I need to test its > efficiency. Can I do this using llvm-test package? > Do llvm tests check all available regalloc options automatically? If not, > then what modifications should I do to the test files? > It would be great if I could test my algo along with linearscan and compare > the results. > >

Hi Quentin, > It sounds like you only need the earlyclobber description for the N, N > variant. > In other words, as long as you use different opcodes for widen-op NN and > widen-op WN, you model exactly what you want. > > What am I missing? > we are using different opcodes for widen-op NN and widen-op WN. My understanding is that not setting earlyclobber to the W, N

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