search for: reg_sequence

Hi all, Can someone please explain me how to use REG_SEQUENCE in tablegen? The arch i'm writing backend for has 32-bit regs, and it has a couple of 64-bit load/store instructions which use two neighboring regs at once, which i'm trying to employ using virtual regs with subs. For example, it I want to move one 64-bit virtual reg to another, I'm tr...

...gh in reality they shouldn't conflict. That is, they are individual registers and would be better compared as such for register coalescing decisions (CoalescerPair::Partial = 0). For example, I have a super reg that has r20, r21, r22, and r23 physical registers. This super reg is the dest of a reg_sequence which generates 4 COPY MIs. The first COPY coalesces (merging into r20), but the vregs for r21-r23 (SUPER_RC:%vreg50:subreg1..subreg3) are never coalesced after that because doing so generates inteference on %vreg50, the "parent" super reg. Is there a way to work around this? It causes u...

...ity they shouldn't conflict. That is, they are individual registers and would be better compared as such for register coalescing decisions (CoalescerPair::Partial = 0). > > For example, I have a super reg that has r20, r21, r22, and r23 physical registers. This super reg is the dest of a reg_sequence which generates 4 COPY MIs. The first COPY coalesces (merging into r20), but the vregs for r21-r23 (SUPER_RC:%vreg50:subreg1..subreg3) are never coalesced after that because doing so generates inteference on %vreg50, the "parent" super reg. > > Is there a way to work around this? I...

...onflict. That is, they are individual registers > and would be better compared as such for register coalescing decisions > (CoalescerPair::Partial = 0). > > > > For example, I have a super reg that has r20, r21, r22, and r23 physical > registers. This super reg is the dest of a reg_sequence which generates 4 > COPY MIs. The first COPY coalesces (merging into r20), but the vregs for > r21-r23 (SUPER_RC:%vreg50:subreg1..subreg3) are never coalesced after that > because doing so generates inteference on %vreg50, the "parent" super reg. > > > > Is there a wa...

On May 31, 2013, at 4:59 PM, Joe Matarazzo <joe.matarazzo at gmail.com> wrote: > I think the last time I pulled from trunk was probably end of last year. Some time ago. Does your reply intimate it's fixed on trunk? Yes, it’s been fixed recently. /jakob

...s for your reply. > > The <undef> flag goes on NewMI_1 because the virtual register B isn't live > before that instruction. > > But you probably shouldn't be doing this yourself. Your NewMI code isn't in > SSA form because B has multiple definitions. Just use a REG_SEQUENCE > instruction, and let the register allocator do the transformation for you. Aaargh. So you mean something like this ? New_MI_1:: Vreg1 = 0 ; Vreg1 and Vreg2 are 32 bit virt. regs. New_MI_2:: Vreg2 = COPY C:lo_sub_reg. New_MI_3:: B= REG_SEQUENCE<Vreg1, hi...

Was it the subreg lane masks / mapping that was added to address the missed coalescing? This solution is nice, but I don't think it'll work for me. I have 8-element vector registers that can be grouped into virtual super regs for bulk save/restore, and as soon as I have more than 4 in a tuple, the unsigned int used to hold the lane masks overflows and switches over to the "bit 31 set

...ister Allocator ***: # Machine code for function accumconv: Function Live Ins: %a0_gh in %vreg0, %a1_gh in %vreg1 BB#0: derived from LLVM BB %0 Live Ins: %a0_gh %a1_gh %vreg1<def> = COPY %a1_gh; aNgh_0_7:%vreg1 [...] %vreg56<def> = mv_any16 0; aNl_0_7:%vreg56 %vreg57<def> = REG_SEQUENCE %vreg1, hi24, %vreg56, lo16; aN40_0_7:%vreg57 aNgh_0_7:%vreg1 aNl_0_7:%vreg56 So the in-argument in a1_gh is saved in vreg1, and used later in a REG_SEQUENCE instruction to write a full register, vreg57. After the REG_SEQUENCE has been eliminated we instead get 16 %vreg57:hi24<def> = COPY...

...Coalescing: This ends up as overlapping live-ranges, where the value numbers did not become one, and Interference is reported. This must then be considered bad code in LLVM. But if I write %reg16507<def> = COPY %reg16445; %reg16508<def> = COPY %reg16468; %reg16506<def> = REG_SEQUENCE %reg16507, hi16, %reg16508, lo16; %reg16509<def> = st_2_1_postMod %reg16506, %reg16441, %reg16454, pred:20, pred:%CCReg; then, there is not an erroneous live-range that interferes, so it coalesces. I suppose this means that the first version with INSERT_SUBREG's is breaking the SSA...

