search for: regallocgreedi

I can generate debug info using opt like this: opt < a.bc > /dev/null -mypass -debug But I don't know how to do it using llc. I check http://llvm.org/docs/CommandGuide/llc.html there are not any information about debug flags. Purpose EX: I want to print all the DEBUG(dbgs()......) in llvm/lib/CodeGen/RegAllocGreedy.cpp . What should I do? -------------- next part -------------- An HTML

Hi, I have worked a little on the PBQP register allocator, and it is quite clear (at least to me) that it is not even a serious alternative to RegAllocGreedy at the moment, due to the poor handling of spilling. As Arnaud wrote below, it is not optimizing spilling at all, but rather just spills anything that does not get an assignment. The result is a lot more spill/reload instructions than

Hi, I would like to ask about PBQPs use of InlineSpiller. The code output when using PBQP gets a lot bigger compared to when using RegAllocGreedy. PBQP does not split the live intervals, and a lot more (often redundant) reload instructions are emitted as a result, it seems. I wonder why this is, and if there are any plans to improve on this point? /Jonas Paulsson -------------- next part

When compiling C code below for AArach64, I saw that shrink-wrapping didn't happen due to the very early uses of CSRs in the entry block. So CSR spills/reloads are executed even when the early exit block is taken. int getI(int i); int foo(int *P, int i) { if (i>0) return P[i]; i = getI(i); return P[i]; } It's not that hard to find such cases where

Hi Quentin, Jonas, Splitting fits in with PBQP reasonably well, at least conceptually. The PBQP graph is designed to be mutable, so there is no problem with updating it when splitting. As I see it, there are two logical places to integrate splitting into PBQP: 1) Split during spilling -- If a PBQP solution selects the spill option for a node, rather than spill immediately, split the interval

On 2017-10-27 19:50, Hal Finkel wrote: > On 10/27/2017 03:32 PM, Jun Lim via llvm-dev wrote: > >> When compiling C code below for AArach64, I saw that shrink-wrapping >> didn't happen due to the very early uses of CSRs in the entry block. >> So CSR spills/reloads are executed even when the early exit block is >> taken. >> >> int getI(int i); >>

Both approaches are not exclusive. I would even think it makes sense to have a pre-split pass to prepare the graph, with a global view, and later on use use trySplit (or an equivalent) to handle the local coloring issues. From: Quentin Colombet [mailto:qcolombet at apple.com] Sent: 09 March 2015 23:08 To: Lang Hames Cc: Jonas Paulsson; llvmdev at cs.uiuc.edu; Arnaud De Grandmaison Subject:

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

On 2017-10-30 21:20, Hal Finkel wrote: > On 10/30/2017 12:20 PM, junbuml at codeaurora.org wrote: >> On 2017-10-27 19:50, Hal Finkel wrote: >>> On 10/27/2017 03:32 PM, Jun Lim via llvm-dev wrote: >>> >>>> When compiling C code below for AArach64, I saw that shrink-wrapping >>>> didn't happen due to the very early uses of CSRs in the entry

How precise is the interference checking (to my mind, a great weakness of linear scan)? Is there way to do coalescing (the great strength of coloring)? I ask these questions because we (guys I work with) see loops where there's a little register juggling that seems unnecessary. Is there a paper that describes what y'all do? Thanks, Preston On Mon, Sep 10, 2018 at 9:57 AM, Matthias

Running a build on r122586, gave me the following warnings with: gcc version 4.2.1 (Apple Inc. build 5664) =================================================== <dir>/llvm/lib/Analysis/InstructionSimplify.cpp:82: warning: comparison between signed and unsigned integer expressions <dir>/llvm/lib/Analysis/InstructionSimplify.cpp:106: warning: comparison between signed and unsigned

Why have we ended up using linear-scan register allocation by default (instead of, e.g., coloring)? Thanks, Preston -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180910/2f468e56/attachment.html>

On 2017-11-10 07:47, Nemanja Ivanovic wrote: > One thing I thought about doing a while back and never really wrote a > POC for is the following: > - Make FirstCSRCost a property of the MachineBasicBlock (or create a > map of MBB* -> FirstCSRCost) > > - Implement a pre-RA pass that will populate the map as follows: > > - Identify all blocks with calls > > -

> The underlying liveness datastructure is a list of ranges where each vreg is alive > (ranges in terms of instructions numbered). I remember a couple of later linear scan > papers describing the same thing (Traub et.al. being the first if I remember correctly). > That should be as accurate as you can get in terms of liveness information. It depends on the details. For example, given

I will be removing RegAllocLinearScan and VirtRegRewriter from trunk shortly after we cut the 3.0 release branch. LLVM 3.0 will still ship with the linear scan register allocator, but the default will be the new greedy allocator. Linear scan can be enabled by passing '-regalloc=linearscan -join-physregs' to llc. RegAllocLinearScan and VirtRegRewriter need to go away soon because they

On 2017-11-14 17:22, Quentin Colombet wrote: > Hi, > > I think it is kind of artificial to tie the CSRCost with the presence > of calls. > I think I’ve already mentioned it in one of the review, but I > believe it would be better to differentiate when we want to use a CSR > to avoid spilling or to avoid splitting. CSR instead of spilling is > good, CSR instead of

On 2017-11-17 13:10, Quentin Colombet wrote: >> On Nov 16, 2017, at 2:31 PM, junbuml at codeaurora.org wrote: >> On 2017-11-14 17:22, Quentin Colombet wrote: >> >>> Hi, >>> I think it is kind of artificial to tie the CSRCost with the >>> presence >>> of calls. >>> I think I’ve already mentioned it in one of the review, but I

The phi instruction is irrelevant; just the way I think about things. The question is if the allocator believes that t0 and t2 interfere. Perhaps the coalescing example was too simple. In the general case, we can't coalesce without a notion of interference. My worry is that looking at interference by ranges of instruction numbers leads to inaccuracies when a range is introduced by a copy.

Hi, There are some warnings in the LLVM and clang code bases: ---------------------------- llvm[0]: Compiling RegAllocGreedy.cpp for Release+Asserts build /Users/filcab/dev/stuff/llvm/llvm/include/llvm/ADT/SmallVector.h: In member function ‘void<unnamed>::RAGreedy::calcLiveBlockInfo(llvm::LiveInterval&)’: /Users/filcab/dev/stuff/llvm/llvm/include/llvm/ADT/SmallVector.h:325: warning: