similar to: [LLVMdev] Question about an unusual jump instruction

On Wed, Jul 25, 2012 at 12:48 AM, Michele Scandale <michele.scandale at gmail.com> wrote: > Dear all, > > I'm working on an exploratory backend on llvm. In the instruction set I'm using > I have an instruction (called DECJNZ) that decrements a register and, if the > decremented value is not zero, jumps (with a relative jump) to a given offset. > > I've

Il 25/07/2012 10:07, Eli Friedman ha scritto: > On Wed, Jul 25, 2012 at 12:48 AM, Michele Scandale > <michele.scandale at gmail.com> wrote: >> Dear all, >> >> I'm working on an exploratory backend on llvm. In the instruction set I'm using >> I have an instruction (called DECJNZ) that decrements a register and, if the >> decremented value is not

On Sep 18, 2012, at 1:45 PM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some

Hi, I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some related commits later on, and the assertion I get on the latest trunk (r164162) differs from

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Mon, Nov 21, 2011 at 10:30 AM Subject: Re: [LLVMdev] Order of Basic Blocks To: Benjamin Kramer <benny.kra at googlemail.com> This worked, though the RPO_iterator apparently wasn't what I was looking for anyways, it seems it doesn't rreally go top->down. I have a simple example code,

Hi! During my backend development I get the error message for some tests: *** Bad machine code: Virtual register def doesn't dominate all uses. *** (C source-code, byte-code disassembly and printed machine code at the end of the email) The first USE of vreg4 in BB#1 has no previous DEF in BB#0 or #1. But why? I can't see how the LLVM byte-code is transformed to the lower machine code.

Hi Vincent, On 25/10/2012 18:14, Vincent Lejeune wrote: > When examining the debug output of regalloc, it seems that joining 32bits reg also joins 128 parent reg. > > If I look at the : > %vreg34<def> = COPY %vreg6:sel_y; R600_Reg32:%vreg34 R600_Reg128:%vreg6 > > instructions ; it gets joined to : > 928B%vreg34<def> = COPY %vreg48:sel_y; > > when vreg6 and

Hi Quentin, yes, this happens quite late. With the Option --debug-pass=Structure it's in or after "Assembly Printer". I do have a very simple DAGToDAGISel::Select() method: SDNode *MyTargetDAGToDAGISel::Select(SDNode *N) { SDLoc dl(N); // default implementation if (N -> isMachineOpcode()) { N -> setNodeId(-1); return NULL; // Already selected. } SDNode

> On Sep 21, 2016, at 2:23 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > // For all predecessors of this MBB, find the set of VarLocs that > // can be joined. > for (auto p : MBB.predecessors()) { > auto OL = OutLocs.find(p); > // Join is null in case of empty OutLocs from any of the pred. > if (OL == OutLocs.end()) >

Thank for your help. You're right, merging vreg32 and vreg48 is perfectly fine, sorry I missed that. I "brute force" debuged by adding MachineFunction dump after each join, I think I found the issue : it's when vreg32 and vreg10 are merged. vreg10 only appears in BB#3, and the join only occurs in BB#3 apparently even if vreg32 lives in the 4 machine blocks After joining, there

Hi Quentin, I added some debug output (N->dump()) in ::Select(SDNode*N) and compared it to the dot/Graphviz output (-view-legalize-types-dags; the last one with correct code). I found out, that some SDNodes are not passed to the ::Select(SDNode*N), approximately 11 nodes are missing. The first add-node (v1+v2) is missing. Is it normal that not all nodes are passes to ::Select()? Thanks,

Hi, this question might be a bit silly: apart from the language reference(http://llvm.org/docs/LangRef.html#switch-instruction) page, are there additional rules for a regular llvm frontend to generate llvm IRs? There are a few cases that I got from clang/llvm-gcc/dragonegg when compiling *C* source code into llvm IR: 1. It seems that there is ONLY ONE ReturnInst(and NO InvokeInst) for such llvm

Vincent, File a bug report so you can get a fix for it. Ivan On 25/10/2012 23:01, Vincent Lejeune wrote: > Thank for your help. You're right, merging vreg32 and vreg48 is perfectly fine, sorry I missed that. > I "brute force" debuged by adding MachineFunction dump after each join, I think I found the issue : it's when vreg32 and vreg10 are merged. > vreg10 only

> On May 12, 2016, at 11:00 AM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Here is a specific case that make the debugging experiences degraded on my target: > This is a loop simplified CFG: > > BB#0: > %R5<def> = OR_rr %R0, %R49 // this is %R5 only def. > DBG_VALUE %R5, %noreg, !"argc", <!18>; line no:4 > Successors

> On May 11, 2016, at 1:12 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Hello, > > Regarding the problem of debug range for optimized code. > Currently a DEBUG_VALUE will be inserted after the <def>vregX > DEBUG_VALUE are only valid until the end of the current MachineBasicBlock. That's the main problem. > Why not simply iterate over all uses

Hi Quentin, Am 01.11.2014 um 00:39 schrieb Quentin Colombet <qcolombet at apple.com>: > > On Oct 31, 2014, at 11:00 AM, Boris Boesler <baembel at gmx.de> wrote: > >> Hi Quentin, >> >> I added some debug output (N->dump()) in ::Select(SDNode*N) and compared it to the dot/Graphviz output (-view-legalize-types-dags; the last one with correct code). I

> > > Conceptually, the LiveDebugValues data flow analysis should be using > three-valued logic arranged in a lattice > > ⊥ (uninitialized / don't know) > / \ > true false (is (not) available) > > where join(x, ⊥) = x, otherwise it behaves like boolean &. > > All debug variable values are initialized to the bottom element first. > After

On 10/10/13 10:43 AM, Hongxu Chen wrote: > Hi, this question might be a bit silly: apart from the language > reference(http://llvm.org/docs/LangRef.html#switch-instruction) page, are > there additional rules for a regular llvm frontend to generate llvm IRs? > > There are a few cases that I got from clang/llvm-gcc/dragonegg when > compiling *C* source code into llvm IR: > >

On Fri, Oct 11, 2013 at 12:06 AM, John Criswell <criswell at illinois.edu>wrote: > On 10/10/13 10:43 AM, Hongxu Chen wrote: > >> Hi, this question might be a bit silly: apart from the language >> reference(http://llvm.org/**docs/LangRef.html#switch-**instruction<http://llvm.org/docs/LangRef.html#switch-instruction>) >> page, are >> there additional rules

On Jun 13, 2012, at 1:15 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Andy, > > You are probably right here – look at this – before phi elimination this code looks much more sane: > > # *** IR Dump After Live Variable Analysis ***: > # Machine code for function push: SSA > Function Live Outs: %R0 > > BB#0: derived from LLVM BB %entry >