similar to: [LLVMdev] TableGen list merging

On Apr 12, 2013, at 2:06 AM, Hal Finkel <hfinkel at anl.gov> wrote: > In the PPC backend, there is a "helper" class used to define instructions that implicitly define a condition register: > > class isDOT { > list<Register> Defs = [CR0]; > bit RC = 1; > } > > and this gets used on instructions such as: > > def ADDICo : DForm_2<13,

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, April 12, 2013 11:36:49 AM > Subject: Re: [LLVMdev] TableGen list merging > > > On Apr 12, 2013, at 2:06 AM, Hal Finkel

I'm starting to look into binary instruction encodings in TableGen, and I'm a bit confused on how the instruction fields are populated. Perhaps I'm just being dense, but I cannot see how SDAG operands are translated into the encoding fields. Can someone please explain the following snippet from the PPC back-end. The AND instruction in PPC is defined as: 1011 def AND :

Cool, that worked. New patch attached... Cheers, Gary Evan Cheng wrote: > Just cast both values to const TargetRegisterClass*. > > Evan > > On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > > Evan Cheng wrote: > > > How about? > > > > > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > > > &PPC:G8RCRegClass; >

On Tue, Jul 24, 2012 at 3:59 PM, Tom Stellard <thomas.stellard at amd.com>wrote: > On Tue, Jul 24, 2012 at 03:25:14PM -0400, Justin Holewinski wrote: > > I'm starting to look into binary instruction encodings in TableGen, and > I'm > > a bit confused on how the instruction fields are populated. Perhaps I'm > > just being dense, but I cannot see how SDAG

On Tue, Jul 24, 2012 at 03:25:14PM -0400, Justin Holewinski wrote: > I'm starting to look into binary instruction encodings in TableGen, and I'm > a bit confused on how the instruction fields are populated. Perhaps I'm > just being dense, but I cannot see how SDAG operands are translated into > the encoding fields. Can someone please explain the following snippet from

On Tue, Jul 24, 2012 at 8:46 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Jul 24, 2012, at 3:52 PM, Justin Holewinski < > justin.holewinski at gmail.com> wrote: > > On Tue, Jul 24, 2012 at 3:59 PM, Tom Stellard <thomas.stellard at amd.com>wrote: > >> On Tue, Jul 24, 2012 at 03:25:14PM -0400, Justin Holewinski wrote: >> > I'm

On Jul 24, 2012, at 3:52 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Tue, Jul 24, 2012 at 3:59 PM, Tom Stellard <thomas.stellard at amd.com> wrote: > On Tue, Jul 24, 2012 at 03:25:14PM -0400, Justin Holewinski wrote: > > I'm starting to look into binary instruction encodings in TableGen, and I'm > > a bit confused on how the instruction

PPCTargetLowering::EmitInstrWithCustomInserter has a reference to the current MachineFunction for other purposes. Can you use MachineFunction::getRegInfo instead? Dan On Jul 8, 2008, at 1:56 PM, Gary Benson wrote: > Would it be acceptable to change MachineInstr::getRegInfo from private > to public so I can use it from > PPCTargetLowering::EmitInstrWithCustomInserter? > >

On Wed, 25 Jul 2012 07:51:28 -0400 Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Tue, Jul 24, 2012 at 8:46 PM, Jim Grosbach <grosbach at apple.com> > wrote: > > > > > On Jul 24, 2012, at 3:52 PM, Justin Holewinski < > > justin.holewinski at gmail.com> wrote: > > > > On Tue, Jul 24, 2012 at 3:59 PM, Tom Stellard > >

Hi Gary, This does not patch cleanly for me (PPCISelLowering.cpp). Can you prepare a updated patch? Thanks, Evan On Jul 10, 2008, at 11:45 AM, Gary Benson wrote: > Cool, that worked. New patch attached... > > Cheers, > Gary > > Evan Cheng wrote: >> Just cast both values to const TargetRegisterClass*. >> >> Evan >> >> On Jul 10, 2008, at 7:36

Just cast both values to const TargetRegisterClass*. Evan On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > Evan Cheng wrote: >> How about? >> >> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : >> &PPC:G8RCRegClass; >> unsigned TmpReg = RegInfo.createVirtualRegister(RC); > > I tried something like that yesterday: > > const

You need to insert new basic blocks and update CFG to accomplish this. There is a hackish way to do this right now. Add a pseudo instruction to represent this operation and mark it usesCustomDAGSchedInserter. This means the intrinsic is mapped to a single (pseudo) node. But it is then expanded into instructions that can span multiple basic blocks. See

Evan Cheng wrote: > How about? > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > &PPC:G8RCRegClass; > unsigned TmpReg = RegInfo.createVirtualRegister(RC); I tried something like that yesterday: const TargetRegisterClass *RC = is64bit ? &PPC::GPRCRegClass : &PPC::G8RCRegClass; but I kept getting this error no matter how I arranged it:

Chris Lattner wrote: > On Jun 27, 2008, at 8:27 AM, Gary Benson wrote: > > def CMP_UNRESw : Pseudo<(outs), (ins GPRC:$rA, GPRC:$rB, i32imm: > > $label), > > "cmpw $rA, $rB\n\tbne- La${label}_exit", > > [(PPCcmp_unres GPRC:$rA, GPRC:$rB, imm: > > $label)]>; > > } > > > > ...and

Would it be acceptable to change MachineInstr::getRegInfo from private to public so I can use it from PPCTargetLowering::EmitInstrWithCustomInserter? Cheers, Gary Evan Cheng wrote: > Look for createVirtualRegister. These are examples in > PPCISelLowering.cpp. > > Evan > On Jul 8, 2008, at 8:24 AM, Gary Benson wrote: > > > Hi Evan, > > > > Evan Cheng wrote:

Hi Evan, Evan Cheng wrote: > This does not patch cleanly for me (PPCISelLowering.cpp). Can you > prepare a updated patch? This should work, though I won't have access to my test box now until next Thursday so no guarantees :) Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- Index: lib/Target/PowerPC/PPCISelLowering.h

Ah, didn't see that, that's what comes of trying to do something at 5pm :) I attached an updated patch which creates a virtual register instead of using R0. How does this look? Cheers, Gary Dan Gohman wrote: > PPCTargetLowering::EmitInstrWithCustomInserter has a reference > to the current MachineFunction for other purposes. Can you use > MachineFunction::getRegInfo instead?

Evan Cheng wrote: > You need to insert new basic blocks and update CFG to accomplish this. > There is a hackish way to do this right now. Add a pseudo instruction > to represent this operation and mark it usesCustomDAGSchedInserter. > This means the intrinsic is mapped to a single (pseudo) node. But it > is then expanded into instructions that can span multiple basic >

I am working on an experimental target and trying to make sure that the load offset field is used to the best way. There appears to be some control over the architecture's offset range and whether the offset is too large and needs to be lowered/converted into a separate sequence of operations in DAGSelection? Can someone point me to what might be the case? For example, the difference between