search for: insn1

Hi, all, When I schedule machine instructions in a VLIW way and packetize them, a problem is encountered, and I will show it use a simplified case as follows. ############ original instruction sequence ... insn1 ... jump LBB0_xx ... LBB0_xx: ... ############ expected instruction sequence after scheduling and packetizing insn1; jump LBB0_xx ... LBB0_xx: ... ############ generated instruction sequence insn1; jump LBB0_xx ... #BB#xx: ... BasicBlock BB#xx is commented out when insn1 and "jump LBB0_xx&...

...ketizing > > > > Hi, all, > > > > When I schedule machine instructions in a VLIW way and packetize them, a > problem is encountered, and I will show it use a simplified case as follows. > > > > ############ original instruction sequence > > ... > > insn1 > > ... > > jump LBB0_xx > > ... > > LBB0_xx: > > ... > > > > ############ expected instruction sequence after scheduling and packetizing > > insn1; jump LBB0_xx > > ... > > LBB0_xx: > > ... > > > > ############ generate...

...n the copies should be coalesced away. In the examples that you show below, it all depends in which iteration each instruction is scheduled and/or the order in which the instructions are scheduled. %vreg73<def> = PHI %vreg59, <BB#5>, %vreg62, <BB#6>; %vreg61<def> = INSN1 %vreg1, %vreg73; %vreg62<def> = INSN2 %vreg73, %vreg5; %vreg64<def> = INSN1 %vreg2, %vreg73; For some reason, the instruction defining vreg64 was scheduled after the instruction defining vreg62, which causes the copy to be generated. Then, the question is why did that happen?...

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

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

From: Andrew Trick [mailto:atrick at apple.com] Sent: 24 January 2014 21:52 To: Daniel Sanders Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) Subject: Re: New machine model questions On Jan 24, 2014, at 2:21 AM, Daniel Sanders <Daniel.Sanders at imgtec.com<mailto:Daniel.Sanders at imgtec.com>> wrote: Hi Andrew, I seem to be making good progress on the P5600 scheduler

Hi all, This is version three of the patches I previously posted here: v1: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ v2: https://lore.kernel.org/r/20200630173734.14057-1-will at kernel.org Changes since v2 include: * Actually add the barrier in READ_ONCE() for Alpha! * Implement Alpha's smp_load_acquire() using __READ_ONCE(), rather than the other

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

Hi debuginfo-cabal, tl;dr: Let's please consider using a new implementation of LiveDebugValues that produces richer information, might be slightly faster, but mostly will support the instruction referencing and value tracking paradigm from my RFC [0] rather than the location tracking that LiveDebugValues does today. In that RFC, the main motivator is to treat variable locations a bit more