similar to: [LLVMdev] Greedy regalloc

On Fri, 2019-08-30 at 10:03 -0700, Quentin Colombet wrote: > > On Aug 30, 2019, at 8:31 AM, Jesper Antonsson via llvm-dev < > > llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > After dead-mi-elimination I'm experiencing a machine verifier > > failure > > at this virtual subregister write: > > > > %5.sub1 = COPY undef

On Jan 19, 2012, at 2:16 AM, Patrik Hägglund <patrik.h.hagglund at ericsson.com> wrote: > Is it intended that in some cases it is necessary to use > "-disable-cross-class-join" to be sure the resulting code is ok? No. > I have several cases where cross class joins are carried out that makes > the code turn out illegal, because the "new" register class is

Hi, Is it intended that in some cases it is necessary to use "-disable-cross-class-join" to be sure the resulting code is ok? I have several cases where cross class joins are carried out that makes the code turn out illegal, because the "new" register class is not allowed in all instructions where it is now used. For example, by joining %vreg4, %vreg7 and %vreg9 the

Hi Dominik, Thanks for your reply. In my case, the Defs is the cause of the problem. Or rather, it is part of the problem, because when I remove it from the instruction TableGen gives me a different error message which concerns a part which is deeper into the pattern tree, so at least it is able to proceed beyond that part of the pattern. I have also stepped TableGen inside gdb and

Hi, I am in the process of porting our target to GlobalISel, and have encountered a problem. Nearly all instructions in our instruction set make modifications to a CC register, and hence are defined as follows: let ..., Defs = [CCReg] in def shfts_a32_imm7: Instruction<(outs OurRC:$dst), ...>; What's more, many of these instructions have patterns where the instruction itself

Hi Daniel, Thanks for replying; I was hoping to get in touch with you on this issue. I had a look at how SelectionIDAG does it when generating the matcher table, and it does consider the implicit defs as additional output. Here is the match table generated for the pattern: /* 0*/ OPC_CheckOpcode, TARGET_VAL(ISD::SIGN_EXTEND), /* 3*/ OPC_MoveChild0, /* 4*/ OPC_CheckOpcode,

Hi, After dead-mi-elimination I'm experiencing a machine verifier failure at this virtual subregister write: %5.sub1 = COPY undef %11 The machine verifier essentially complains that the rest of the register is undefined (a subregister write implies a "read" of the other parts). So the problem is that dead-mi-elimination has removed the previously existing defines of %5.sub0.

Thanks! Our bug is now fixed. Our getMatchingSuperRegClass is huge (more than 300 lines), messy, and incomplete. > Or you could just rebase. On trunk, TableGen writes this difficult function for you. That in itself would be a compelling reason to get the rebase to trunk done. I just curious how large the generated version will be. :-) /Patrik Hägglund -----Original Message----- From: Jakob

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

Hi, We're having an issue with TailDuplication in our out-of-tree target and it's this PHI-node that seems to be the cause of the trouble: %vreg2<def> = PHI %vreg0, <BB#2>, %vreg1, <BB#3>; rN:%vreg2 aNlh_0_7:%vreg0 aNlh_rN:%vreg1 Note that the defined %vreg2 has register class "rN" while the read %vreg0 has register class "aNlh_0_7".

If I write %reg16506<def> = INSERT_SUBREG %reg16506, %reg16445, hi16; #1 %reg16506<def> = INSERT_SUBREG %reg16506, %reg16468, lo16; #2 store %reg16506 #3 it will not coalesce, as LiveVariables: on #2: %16506 gets #2 as a kill #3: %16506 gets #3 as an additional kill LiveIntervalAnalysis:

On Jan 20, 2012, at 6:40 AM, Jonas Paulsson wrote: > > What exactly are you proposing? Why can't you do what the PowerPC and Hexagon targets do? > > Yes, I can move a CR to a GPR and save it to the stack, but due to a very irregular register file this is about 10 times more expensive than saving/restoring an ordinary register. These registers should basically never > have to

> On Jan 19, 2012, at 5:31 AM, Jonas Paulsson wrote: > LLVM would have to be extended with an RegClass/register-attribute 'spillable' > > > What exactly are you proposing? Why can't you do what the PowerPC and Hexagon targets do? Yes, I can move a CR to a GPR and save it to the stack, but due to a very irregular register file this is about 10 times more expensive

Hi, I have a problem with the assert in Tablegen: llvm-tblgen: /dev/shm/uabpath/dev-master/utils/TableGen/RegisterInfoEmitter.cpp:204: void <anonymous namespace>::RegisterInfoEmitter::EmitRegUnitPressure(llvm::raw_ostream &, const llvm::CodeGenRegBank &, const std::string &): Assertion `RU.Weight < 256 && "RegUnit too heavy"' failed. The reason for

To: Andrew Trick Hi, I write you directly as you are the commiter of the code I am having problems with for my target - see below. I wonder what you think about this? Thanks, Jonas ________________________________ From: Jonas Paulsson Sent: Thursday, December 06, 2012 4:14 PM To: llvmdev at cs.uiuc.edu Subject: Register classes, reg unit weights calculation in tablegen Hi, I have a problem

On May 19, 2011, at 7:47 AM, Jonas Paulsson wrote: > Hi, > > I am combining 16-bit registers to a 32 bit register in order to make a wide store, as per below: > > 732 %reg16506:hi16<def,dead> = COPY %reg16445<kill>; > 740 %reg16506:lo16<def> = COPY %reg16468<kill>; > 748 %r3<def,dead> = store %reg16506<kill>, %r3, > > As you can

Hi, I am combining 16-bit registers to a 32 bit register in order to make a wide store, as per below: 732 %reg16506:hi16<def,dead> = COPY %reg16445<kill>; 740 %reg16506:lo16<def> = COPY %reg16468<kill>; 748 %r3<def,dead> = store %reg16506<kill>, %r3, As you can see, LiveVariables has marked the high part dead, even though the super-register is used at

Help .. I've struggled with this for a few weeks and can't get anywhere. I'd like for someone to point me in the right direction, if possible. I have laid out below my complete samba setting in the hope that 1) Someone can find a solution to my current problem 2) It might help someone else, as I overcame a few problems with these settings myself, under samba 2.2.8a.. please note

Ok, thanks. Except the question was meant slightly different. Less w.r.t. organizing the register classes, and more w.r.t. implementation. I've noticed for instance that when trying to model this straight forwardly by writing a vreg from spills and reading this from fills (not further elaborated here), that the spiller can't handle vreg def-use pairs: there are assertions making sure a

Hi, I'm having some trouble understanding if the live intervals calculated for one of my testcases are correct or not. I have the following instructions: 272L %vreg67:lo<def> = mv_any16 65535; R:%vreg67 288L %vreg64:hi<def> = mv_any16 16383; R:%vreg64 304L %vreg64:lo<def> = COPY %vreg67:lo; R:%vreg64,%vreg67 320L %vreg6<def> = COPY %vreg64<kill>;