similar to: [LLVMdev] Type Legalizer Question.

On Tue, Sep 30, 2008 at 9:48 AM, <Sanjiv.Gupta at microchip.com> wrote: > All the sub methods called inside ExpandIntegerOperand like ExpandInOp_STORE > etc have access to the expanded operands map. > > Why they aren't passed to target LowerOperation? A target may also want to > use the already expanded Lo and Hi parts. You don't really need access to the map; just

> > On Tue, Sep 30, 2008 at 9:48 AM, <Sanjiv.Gupta at microchip.com> wrote: > > All the sub methods called inside ExpandIntegerOperand like > ExpandInOp_STORE > > etc have access to the expanded operands map. > > > > Why they aren't passed to target LowerOperation? A target may also want > to > > use the already expanded Lo and Hi parts. >

> -----Original Message----- > From: Duncan Sands [mailto:baldrick at free.fr] > Sent: Friday, January 09, 2009 5:23 PM > To: Sanjiv Kumar Gupta - I00171 > Cc: llvmdev at cs.uiuc.edu > Subject: Re: PIC16 backend for llvm 2.5 > > Hi Sanjiv, > > > Well, the first email is here. > > > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon- >

Well, the first email is here. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081013/068667.html -----Original Message----- From: Duncan Sands [mailto:baldrick at free.fr] Sent: Thu 1/8/2009 8:41 PM To: Sanjiv Kumar Gupta - I00171 Cc: llvmdev at cs.uiuc.edu Subject: Re: PIC16 backend for llvm 2.5 Hi Sanjiv, > We are targetting a reasonably functional PIC16 backend for llvm

Hi Sanjiv, > Well the magnitude of the task is not small. > ExpandIntegerOperand() calls LowerOperation() to allow targets to handle > illegal operands. So we will need to change the interface of > LowerOperation() to pass an extra argument called Results, which is an > array of SDValue. Targets will push the result values in this array and > then we can replace values in

Hi Sanjiv, > Well, the first email is here. > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081013/068667.html thanks, I remember now (more or less). So would something like ReplaceNodeResults solve the problem? Ciao, Duncan.

Hi All, I have some doubt in LLVM Type Legalizer. How will LOAD:i8 with an i16 operand be lowered in type legalizer? (i16 type is not legal for our target) Following assertion in function ExpandIntegerOperand (file LegalizeIntegerTypes.cpp) is not allowing us to change LOAD node. assert(Res.getValueType() == N->getValueType(0) && N->getNumValues() == 1 &&

On Wed, 2008-10-01 at 11:12 +0200, Duncan Sands wrote: > Hi, > > > I have another query related to type legalizer. > > Can a target ignore certain nodes during legalize? Probably a hook for > > target that can be called inside IgnoreNodeResults ()? > > while this could be done, I don't like the idea of doing an end-run > around the whole type legalization

On Fri, 2009-01-16 at 10:03 +0100, Duncan Sands wrote: > Hi Sanjiv, > > > Well the magnitude of the task is not small. > > ExpandIntegerOperand() calls LowerOperation() to allow targets to handle > > illegal operands. So we will need to change the interface of > > LowerOperation() to pass an extra argument called Results, which is an > > array of SDValue.

Hi Duncan, We are targetting a reasonably functional PIC16 backend for llvm 2.5. The only problem in our way is a local patch in ExpandIntegerOperand, which couldn't make its way to trunk so far. The discussion is contained in the following link: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081103/069593.html I now have time to take it up again and do whatever rework is

On Oct 1, 2008, at 3:01 AM, sanjiv gupta wrote: > On Wed, 2008-10-01 at 11:12 +0200, Duncan Sands wrote: >> Hi, >> >>> I have another query related to type legalizer. >>> Can a target ignore certain nodes during legalize? Probably a hook >>> for >>> target that can be called inside IgnoreNodeResults ()? >> >> while this could be

Hi, > I have another query related to type legalizer. > Can a target ignore certain nodes during legalize? Probably a hook for > target that can be called inside IgnoreNodeResults ()? while this could be done, I don't like the idea of doing an end-run around the whole type legalization infrastructure. So you would have to come up with a pretty convincing argument as to why this

Hi Sanjiv, > We are targetting a reasonably functional PIC16 backend for llvm 2.5. > The only problem in our way is a local patch in ExpandIntegerOperand, which couldn't make its way to trunk so far. The discussion is contained in the following link: > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081103/069593.html > > I now have time to take it up

Hi, > How will LOAD:i8 with an i16 operand be lowered in type legalizer? (i16 > type is not legal for our target) what does "LOAD:i8 with an i16 operand" mean? Are you saying that the type of a pointer is i16, and you are loading an i8 value from the pointed to location? If so, you are in trouble because many parts of the code generator assume that the type of a pointer is

On Jul 1, 2008, at 3:42 PM, Richard Osborne wrote: > Evan Cheng wrote: >> On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: >> >> >>> Evan Cheng wrote: >>> >>>> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: >>>> >>>> >>>>> I'm trying to write a backend for a target with no hardware

Evan Cheng wrote: > On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: > > >> Evan Cheng wrote: >> >>> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: >>> >>> >>>> I'm trying to write a backend for a target with no hardware floating >>>> point support. I've added a single i32 register class. I'm

My target doesn't support 64 bit arithmetic, so I'd like to supply definitions for adde/addc. The problem is I can't seem to figure out the magic. Here's an example of what I need to generate: # two i64s in r5/r6 and r7/r8 # result in r1/r2, carry in r3 # adde add r2, r6, r8 cmpltu r3, r2, r6 # compute carry # addc add r1, r5, r7 add r1, zero, r3 Is this

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

On Mon, 2008-08-18 at 08:50 -0700, Eli Friedman wrote: > On Mon, Aug 18, 2008 at 6:31 AM, <Sachin.Punyani at microchip.com> wrote: > > assert(Res.getValueType() == N->getValueType(0) && N->getNumValues() == 1 && > > "Invalid operand expansion"); > > > > LOAD node has two values but the assertion checks N->getNumValues() == 1 >

On Thu, 2008-10-02 at 08:53 -0700, Chris Lattner wrote: > On Oct 2, 2008, at 8:38 AM, Eli Friedman wrote: > > > On Thu, Oct 2, 2008 at 7:34 AM, Evan Cheng <evan.cheng at apple.com> > > wrote: > >> > >> On Oct 2, 2008, at 2:01 AM, sanjiv gupta wrote: > >> > >>> > >>>> > >>>> So you have a i16 register