similar to: Purpose of various register classes in X86 target

Hello Matthias, On 28 July 2017 at 04:13, Matthias Braun <mbraun at apple.com> wrote: > It's not that hard in principle: > - A register class is a set of registers. > - Virtual Registers have a register class assigned. > - If you have register constraints (like x86 8bit operations only work on > al,ah,etc.) then you have to create a new register class to express that.

I am working on a project where we are integrating an existing pre-RA scheduler into LLVM and we are trying to match our peak register pressure values with the machine instruction schedulers values while using X86. I am finding some mismatches in test cases like the one attached. The registers "AH" and "AL" are live-out but not live-in and I don't see that they are defined

On Wednesday 11 July 2007 15:07, Christopher Lamb wrote: > Could it be possible for there to be a harness type interface that > would allow coalescers that support both modes to be hooked into the > pass registration, and those that depend on the allocator not be > registered as passes? I have a patch for this kind of thing attached. Please take a look and let me know if it looks

I cannot figure out a particular PassManager error for what seem to be legal dependencies. Here is the situation. We have 5 passes, RegisterAllocator, FunctionLiveVarInfo, CoalesceCopies, DominanceForest, and UnionSSAVars, with dependencies as follows: class RegisterAllocator : public FunctionPass { . . . virtual void getAnalysisUsage(AnalysisUsage &AU) const {

Hi all, At the EuroLLVM BoF people asked where the design discussions around GlobalISel take place. Naturally, a lot of them take place at Apple, since they have the highest density of co-located GlobalISel devs, but we also have some in Phab. For those of you that are interested, please have a look at the following topics - discussions are progressing rather slowly and we definitely

Hi again, On 1 April 2017 at 15:09, Diana Picus <diana.picus at linaro.org> wrote: > If people feel it would be useful, we could also try to send a > weekly-ish email listing the pending reviews and any points that need > coordination. We're open to any suggestions on how we can communicate > better. Nobody said anything about this, but with people coming back from spring

On Tuesday 17 July 2007 14:21, David Greene wrote: > > I don't care for a MachineFunctionPass that can be directly called. I > > think it's a very good idea to keep the coalescers independent from > > the allocators. If that's desired, we should enhance passmanager so > > each allocator can run some sub-passes as part of the allocation > > pass. > >

Hello, all, I want to implement the register allocation algorithm described in the paper "Register Allocation via Coloring of Chordal Graphs, APLAS'05" in LLVM. This is a graph coloring algorithm that can find an optimal coloring of the interference graph in most of the cases. I've downloaded LLVM last week, and started studying the code. Basically, I have to implement: 1) A

Hi all, I cannot figure out why is named GenRegisterInfo.h.inc and not GenRegisterInfo.inc ... Is it for a dependency problem? Back again to compilation problems under win32 with VC llvm\lib\Analysis\DataStructure\Local.cpp(628) : error C2105: '--' needs l-value the line is: Result.mergeWith(getValueDest(**--CS.arg_end())); Can I submit patches for mutate it in something like:

On Tue, 12 Oct 2004, Paolo Invernizzi wrote: > Hi all, > I cannot figure out why is named GenRegisterInfo.h.inc and not > GenRegisterInfo.inc ... > Is it for a dependency problem? I'm not sure what you're saying here. In the X86 backend, for example, we generate both X86GenRegisterInfo.h.inc and X86GenRegisterInfo.inc. The former is #included into X86RegisterInfo.h and the

Hi David, Sorry I should have replied earlier. I really don't like this dual interface approach. To me, this muddles things without offering any real useful new functionalities. IMHO, if a register coalescer is tied to a particular allocator. Then either it should simply belong to that allocator or that we have to allow the allocator to act as a pass manager itself, i.e. it can

On Jul 11, 2007, at 11:39 AM, David Greene wrote: > On Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > >> I think the coalescer should be flexible enough to be run >> independent of >> the register allocator. For example, you may want to expose the >> copies >> induced by transforming out of SSA to the scheduler. If the >> scheduler is

On Sat, 29 Apr 2006, Fernando Magno Quintao Pereira wrote: > I want to implement the register allocation algorithm described in the > paper "Register Allocation via Coloring of Chordal Graphs, APLAS'05" in > LLVM. This is a graph coloring algorithm that can find an optimal coloring > of the interference graph in most of the cases. I've downloaded LLVM last > week,

Hi! I want to use LLVM for my own "pet" programming language compiler as a backend. Currently it generates C code, but I am not satisfied with this approach as generating high-level C (with proper type declarations!) is horrible. So here are my questions/problems with LLVM: 1.) Are there operations that add, sub, mul integers with overflow checking? How much work would it be to add

I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: _main: pushq %rbp Ltmp18: movq %rsp, %rbp Ltmp19: subq $320, %rsp Ltmp20: movl %ecx, -276(%rbp) I've tracked them back to emitPrologue in X86RegisterInfo.cpp. I'm wonder what's their purpose? They're filling up my symbol table... Cameron Esfahani

On Mon, 2007-07-16 at 16:19 -0700, Evan Cheng wrote: > Property changes on: llvm/include/llvm/CodeGen/RegisterAllocator.h > ___________________________________________________________________ > Name: svn:eol-style > + LF > > What's this? Its a property change. In Subversion every file and directory can have properties associated with them. For example the svn:ignore

On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: > > _main: > pushq %rbp > Ltmp18: > movq %rsp, %rbp > Ltmp19: > subq $320, %rsp > Ltmp20: > movl %ecx, -276(%rbp) > > I've tracked them back to emitPrologue in

When we discussed this our line of thought was like this: - LLVM IR already uses %name for SSA values which is closer to what a vreg is than to what a physreg is. It would be neat to draw that parallel to llvm IR. - We wanted another sigil for physregs so they are easy to differentiate from vregs to allow people to differentiate vregs/physregs even if they don't know all the physreg names of

I have noticed a strange behaviour when our internet connection was down a couple of hours last week. What happens is that asterisk starts running *really* slow. If I type "sip show peers" it sometimes responds correctly and shows all the connected peers, but sometimes I get an empty list (this seems to go in cycles). Also the connected polycom phones seems to be unable to place any

Hi, I'd like to propose extending the supported syntax for AssemblerPredicates to allow sets of SubtargetFeatures to be listed, but where only one in the list has to be enabled for the predicate to be true. The condition string which forms a AssemblerPredicate already allows multiple features to be defined, separated by commas, and this means all of these features must be present. For