...32 bit reg: %vreg20<def> = toHi16_low0_pseudo %vreg2; reg32:%vreg20 hi16:%vreg2 expands to %vreg2<def> = COPY %a2h; hi16:%vreg2 %vreg43<def> = mov 0, pred:0, pred:%noreg, %ac0<imp-use>, %ac1<imp-use>; lo16:%vreg43 %vreg20<def> = REG_SEQUENCE %vreg2, hi16, %vreg43, lo16; reg32:%vreg20 hi16:%vreg2 lo16:%vreg43 Becomes 16L %vreg20:hi16<def,undef> = COPY %a2h<kill>, %vreg20<imp-def>; reg32:%vreg20 368L %vreg20:lo16<def> = mov 0, pred:0, pred:%noreg, %ac0<imp-use>, %ac1<imp-use>;...

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

...es has marked the high part dead, even though the super-register is used at SlotIndex 748. Why is this? Should I add anything special to the basic BuildMI calls? That code is not in SSA form as LiveVariables requires, there can only be one def per virtual register. You need to use INSERT_SUBREG or REG_SEQUENCE to do this. /jakob

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

...d in the DoubleReg. > > The optimization opportunity here is that if %vreg2 and %vreg1 are allocated > the right registers (odd for %vreg2 and even for %vreg1) then the COMBINE_rr > instruction can be made redundant. Your COMBINE_rr instruction does exactly what the target-independent REG_SEQUENCE instruction does. The important difference is that REG_SEQUENCE is recognized by the coalescer to do exactly what you need. You simply need to generate REG_SEQUENCE instead of COMBINE_rr. Look at the ARM target for examples. /jakob

...undef> flags be set in both as per 2 above ? The <undef> flag goes on NewMI_1 because the virtual register B isn't live before that instruction. But you probably shouldn't be doing this yourself. Your NewMI code isn't in SSA form because B has multiple definitions. Just use a REG_SEQUENCE instruction, and let the register allocator do the transformation for you. /jakob

...it doesn't understand that a live interval can be partially defined and so may not interfere. The opposite direction should be fine - using EXTRACT_SUBREG to get small registers from the larger one. Your stores ought to coalesce properly. > Is there a way to solve this? What Bob said. Use REG_SEQUENCE. You may have to use LLVM from Subversion to do that. Your machine code looks like you are using 2.7. > As an alternate approach, I also tried to do a custom InstrInserter that > ended with the correct code just after MI emission: > > 68 %reg16392<def> = LDWr %reg16384<kill&g...

Hi, This question relates to the undef flag in the context of sub-register def operands. 1) Firstly, the documentation (comments in the source code) says that in a sub-register def operand, the "IsUndef" flag refers to the part of the register that is not written. 2) Further, the documentation about readsReg() states that a sub-register def implicitly reads the other parts of the

...ay 18, 2010, at 8:23 AM, Daniel Dunbar wrote: > You mention some potential issues on ARM, should we sort those out > before we enable it in Clang? It's somewhat more convenient to have > things be consistent. Sure, I'll be testing some ARM code today. There is also Evan's new REG_SEQUENCE instruction to verify. > I propose that at some point you just replace the old local register > allocator with the new one, and rename the old one. Then clients don't > need to change, and we can keep the old one available for a little > while if we want, for testing. I am not a b...

...ed MVT::Untyped a while back to address this kind of use case. You can construct node of MVT::Untyped, and as long as the InstrEmitter can infer what register class they can map to from their uses, everything should just work. Of course, it's only been seriously tested with register sequence (REG_SEQUENCE) nodes. --Owen

Hi Jakob, > New_MI_1:: Vreg1 = 0 ; Vreg1 and Vreg2 > are 32 bit virt. regs. > New_MI_2:: Vreg2 = COPY C:lo_sub_reg. > New_MI_3:: B= REG_SEQUENCE<Vreg1, hi_sub_reg, Vreg2, lo_sub_reg> ; B > is a > 64 bit virt reg. I used this approach and it worked find until I hit, what I believe is, a bug in the register coalescer. When the register coalescer cannot trivially coalesce a copy, say C,, it calls AdjustCopiesBackFrom. In this fu...