similar to: [LLVMdev] proposal: add macro expansion of for-loop to TableGen

greened at obbligato.org (David A. Greene) writes: > The problem I solved via multidefs was this: how does one write a set of > Pat<> patterns in a generic way? > > For example, I want to be able to do this: > > defm MOVH : > vs1x_fps_binary_vv_node_rmonly< > 0x16, "movh", undef, 0, > // rr > [(undef)], >

Jakob Stoklund Olesen <jolesen at apple.com> writes: > The TableGen language seems to be growing Lisp macros from two > different directions. > > Che-Liang Chiou added a preprocessor with for loops, and David Greene > added multidefs. > > It seems that some kind of macro facility is needed, perhaps we should > discuss what it is supposed to look like? Don't

The TableGen language seems to be growing Lisp macros from two different directions. Che-Liang Chiou added a preprocessor with for loops, and David Greene added multidefs. It seems that some kind of macro facility is needed, perhaps we should discuss what it is supposed to look like? /jakob

Jakob Stoklund Olesen <jolesen at apple.com> writes: > I think the for loops have merit, but not the way you want to use them. > > Some target descriptions have many sequential definitions, for example PowerPC/PPCRegisterInfo.td: > > // Vector registers > def V0 : VR< 0, "v0">, DwarfRegNum<[77, 77]>; > def V1 : VR< 1, "v1">,

On Oct 7, 2011, at 11:23 AM, David A. Greene wrote: > Evan Cheng <evan.cheng at apple.com> writes: > >> Your proposed new TableGen functionalities are interesting but it is >> clearly not where the code owners want it to go. > > Jakob at least seems interested in the for loop stuff. Am I reading you > correctly, Jakob? Having that feature would make a huge

On Oct 7, 2011, at 2:23 PM, David A. Greene wrote: >> As repeated many times on this thread, the most common operation that >> a .td file must support is looking up an instruction and figuring out >> what its properties are and where they came from. > > Ok. What properties are most important to look up? I have found it > really easy to just run "tblgen

greened at obbligato.org (David A. Greene) writes: > Also, I know I introduced the #..# "pasting" operation but I've found it > to be too limiting. In this example: [snip!] > what if we instead did this: > > (Equivalent TableGen code with a for-loop) > ---------------------------------------- > multiclass PTX_FLOAT_4OP<string opcstr, SDNode opnode1, SDNode

A simulator should be expecting the machine opcodes not macros. LD shouldn't care at all as long as the object format plays well. I would think it would be better to fix the simulator. Jack ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of llvmdev-request at cs.uiuc.edu [llvmdev-request at cs.uiuc.edu] Sent: Thursday,

Evan Cheng <evan.cheng at apple.com> writes: > David, we cannot accept the 'multidef' keyword. Please revert it. Working on it now. > We appreciate you thinking ahead about MIC, but we are against the > massive refactoring and complicated abstraction scheme. We'll never > accept those patches. How about a less massive and complicated scheme? I think we can make

Hi Jakob and David, The for-loop inside multiclass definition does not have to add extra abstraction layer. As in the pseudo codes that David wrote earlier (see below), it only condenses the repetitive 'def' statements inside the multiclass definition into a more compact and less copy-paste style form, instead of encapsulating them somewhere outside the multiclass definition. I believe

Hi, Current register class naming has a confusing prefix letter 'R' (it is my bad), such as the first 'R' of RRegu32 (for unsigned 32-bit registers). I propose a 'Reg' + type name naming convention for register classes; such as: Regu16, Regu32, Regf32, Regf64 With one exception for predicate registers (capitalized first letter of 'pred'): RegPred Since

That's fine with me. Unless there's a particular reason for it I would suggest perhaps changing the immediate syntax as well to swap it round, so it would be Immi32, Immi64, Immf32, etc. It doesn't bother me that much the way it currently is, but when there are lots of operations taking a register and an immediate, representing them in the same way might be a little more

On Fri, May 13, 2011 at 5:11 AM, Dan Bailey <drb at dneg.com> wrote: > That's fine with me. Unless there's a particular reason for it I would > suggest perhaps changing the immediate syntax as well to swap it round, so > it would be Immi32, Immi64, Immf32, etc. It doesn't bother me that much the > way it currently is, but when there are lots of operations taking a

2011/5/13 Dan Bailey <drb at dneg.com> > Justin Holewinski wrote: > > On Fri, May 13, 2011 at 5:11 AM, Dan Bailey <drb at dneg.com> wrote: > >> That's fine with me. Unless there's a particular reason for it I would >> suggest perhaps changing the immediate syntax as well to swap it round, so >> it would be Immi32, Immi64, Immf32, etc. It

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Justin Holewinski wrote: <blockquote cite="mid:BANLkTi=Y9EFmWRu-9dQxydq8zTyF7tEbJw@mail.gmail.com"

Is it possible to represent floating-point constants in TableGen definitions? Let's say I have the following pattern: def : Pat<(i1 (trunc RegI16:$a)), (SETPGTu16ri RegI16:$a, 0)>; Note the zero constant in the result. Is there a way to represent floating-point literals in the same way? Something like... def : Pat<(i1 (uint_to_fp RegF32:$a)), (SETPGTf32ri RegF32:$a,

On 6 Dec 2012, at 07:46, 陳韋任 (Wei-Ren Chen) wrote: > The code below in lib/Target/ARM/ARMRegisterInfo.td is where you > should look into, > > // Integer registers > def R0 : ARMReg< 0, "r0">, DwarfRegNum<[0]>; > def R1 : ARMReg< 1, "r1">, DwarfRegNum<[1]>; > > ... That's the easy part. ARM (AArch32) has 16 registers

On Wed, Dec 05, 2012 at 09:17:12PM -0600, Amir Yazdanbakhsh wrote: > Hi, > > I want to increase the number of integer registers in the ARM machine. > I don't have any idea how/where I can start. Can anybody help me? The code below in lib/Target/ARM/ARMRegisterInfo.td is where you should look into, // Integer registers def R0 : ARMReg< 0, "r0">,

On Thu, Dec 06, 2012 at 09:13:53AM +0000, David Chisnall wrote: > On 6 Dec 2012, at 07:46, 陳韋任 (Wei-Ren Chen) wrote: > > > The code below in lib/Target/ARM/ARMRegisterInfo.td is where you > > should look into, > > > > // Integer registers > > def R0 : ARMReg< 0, "r0">, DwarfRegNum<[0]>; > > def R1 : ARMReg< 1,

The field Num seems to have no meaning. It is not recognized by the backend tools. It does not hurt anything but should not be there. // We have banks of 32 registers each. class MipsReg<string n> : Register<n> { field bits<5> Num; let Namespace = "Mips"; } class ARMReg<bits<4> num, string n, list<Register> subregs = []> : Register<n> {