similar to: [LLVMdev] Register Class assignment for integer and pointer types

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

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,

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

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 >

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

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

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.

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

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:

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

"--strict-whitespace By default, FileCheck canonicalizes input horizontal whitespace (spaces and tabs) which causes it to ignore these differences (a space will match a tab). The/--strict-whitespace/ <http://llvm.org/docs/CommandGuide/FileCheck.html#cmdoption--strict-whitespace>argument disables this behavior. End-of-line sequences are canonicalized to UNIX-style ‘n’ in all

You should set them as using/defining your stack register with : let Defs = [STACKREG], Uses = [STACKREG] in { __ YOUR INSTRUCTION __ } Marcello On 04/09/13 07:56, 杨勇勇 wrote: > 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

Hi, I write a backend and come cross an abnormal problem. Here I give a example to describe it: /////////////////////////////////////////////////////////////////////////////////////////// // A simple C function int foo() { return 1234; } ///////////////////////////////////////////////////////////////////////////////////////// When compiling foo() into my target ISA, I would expect codes

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

Hi Yang, > bnz R2, LBB0_34 > > I do not have any clue what happens when compiling with -O2. > Can someone make a suggestion? Is the "bnz" instruction marked "isBarrier" in your TableGen files? If so, that would mean LLVM considers fallthrough impossible and decides it can move LBB0_33 around at will. It's still very odd that it thinks it can put it

Hi, developers, I notice following asm symbol definitions are eveluated improperly: A = 9 B = 3*A - 2 * A + 1 the value of B should be 10 instead of 8. It seems asm parser treat "B = 3*A - 2 * A + 1" as "B = 3*A - (2 * A + 1)" because the second "*" has higher precedence than "-", and evaluation just performs simple recursion within

http://llvm.org/docs/CommandGuide/FileCheck.html says FileCheck ignores white spaces/tabs by default unless you use "--strict-whitespace" option. 2013/3/15 Shawn <shaolin.xie at ia.ac.cn>: > 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