similar to: [LLVMdev] Instructions working on 64bit registers without true support for 64bit operations

Fabian, 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. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Fabian Scheler > Sent: Wednesday,

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

On Thu, Jul 12, 2012 at 01:22:39PM +0200, Fabian Scheler wrote: > 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

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

Hello Tom, > I took a look at lib/CodeGen/SelectionDAG/LegalizeDAG.cpp and it > doesn't look like there is an Expand operation implemented for > ISD::Constant. I think you'll either need implement Expand for > ISD::Constant or Custom lower it in your backend. thank you for that information. This exactly is what I feared. Well I did some more mostly unguided hacking and these

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,

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

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

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 :

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

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 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 Raghu, > I am working with the "LowerCall" function, and trying to figure out the types of all the "Outs" arguments. Specifically, I want to find out if a particular "Out[i]" argument is a pointer (of any type), or a regular data type. So far, all pointers show up as the "MVT::i32" datatype, which is not helping my cause. Is there a way to distinguish

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

Hi all, I am working with the "LowerCall" function, and trying to figure out the types of all the "Outs" arguments. Specifically, I want to find out if a particular "Out[i]" argument is a pointer (of any type), or a regular data type. So far, all pointers show up as the "MVT::i32" datatype, which is not helping my cause. Is there a way to distinguish

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

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 :

It seems that Tablegen is generating intrinsic ID's off by in DAGISel.inc In DAGISel.inc, I have the following pattern: int64_t CN1 = Tmp0->getZExtValue(); // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Emits: (MACRO_FMA_f32:f32 GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Pattern complexity = 8 cost