similar to: [LLVMdev] expanding i16 operations in presence of an i16 regclass.

Dan Gohman <gohman at apple.com> writes: > On Mar 15, 2009, at 2:02 PM, Jakob Stoklund Olesen wrote: >> Am I misusing register classes, or is this simply functionality that >> has not been written yet? The existing backends seem to have only one >> register class per machine value type. > > The x86 backend has an example of a partial solution. The GR32 >

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

On Mar 16, 2009, at 11:31 AM, Jakob Stoklund Olesen wrote: > Dan Gohman <gohman at apple.com> writes: > >> On Mar 15, 2009, at 2:02 PM, Jakob Stoklund Olesen wrote: >>> Am I misusing register classes, or is this simply functionality that >>> has not been written yet? The existing backends seem to have only >>> one >>> register class per

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

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.

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

On Mar 15, 2009, at 2:02 PM, Jakob Stoklund Olesen wrote: > Hi, > > I am writing a backend for the Blackfin processor from Analog > Devices. I > just started so I still have a lot to learn about the code > generator. So > far, I can compile test/CodeGen/Generic/BasicInstrs.ll correctly, but > that is about it. > > The Blackfin 32-bit registers divide naturally

Ok, I've found that marking tiny live intervals as not spillable inside VirtRegAuxInfo::CalculateWeightAndHint is not playing nicely with very constrained regclasses, in my case a regclass composed of only one register. As a workaround, instead of marking them as not spillable, I've marked them with a very high spill cost and the regalloc is able to compile the function with good code

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. - Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL:

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 class which makes the type legal. You can >>> make loads and stores legal (can you?). But you will have to custom >>> lower all other i16 operations. This will work, but it

> > So you have a i16 register class which makes the type legal. You can > make loads and stores legal (can you?). But you will have to custom > lower all other i16 operations. This will work, but it requires a lot > of target specific code. True. If we add the i16 reg class we will need to write a lot of target specific code. To avoid that our idea was not to tell the

Hi, I am writing a backend for the Blackfin processor from Analog Devices. I just started so I still have a lot to learn about the code generator. So far, I can compile test/CodeGen/Generic/BasicInstrs.ll correctly, but that is about it. The Blackfin 32-bit registers divide naturally into several classes. I have modelled these register classes without knowing anything about what the code

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 class which makes the type legal. You >>>> can >>>> make loads and stores legal

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 Sun, 2009-01-18 at 20:28 +0100, Duncan Sands wrote: > Hi Sanjiv, > > > + /// CustomLowerOperation - This callback is invoked for operations that are > > + /// unsupported by the target, which are registered to use 'custom' lowering, > > + /// and whose defined values are all legal. > > and whose defined values are all legal -> and whose return

On Jan 9, 2013, at 10:46 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Ok, I've found that marking tiny live intervals as not spillable inside VirtRegAuxInfo::CalculateWeightAndHint is not playing nicely with very constrained regclasses, in my case a regclass composed of only one register. > As a workaround, instead of marking them as not spillable, I've marked them

On Oct 2, 2008, at 10:11 AM, sanjiv gupta wrote: > 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: >>>>

> >>>> You can try just marking all i16 operations, other than load and > >>>> store, as "expand". Would that work? > >>> > >>> Won't work; LLVM expects at least some basic operations, like add, > >>> to > >>> be legal in legal register types. > >> > >> That sounds like a bug, not a

Hello Jakob, Did you get a chance to take a look into this, and if not, can you do it when you get some spare time? Thanks! 2012/12/19 Borja Ferrer <borja.ferav at gmail.com> > We did something like this back when the register allocator couldn't split >> live ranges. >> > > Yes, I remember the isWinToJoinCrossClass() function, removed here: > >

On Jan 7, 2013, at 4:58 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Hello Jakob, > > Did you get a chance to take a look into this, and if not, can you do it when you get some spare time? It's not likely I'll have time to look at this in the near future. I'd recommend you do it yourself. /jakob > 2012/12/19 Borja Ferrer <borja.ferav at gmail.com>