similar to: [LLVMdev] Passing return values on the stack & storing arbitrary sized integers

Displaying 20 results from an estimated 8000 matches similar to: "[LLVMdev] Passing return values on the stack & storing arbitrary sized integers"

2012 Aug 17
2
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
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
2012 Aug 16
0
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
On Thu, Aug 16, 2012 at 5:18 AM, Fabian Scheler <fabian.scheler at gmail.com> wrote: > Hi everybody, > > 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
2012 Aug 17
0
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
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
2012 Aug 20
2
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
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
2012 Aug 20
0
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
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
2012 Aug 21
2
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
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 >>>>>>
2012 Aug 22
2
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
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,
2012 Aug 21
0
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
On Tue, Aug 21, 2012 at 1:25 AM, Fabian Scheler <fabian.scheler at gmail.com> wrote: > 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 >>>>>>>
2012 Aug 22
0
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
>> 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 Aug 21
2
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
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 Aug 23
0
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
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 :
2012 Aug 21
0
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
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
2012 Aug 23
0
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
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 : RegisterClass<"TriCore", [i32], 32, >>>>
2012 Aug 21
2
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
> 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
2012 Aug 15
5
[LLVMdev] More Back-End Porting Troubles
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
2012 Aug 16
2
[LLVMdev] More Back-End Porting Troubles
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
2012 Jun 13
2
[LLVMdev] Instructions working on 64bit registers without true support for 64bit operations
Hi LLVM-Folks, at our department we have an in-house developed back-end for the TriCore processor and we want to upgrade it to LLVM 3.1. However, we have some troubles regarding some instructions that work on 64bit registers: The TriCore processor has 16 32bit registers that can be paired to form 64bit registers. Except a few instructions all work on 32bit registers, thus the TriCore processor
2012 Aug 15
0
[LLVMdev] More Back-End Porting Troubles
> -----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 >
2012 Aug 16
0
[LLVMdev] More Back-End Porting Troubles
> -----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
2009 May 06
3
[LLVMdev] Pointer vs. integer: backend troubles
Hi everyone, I am currently working on a backend for the TriCore architecture. Unfortunately, I have hit an issue with LLVM's internal representation that's giving me a bit of a headache. The problem is that LLVM assumes that a pointer is equivalent to a machine-word sized integer. This implies that all pointer arithmetic takes place in the CPU's general-purpose registers and is done