similar to: LLC does not do proper copy propagation (or copy coalescing)

Hello. I'm writing a back end for my research SIMD processor that has an assembly language that is blocked structured, with one-level loops. An example program with my assembly language: REPEAT_X_TIMES(Param2) R0 = LS[offset_A]; END_REPEAT; The LLVM code somewhat equivalent to the above ASM program is: vector.body: %index = phi i64 [

Hi Alex, You might find it useful to look at how lib/Target/PowerPC/PPCCTRLoops.cpp works. -Hal ----- Original Message ----- > From: "Alex Susu via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, May 30, 2016 5:09:37 PM > Subject: [llvm-dev] Back end with special loop instructions > > Hello.

Hello. Does anybody have an idea why I'm getting the error below when using llc with arguments -O1 -disable-cgp? Note that this error is not given when using llc -O0. (I'd like to mention also I'm using custom Instruction selection for BUILD_VECTOR, which gets converted in my back end's machine instrution VLOAD_D, although the custom code seems to always select

On Jul 11, 2007, at 11:39 AM, David Greene wrote: > On Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > >> I think the coalescer should be flexible enough to be run >> independent of >> the register allocator. For example, you may want to expose the >> copies >> induced by transforming out of SSA to the scheduler. If the >> scheduler is

Need some guidance about the right way to model this -- how would you model a backend with a handful of read-only physical registers that are passed as arguments to a function? I was emitting copyFromReg nodes in the LowerFormalArgument() routine, but then the register allocator and coalescer are resisting coalescing the COPY MI's for various reasons - for example, the read-only register class

On Oct 10, 2008, at 1:44 PM, Óscar Fuentes wrote: > OvermindDL1 <overminddl1 at gmail.com> writes: > > [snip] > >> On this first compile everything compiled except for llc and lli, >> which did not link due to: >> unresolved external symbol "class llvm::FunctionPass * __cdecl >> llvm::createPBQPRegisterAllocator(void)" > > That is because

Hello again, I am trying to implement an optimization pass for PowerPC such that simple loops use the special "counter register" (CTR) to track the induction variable. This is helpful because, in addition to reducing register pressure, there is a combined decrement-compare-and-branch instruction BZND (there are also other related instructions). I started this process by converting the

Hello. I come back to this thread. But I want to ask a slightly different question. Is there a way to have LLVM IR language intrinsics that are given at construction time a string that is written at assembly generation time as it is? (so, basically having placeholders of strings in LLVM that remain untouched until the end, including code generation time.) More exactly, I would

On Jun 7, 2012, at 7:31 PM, Hal Finkel wrote: > 112B BB#1: derived from LLVM BB %for.body, ADDRESS TAKEN > Predecessors according to CFG: BB#0 BB#1 > %vreg12<def> = PHI %vreg13, <BB#1>, %vreg11, <BB#0>;CTRRC8:%vreg12,%vreg13,%vreg11 > %vreg13<def> = COPY %vreg12<kill>; CTRRC8:%vreg13,%vreg12 > %vreg13<def> = BDNZ8 %vreg13,

Hello, I have a minimal testcase which crashes RegisterCoalescer in my out-of-tree target. It only crashes in Debug builds of llc---not in Release builds. Also, interesting to note that the x86 backend lowers this same testcase successfully. I did a quick search of bugs.llvm.org and found no matches. This implies that the problem is in my backend and/or how my backend interacts with

On Tuesday 17 July 2007 14:21, David Greene wrote: > > I don't care for a MachineFunctionPass that can be directly called. I > > think it's a very good idea to keep the coalescers independent from > > the allocators. If that's desired, we should enhance passmanager so > > each allocator can run some sub-passes as part of the allocation > > pass. > >

On Oct 20, 2012, at 1:23 PM, Vincent Lejeune <vljn at ovi.com> wrote: > 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. >

Here it is :  Starting program: /home/vlj/llvmbin/bin/llc -march=r600 -mcpu=cayman /home/vlj/shader [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". llc: /home/vlj/llvm/include/llvm/ADT/SmallVector.h:143: const T& llvm::SmallVectorTemplateCommon<T, <template-parameter-1-2> >::operator[](unsigned int) const [with T

On Oct 20, 2012, at 3:37 PM, Vincent Lejeune <vljn at ovi.com> wrote: > #5 0x00000000010c8e83 in (anonymous namespace)::JoinVals::getAssignments (this=0x7fffffffd230) at RegisterCoalescer.cpp:1305 Does this fix it? diff --git a/lib/CodeGen/RegisterCoalescer.cpp b/lib/CodeGen/RegisterCoalescer.cpp index ba6b456..2ca67d6 100644 --- a/lib/CodeGen/RegisterCoalescer.cpp +++

Hi. Im currently investigating LLVM's implementation of PBQP as a part of a bachelors thesis im doing on register allocation for regular architectures. In particullar, im looking at the possibility for improving the spill rate of PBQP for a particular DSP architecture, by using register pairing. >From reading the source code of lib/CodeGen/RegAllocPBQP.cpp i conclude that support for

On Monday 09 July 2007 16:49, Reid Spencer wrote: > The only thing that comes to mind is that creating and running the > coalescer are separate operations so you might want to do the creation > of it in alias analysis style. Then, the allocator can a) determine if a > coalescer was created, b) obtain the coalescer that was created, if any, > and c) run it at the right time for the

Here's a proposed patch for reworking register coalescing to allow pluggable coalescers. I think I've got the interfaces where I want them and am reasonably sure I've squashed most of the bugs. I'm still doing some testing and want to get through a whole regimen before committing. As a reminder, this patch has several goals: - Allow user-specified register coalescers, similar

OvermindDL1 <overminddl1 at gmail.com> writes: [snip] > On this first compile everything compiled except for llc and lli, > which did not link due to: > unresolved external symbol "class llvm::FunctionPass * __cdecl > llvm::createPBQPRegisterAllocator(void)" That is because the lib/CodeGen project file is missing PBQP.cpp. [snip] > On Fri, Oct 10, 2008 at 2:11

On Aug 10, 2007, at 10:15 AM, David Greene wrote: > However, what happens when alias analysis information gets > invalidated? > Is Andersen's still "available" in the sense analysis groups use it? > > If not, it seems it would be tough to make sure Andersen's is always > used everywhere that AliasAnalysis is asked for because there are > passes > llvm

Hi Jakob, The PBQP allocator should have no problem representing this. Between each pair of address/modification registers that are used together in a post-modification instruction you'll need to add the following cost matrix: sp r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 m0 0 0 0 0 0 i