similar to: [LLVMdev] Register coalescing (Subregs and SuperRegs)

On May 14, 2012, at 4:09 PM, "Pranav Bhandarkar" <pranavb at codeaurora.org> wrote: > Hi, > > Consider this MI code from the hexagon backend. > ------------------------------------------------------------------ > 16B %vreg0<def> = COPY %R0<kill>; IntRegs:%vreg0 > 32B %vreg1<def> = LDriw %vreg0, 0; mem:LD4[%a] >

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Pranav Bhandarkar > Sent: Thursday, April 26, 2012 5:24 PM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] MemRefs in a Load Instruction > > Hi, > > On the hexagon target, I have written a following combiner pattern. >

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

I have already written about something similar (either on the list, or in private communication), so this may look familiar. Here's a scenario I'm observing: First, we have some innocent looking code: vreg(32) = x // vreg(32) = 32-bit register ... = vreg(32) [...] vreg(64).low_half = vreg(32) // vreg(64) = 64-bit register [...] then, after register

On Jul 5, 2012, at 6:01 PM, "Pranav Bhandarkar" <pranavb at codeaurora.org> wrote: > 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

Hi, On the hexagon target, I have written a following combiner pattern. ********************************************* def: Pat<(i64 (or (i64 (shl (i64 (extloadi32 (i32 (add IntRegs:$src1, s11_2ExtPred:$offset1)))), (i32 32))), (i64 (zextloadi32 ADDRriS11_2:$src2)))), (i64 (COMBINE_rr

On Jul 8, 2012, at 3:42 PM, Sergei Larin <slarin at codeaurora.org> wrote: > ********** EXPANDING POST-RA PSEUDO INSTRS ********** > ********** Function: main > real copy: %R15<def> = COPY %R4, %D2<imp-use,kill>, %D7<imp-use,kill>, > %D7<imp-def> > replaced by: %R15<def> = TFR %R4, %D7<imp-def> > > The R4 is a subreg of D2 double

Hello Jakob and everyone, I am observing an issue with MCRegUnitIterator in my back end, and trying to reverse engineer some of the table gen magic around it, but if you or someone readily knows the answer, I would highly appreciate it. Here is the problem. In my back end we have a rather simple int register file structure: // Integer registers. def R0 : Ri< 0, "r0">,

Arnold, It is not my code per say - this is what is done in LiveIntervalAnalysis.cpp collectRanges(), it wants to iterate over "units" of D1 (whatever they are assumed to be), but right there it associates them with actual physical register live ranges (see the tread below), and it does it wrongly. I was trying to pinpoint exactly to where the issue is, but there are too many

Hello everyone, I am running into an obscure issue with ExpandPostRA. Does anyone recognizes the following: The pass replaces a real copy with a "transfer" instruction: ********** EXPANDING POST-RA PSEUDO INSTRS ********** ********** Function: main real copy: %R15<def> = COPY %R4, %D2<imp-use,kill>, %D7<imp-use,kill>, %D7<imp-def> replaced by:

Hi Sergei, Register units != sub registers. Register units are an abstraction to describe overlapping of registers effectively. You probably wanted to use MCSubRegIterator. On Thu, Aug 30, 2012 at 2:30 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Hello Jakob and everyone, > > I am observing an issue with MCRegUnitIterator in my back end, and trying > to reverse

Hi Jakob, Thanks 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

Sure I will split it and put it in two patches. Give me few hours. I need to test those patches. Sirish On 4/19/2012 8:40 AM, Tom Stellard wrote: > On Wed, Apr 18, 2012 at 11:18:05PM -0500, Sirish Pande wrote: >> Hi, >> >> Here's a patch for Hexagon Packetizer for review. This patch does >> not yield any warnings. >> > Would it be possible to split this

Hi, I was wondering if there is a way to specify macros to help shorten rewriting patterns like these: def : Pat <(v4i8 (mul (v4i8 IntRegs:$a), (v4i8 IntRegs:$b))), (v4i8 (VTRUNEHB (v4i16 (VTRUNEWH (v2i32 (VMPYH (v2i16 (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$a))), subreg_hireg)), (v2i16 (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8

Andy, Lang, Thanks for the suggestion. I have spent more time with it today, and I do see some strange things in liveness update. I am not at the actual cause yet, but here is what I got so far: I have the following live ranges when I start scheduling a region: R2 = [0B,48r:0)[352r,416r:5)... R3 = [0B,48r:0)[368r,416r:5)... R4 = [0B,32r:0)[384r,416r:4)... R5 = [0B,32r:0)[400r,416r:4)...

If the patterns only include SDNodes, then pattern fragments will work. I might be wrong, but I've yet to find a way to do it with machine instructions, which is what you seem to have here. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Sebastian Pop > Sent: Tuesday, June 19, 2012 3:39 PM > To:

Hi, below is an output of "llc -march=r600 -mcpu=cayman -print-before-all -debug-only=regalloc file.shader" command from llvm3.2svn. The register coalescing pass crashes when joining vreg12:sel_z with vreg13 registers, because it tries to access the interval liveness of vreg13... which is undefined. I don't know if it's a bug of the pass, or if my backend should do something

Hi Julien, > On Oct 28, 2014, at 2:14 AM, Rinaldini Julien <julien.rinaldini at heig-vd.ch> wrote: > > Hum, in fact, I'm still a bit lost ;) > > It seems to works in -O0, but in -O1, -O2 and -O3, I got this error (+ the dump of the function): > > # Machine code for function foo: Post SSA > Function Live Ins: %RDI in %vreg7 > > BB#0: derived from LLVM BB

Example: target triple = "powerpc64le-unknown-linux-gnu" define void @TestFoo() { entry_bb: br label %loop_bb loop_bb: %tmp = load float, float* undef %tmp1 = fmul float %tmp, 0x401F25E360000000 %tmp2 = fadd float %tmp1, 0x3FC1A7B960000000 %tmp3 = select i1 undef, float 0x401F25E360000000, float %tmp2 store float %tmp3, float* undef br label %loop_bb } The code above is

Ok, after a long detour I am back to where I have started. I think there is a problem at dep DAG construction. Let me try to convince you. Here is the C code we are dealing with: push () { struct xx_stack *stack, *top; for (stack = xx_stack; stack; stack = stack->next) top = stack; yy_instr = top->first; } If the loop never iterates, "top" will have