similar to: [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 >

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

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

On Wed, Aug 15, 2012 at 12:11 PM, Fabian Scheler <fabian.scheler at gmail.com> wrote: > Hi LLVM-Folks, > ... > Currently, I am not even able to find out which instruction is messed > up here (dumping the node via the dump-Method yields "<<Unknown > Machine Node #65434>>"). Can I use "machine nodes" and "normal nodes" > when

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

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,

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

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

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 Describing the calling conventions in tablegen so that first registers are used and to fall back to the stack if these do not

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 :

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

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

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

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

Hi Micah, > We have a very similar setup with the AMDIL backend(some operations support 64bit some don't). > > What we do is we enable MVT::i64, set legal to all operands that are legal and then set everything else to expand. thanks for your hint. Unfortunately, I didn't find any time to work on my problem in the meantime as I was busy preparing lectures. However, the summer

Currently I can use a BUILD_PAIR to make a pair of two arbitrary values to a desired result value. For example, I can make i8,build_pair = (i8, i8) or i16,build_pair = (i1, i8). This is turning out to very handy when I replace nodes during the expansion/legalization of types for my target. I was just wondering if we could go one more step further and create a BUILD_TRIPLET node which can

Hi, I have a custom lowering operation on ISD::BITCAST for the PowerPC/SPE target, to convert 'f64 bitcast (i64 build_pair i32, i32)' into a 'f64 BUILD_SPE64 i32, i32' node, which can be seen at https://reviews.llvm.org/D54583. However, when building compiler-rt's lib/builtins/divdc3.c an assertion is triggered that BUILD_PAIR is not legal on line 24. There should be no

Hi Nemanja, I'm attaching a patch that builds on D54583 and implements what we discussed on IRC earlier today. Particularly: * Make LowerCallTo() a virtual function, so it can be wrapped by a subclass. * Implement LowerCallTo() in PPCTargetLowering to wrap TargetLowering::LowerCallTo() and legalize the return node when targeting SPE. * Augment PPCTargetLowering::LowerCall_32SVR4() to

Hello everyone, I wanted to attach a node without affecting the present nodes in any way. I tried to use MVT::Glue for that but I think I'm missing something as I could not achieve the below state. LUI LUI | | ADDI ----GLUE---- ADDI | store I've few question about this and Glue node in general, I'll be happy to get some help on