similar to: [LLVMdev] Pointer vs. integer: backend troubles

Hi Fabian, Anton, On 22/08/2012 08:25, Fabian Scheler wrote: >>> here are the definitions of these register classes: >>> >>> // Data register class >>> def DR : RegisterClass<"TriCore", [i32], 32, >>> (add D0, D1, D2, D3, D4, D5, D6, D7, >>> D8, D9, D10, D11, D12, D13, D14,

Fabian, > here are the definitions of these register classes: > > // Data register class > def DR : RegisterClass<"TriCore", [i32], 32, > (add D0, D1, D2, D3, D4, D5, D6, D7, > D8, D9, D10, D11, D12, D13, D14, D15)>; > > // Extended-size data register class > def ER :

2012/8/21 Anton Korobeynikov <anton at korobeynikov.info>: >> This isn't really my area of expertise, but I think you're messing up >> your RegisterClass definition. Look at how ARM defines DTriple. > DTriple is untyped :) , because we do not have any valut type which > defines 3xi64. > However, the paired register needs to have type. > > Fabian, what are

>> here are the definitions of these register classes: >> >> // Data register class >> def DR : RegisterClass<"TriCore", [i32], 32, >> (add D0, D1, D2, D3, D4, D5, D6, D7, >> D8, D9, D10, D11, D12, D13, D14, D15)>; >> >> // Extended-size data register class >> def ER :

2012/8/20 Eli Friedman <eli.friedman at gmail.com>: > On Mon, Aug 20, 2012 at 12:01 AM, Fabian Scheler > <fabian.scheler at gmail.com> wrote: >> Hi Eli, >> >>>>>> 2. Storing arbitrary sized integers >>>>>> >>>>>> The testcase "test/CodeGen/Generic/APIntLoadStore.ll" checks for >>>>>>

> This isn't really my area of expertise, but I think you're messing up > your RegisterClass definition. Look at how ARM defines DTriple. DTriple is untyped :) , because we do not have any valut type which defines 3xi64. However, the paired register needs to have type. Fabian, what are the definitions of ER and DR register classes? -- With best regards, Anton Korobeynikov Faculty

On Mon, Aug 20, 2012 at 12:01 AM, Fabian Scheler <fabian.scheler at gmail.com> wrote: > Hi Eli, > >>>>> 2. Storing arbitrary sized integers >>>>> >>>>> The testcase "test/CodeGen/Generic/APIntLoadStore.ll" checks for >>>>> loading/storing e.g. i33 integers from/into global variable. The >>>>> questions

Hi Eli, >>>> 2. Storing arbitrary sized integers >>>> >>>> The testcase "test/CodeGen/Generic/APIntLoadStore.ll" checks for >>>> loading/storing e.g. i33 integers from/into global variable. The >>>> questions are the same as regarding feature 1: How important is this >>>> feature? Is it save to ignore it? Is there

Hi, I am developing a backend for an architecture with two diferent sets of registers. The ABI specifies that pointer arguments use one kind of registers while integers use the other one. As LLVM translates pointers to the specified type (i32 in my case), I cannot specify the correct calling convention. I've seen that developing the TriCore backend the same issue appeared. In TriCore

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 LLVM-Folks, as mentioned in an earlier post (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/051677.html) I am currently working on a Back-End for the TriCore processor. Currently, I am struggling as LLVM could not select zext and load, for instance, so some of the testcases in test/CodeGen/Generic are not successfully compiled by my back-end. Furthermore, I am completely puzzled by the

Hi, first of all: thanks for your kind, very helpful and unbelievable fast response! >> as mentioned in an earlier post >> (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/051677.html) I >> am currently working on a Back-End for the TriCore processor. >> Currently, I am struggling as LLVM could not select zext and load, for >> instance, so some of the testcases

On 23/08/2012 11:06, Fabian Scheler wrote: > 2012/8/22 Ivan Llopard<ivanllopard at gmail.com>: >> Hi Fabian, Anton, >> >> >> On 22/08/2012 08:25, Fabian Scheler wrote: >>>>> here are the definitions of these register classes: >>>>> >>>>> // Data register class >>>>> def DR :

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Fabian Scheler > Sent: Wednesday, August 15, 2012 9:12 AM > To: LLVM Developers Mailing List > Subject: [LLVMdev] More Back-End Porting Troubles > > Hi LLVM-Folks, > > as mentioned in an earlier post >

Hi Eli, thank you for the information. >> thanks to kind help of the LLVM-community I was able to bring my >> TriCore back-end a huge step forward, however I am not done, so far. I >> still miss the following features and maybe you could again provide me >> some help: >> >> 1. Passing return values on the stack >> >> Describing the calling

On Thu, Aug 16, 2012 at 11:48 PM, Fabian Scheler <fabian.scheler at gmail.com> wrote: > Hi Eli, > > thank you for the information. > >>> thanks to kind help of the LLVM-community I was able to bring my >>> TriCore back-end a huge step forward, however I am not done, so far. I >>> still miss the following features and maybe you could again provide me

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

> -----Original Message----- > From: Fabian Scheler [mailto:fabian.scheler at gmail.com] > Sent: Thursday, August 16, 2012 4:58 AM > To: LLVM Developers Mailing List; Villmow, Micah > Cc: Stellard, Thomas; cameron.mcinally at nyu.edu > Subject: Re: [LLVMdev] More Back-End Porting Troubles > > Hi, > > first of all: thanks for your kind, very helpful and unbelievable

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,