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