similar to: [LLVMdev] A problem on returning value for functions

Hi, > The headache is when I pass option -O0 to llc, the generated codes are > correct. However, if I omit -O0 and use default compiling options, the > instruction "movi r0, #1234" does not show. It's probably being eliminated as dead code. You want to make sure that during ISelLowering your RET instruction has %R0 as one of its operands (check in the -view-isel-dags

Sergei, Thank you for your attention. My target is a custom VLIW DSP. I am not sure dependency dag is correct when it gets scheduled and packetized. Months ago, I submitted a bug at http://llvm.org/bugs/show_bug.cgi?id=17894 which explained more details. I am not sure my understanding of this bug is proper, but modified my local codes this way and it works for my target when scheduling and

David, thanks for your immediate response. Since iPTR is a reserved type for tablegen internal use, can you make a further explanation? On the other hand, it can be simply treated as a register class assignment problem during register allocation. Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs register allocation, it can retrieve from

Hi, In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers. This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types. We've added a flag that can be set on a per-backend basis to turn this off. Our problem is perhaps a bit different form yours,

llvm code generator lowers both integer and pointer types into ixx(say, i16, i32, i64, ...). This make senses for some optimizations. However, integer registers and pointer registers is expilicitly distinguished from each other for some architectures, like TriCore, Blackfin, and our lab prototype dsp, which accelerates address computation and memory access. I have already read this mail thread:

We also have this problem, and have added iPTR types to the back end. Our pointers are actually fat pointers, so this also requires tweaking some optimisations (for example, things like to turn GEPs with 64-bit offsets into pointer-sized offsets, but our pointers are larger than any integer type that we support...). Most of the changes are a bit ugly, and I'm loath to upstream them without

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

On Sun, Jun 23, 2013 at 04:57:44PM +0100, David Chisnall wrote: > Hi, > > In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers. This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types. We've added a flag that can be set on a per-backend

Hi, LLVMer. I use pseudo-instructions ADJCALLSTACK(DOWN | UP) to adjust call stacks, and it works well with "-O0" option. However, ADJCALLSTACK(DOWN | UP) are removed during codegen DCE pass under "-O2". What have I ignored? Thanks. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML attachment was scrubbed... URL:

Sorry, this is the attachment. 2014-02-19 15:08 GMT+08:00 杨勇勇 <triple.yang at gmail.com>: > Thank you. > > Here is an example and the attchment contains extra files including object > file and executable file. > I want to print for example the value of "a", but lldb command "frame > variable a" displays "0" and so does "b", and

All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for. Greg Clayton On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote: > Hi, all > > I

Hi, guys, I compiled a subroutine with -O2, and llvm backend produced codes like: ################################################################## LBB0_32: ... R31 = -1 R20 = R31 * R20; .... bnz R2, LBB0_34 LBB0_31: ... b LBB0_34 LBB0_33: # weird basic block? R20 = R5 LBB0_34: ....

Hi, all I ported llvm backend and lldb recently. Both tools can basically work. lldb is able to debug programs in asm style and frame unwinding is OK. But "frame variable XX" does not work because lldb is not able to determine the address of XX from debug info. Can someone give any clue? Thanks in advance. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML

Hi All, In the target we are implementing, function return for i64 and f64 types has a different processing. For types i8 to i32, and f32, the return values are stored in their designated return registers (like how other targets does it). For i64 and f64 types, in the function call, after pushing the function parameters into the stack, the address of the allocated return memory space is

2013/6/23 David Chisnall <David.Chisnall at cl.cam.ac.uk> > Hi, > > In our version of LLVM, we've added different-sized iPTR* types, so we > have an iPTR256 for our fat pointers. This causes some problems with > constraints, because the way that TableGen resolves constraints is not > expected to handle multiple pointer types. We've added a flag that can be >

On 2019/10/24 ??11:26, Liu, Yong wrote: > >> -----Original Message----- >> From: Jason Wang [mailto:jasowang at redhat.com] >> Sent: Tuesday, October 22, 2019 9:06 PM >> To: Liu, Yong <yong.liu at intel.com>; mst at redhat.com; Bie, Tiwei >> <tiwei.bie at intel.com> >> Cc: virtualization at lists.linux-foundation.org >> Subject: Re: [PATCH]

On 8 March 2014 00:53, Owen Anderson <resistor at mac.com> wrote: > ISDOpcodes.h contains what documentation there is on the semantics of each > opcode. And TargetOpcodes.h for a few of the post-ISel ones (mostly they're in MachineInstr form, but you'll see them with -view-sched-dags, and occasionally before). Tim.

Hi all: I'm writing testcase for the MC layer regression in llvm, the disassembled string is a bit complicate, for example: "IALU.T0 (I0) = BIU0.DM ; REPEAT AT ( 2 ) ;;" The spaces in the disassembled string is error-prone. Is there any option to tell the FileCheck utility to ignore the spaces ? Kind Regards. Shawn.

Yes, I did an offline upgrade. 1. Stop all clients using gluster servers. 2. Stop glusterfsd and glusterd on both servers. 3. Backed up /var/lib/gluster* in all servers just to be safe. 4. Upgraded all servers from 3.6.x to 3.10.x (I did not have quotas or anything that required special steps) 5. Started gluster daemons again and confirmed everything was fine prior to letting clients connect. 5.

Hi Diego, Just to clarify, so did you do an offline upgrade with an existing cluster (3.6.x => 3.10.x)? Thanks. On Fri, Aug 25, 2017 at 8:42 PM, Diego Remolina <dijuremo at gmail.com> wrote: > I was never able to go from 3.6.x to 3.7.x without downtime. Then > 3.7.x did not work well for me, so I stuck with 3.6.x until recently. > I went from 3.6.x to 3.10.x but downtime was