similar to: [LLVMdev] Splitting live ranges of half-defined registers

Hi Ehsan, In some cases modulo scheduling will insert copy instruction that end up as real copies in the final code. It unavoidable in some cases. For example, let's say a instruction defining a value is scheduled in the first iteration, but one of its uses is scheduled two iterations later. In this case, the kernel needs to create a copy because there will be two values live in the

Hi all, I've come across a problem with register allocation which I have been unable to track down the root cause of. 6728B %vreg304<def> = COPY %vreg278; VRF128:%vreg304,%vreg278 6736B %vreg302<def> = COPY %vreg278; VRF128:%vreg302,%vreg278 6752B %vreg278<def,tied1> = foo %vreg278<tied0>, %vreg277, 14, pred:1, pred:%noreg, 5; VRF128:%vreg278 VRF64_l:%vreg277 * bar

On Jan 14, 2013, at 1:39 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 1/14/2013 3:16 PM, Jakob Stoklund Olesen wrote: >> >> On Jan 14, 2013, at 12:56 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >>> >>> My question is: is this something that was a part of the design? >> >> Yes, the register allocator

On Jan 14, 2013, at 12:56 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > 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 >

Hi, I have a problem in our 3.0-based backend that I'm not sure how it should be handled. In summary, I don't know if * The regalloc verifier is too picky? * The register allocator is at fault for spilling the full register when only parts of it are defined? * Something else? The architecture I'm compiling for has registers with three disjoint parts: g, h and l. In one function we

Hi - I replied to the original sender only by mistake. Sorry about that. When we started working on the pipeliner, and added it before the scheduler, we also were concerned that the scheduler or other passes would undo the work of the pipeliner. The initial thought was that we would add information (using metadata or some other way like you've suggested) to the basic block to tell the

On 1/14/2013 3:16 PM, Jakob Stoklund Olesen wrote: > > On Jan 14, 2013, at 12:56 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >> >> My question is: is this something that was a part of the design? > > Yes, the register allocator only deals in full-width virtual registers, so any copies or spills created will operate on the full register. I see.

Hi, I have some questions about the implementation of Software pipeline in MachinePipeliner.cpp. First, in hexagon backend, between MachinePipeliner and regalloc pass, there're some other passes like phi eliminate, two-address, register coalescing, which may change or insert intructions like 'copy' in MBB, and swp kernel loop may be destroyed by these passes. Why not put

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],IntRegs:%vreg1,%vreg0 48B %vreg2<def> = LDriw_indexed %vreg0<kill>, 4; mem:LD4[%add.ptr] IntRegs:%vreg2,%vreg0 64B

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

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

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

Hi Sergei, I just fixed the broken test case for PR13719 with r163107, but from the debugging output you've posted it suspect it won't fix your test case. Your analysis looks good - findLastUseBefore(..) doesn't appear to be handling physregs. I'm surprised that isn't causing more failures. I'll see if I can find a failing case in the LLVM test-suite (it's been a

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

Lang, I think I am getting closer to understanding this. The findLastUseBefore() should probably look something like this: // Return the last use of reg between NewIdx and OldIdx. SlotIndex findLastUseBefore(unsigned Reg, SlotIndex OldIdx) { SlotIndex LastUse = NewIdx; if (TargetRegisterInfo::isPhysicalRegister(Reg)) { for (MCRegUnitRootIterator Roots(Reg,

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 Sergei, Andy, Sorry - I got distracted with some other work. I'm looking into this and PR13719 now. I'll let you know what I find out. Sergei - thanks very much for the investigation. That should help me pin this down. Cheers, Lang. On Tue, Aug 28, 2012 at 2:33 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Andy, Lang, > > Thanks for the suggestion. >

Hi Lang, Just one more quick question. in LiveIntervalAnalysis.cpp In SlotIndex findLastUseBefore(unsigned Reg, SlotIndex OldIdx) Did you really mean to use for (MachineRegisterInfo::use_nodbg_iterator UI = MRI.use_nodbg_begin(Reg), UE = MRI.use_nodbg_end(); UI != UE; UI.skipInstruction()) {} Aren't we currently dealing with units,

Hello. Could you please tell me how can I optimize with the back end (llc) the following piece of assembly code generated by llc: // NOTE: my processor accepts loops in the form of REPEAT(num_times)..END_REPEAT R0 = ... REPEAT(256) R5 = R0; // basically unnecessary reg. copy REPEAT(256) R10 = LS[R4]; R2 = LS[R5]; R4 =

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