similar to: [LLVMdev] Subregister definition / use

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

On Jul 28, 2010, at 12:25 PM, Carlos Sánchez de La Lama wrote: > Which after register coalescing gets transformed into: > > 36 %reg16404:1<def> = LDWr %reg16384, 0; mem:LD4[<unknown>] > 76 %reg16394<def> = LDWr %reg16386<kill>, 0; mem:LD4[<unknown>] > 124 %reg16404<def> = INSERT_SUBREG %reg16404, %reg16394<kill>, 2 > 132

I've been working on patches to improve subregister liveness tracking on llvm and I wanted to inform the llvm community about the overal design/motivation for them. I will send the patches to llvm-commits later today. Greetings Matthias Braun Subregisters in llvm ==================== Some targets can access registers in different ways resulting in wider or narrower accesses. For

Hi all, We are working on a backend for a machine that has 4-wide vector register & ops, *but* not vector loads. All the vector register elements are directly accesible, so VI1 reg (Vector Integer 1) has I4, I5, I6 and I7 as its (integer) subregisters. Subregisters of same reg *never* overlap. Therefore, vector loads are lowered to scalar loads followed by a chain of INSERT_VECTOR_ELTs. Then

Hi, I have a problem regarding sub-register definitions and LiveIntervals on our target. When a subregister is defined, other parts of the register are always left untouched - they are neither read or def:ed. It however seems that Codegen treats subregister definitions as somehow clobbering the whole register. The SSA-code looks like this after isel: (Reg0 and Reg1 are 16bit registers. Reg2,

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

What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the other half would work. For example, this is an illegal sequence of instructions,

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.

This error indicates that its trying to create a lane mask larger than 32 bits. Without seeing all of your subregister definitions I can't tell if that's correct of if there's something wrong with your register definitions. If it is correct then you need to change all the associated LaneMask code in CodeGenRegisters.cpp, include/llvm/MC/LaneBitMask.h and probably elsewhere to use a

Currently it will always spill / restore the whole vreg but only spilling the parts that are actually live would be a nice addition in the future. Looking at r192119': if "mtlo" writes to $LO and sets $HI to an unpredictable value, then it should just have an additional (dead) def operand for $hi, shouldn't it? Greetings Matthias Am 10/8/13, 11:03 AM, schrieb Akira

Hello, i am trying to construct a register of size 65536 bit by combining 2 registers of 32768 bits. both the 32768 bit registers are different so i have to use the following method let SubRegIndices = [sub_32768bit, sub_32768bit_hi], CoveredBySubRegs = 1 in but i am getting following error.. error:Ran out of lanemask bits to represent subregister

please tell me how to solve this lanemask bits issue? how to increase lanemask bits? On Fri, Jul 14, 2017 at 8:33 PM, hameeza ahmed <hahmed2305 at gmail.com> wrote: > > Hello, > i am trying to construct a register of size 65536 bit by combining 2 > registers of 32768 bits. both the 32768 bit registers are different so i > have to use the following method > > let

I see, thanks. I used to work with GCC, which has an SSA-property verification run after each pass. It is surprising to find that LLVM does not check this! Jonas > Subject: Re: [LLVMdev] subregisters, def-kill > From: stoklund at 2pi.dk > Date: Thu, 19 May 2011 15:39:40 -0700 > CC: llvmdev at cs.uiuc.edu > To: jnspaulsson at hotmail.com > > > On May 19, 2011, at 7:47

Woud it be reasonable to assert that TargetRegisterInfo::isSubRegister() is a transitive relation? In other words, if A is a subregister of B and B is a subregister of C then A is a subregister of C. With this assumption, we could teach TableGen to sort registers topologically such that all the subregisters of R are numbered R+1, R+2, ... This produces better locality of reference and allows

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 Wednesday 23 January 2008 02:01, Evan Cheng wrote: > > Can you explain the basic mechanics of the live interval splitting > > code? > It's splitting live intervals that span multiple basic blocks. That > is, when an interval is spilled, it introduce a single reload per > basic block and retarget all the uses to use the result of the single > reload. It does not

Hi, I am trying to take 16 bit memory reads and combine them to a single 32 bit read. I am having trouble to make the code simply read 32 bytes and the use the subregisters accordingly, without unnecessary copying. I have tried two techniques, in the MachineFunction: 1. replace the MachineOperands in the users of the data with the new register/subregister index. This yields an assert failure

On Oct 8, 2013, at 2:06 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the

On May 9, 2011, at 9:00 AM, Jonas Paulsson wrote: > Hi, > > I am trying to take 16 bit memory reads and combine them to a single 32 bit read. I am having trouble to make the code simply read 32 bytes and the use the subregisters accordingly, without unnecessary copying. > > I have tried two techniques, in the MachineFunction: > > 1. replace the MachineOperands in the users