similar to: [LLVMdev] TableGen and Greenspun

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

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

On Oct 6, 2011, at 7:59 AM, David A. Greene wrote: > For example, I want to be able to do this: > > defm MOVH : > vs1x_fps_binary_vv_node_rmonly< > 0x16, "movh", undef, 0, > // rr > [(undef)], > // rm > [(set DSTREGCLASS:$dst, > (DSTTYPE (movlhps SRCREGCLASS:$src1, >

Jakob Stoklund Olesen <jolesen at apple.com> writes: > On Oct 6, 2011, at 7:59 AM, David A. Greene wrote: > >> For example, I want to be able to do this: >> >> defm MOVH : >> vs1x_fps_binary_vv_node_rmonly< >> 0x16, "movh", undef, 0, >> // rr >> [(undef)], >> // rm >> [(set

Hi folks, TableGen provides sufficiently rich syntax for expressing target instruction set. Nevertheless, when I wrote the PTX backend, I observed that some redundancy in TableGen can be further eliminated through macro expansion of for-loops. The semantics of a for-loop is expanding the for-loop body, and so it is equivalent to manually unroll the loop (see example #1). I believe the for-loop

On Oct 6, 2011, at 12:42 PM, David A. Greene wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >> On Oct 6, 2011, at 7:59 AM, David A. Greene wrote: >> >>> For example, I want to be able to do this: >>> >>> defm MOVH : >>> vs1x_fps_binary_vv_node_rmonly< >>> 0x16, "movh", undef, 0, >>>

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,

On Thursday 11 June 2009 12:28, Chris Lattner wrote: > On Jun 9, 2009, at 12:39 PM, David Greene wrote: > > On Tuesday 09 June 2009 14:34, Dan Gohman wrote: > >> Can you describe what problem you're trying to solve here? Does it > >> really need Regular Expressions? > > > > Yes. I want TableGen to be able to infer lots of stuff > >

On Jun 11, 2009, at 2:01 PM, David Greene wrote: > On Thursday 11 June 2009 12:28, Chris Lattner wrote: >>> >>> Yes. I want TableGen to be able to infer lots of stuff >>> programmatically. >>> This helps tremendously when specifying things like, oh, AVX. :) >> >> I don't see how this relates to regex's, and really don't want to

I've got the following problem in the X86 selector generated by TableGen: llvm/lib/Target/X86/X86GenDAGISel.inc:91821: error: duplicate case value llvm/lib/Target/X86/X86GenDAGISel.inc:91442: error: previously used here This seems to happen because of a pattern I added for VEXTRACTF128 which uses extract_subreg: [(set DSTREGCLASS:$dst, (DSTTYPE (extract_subreg

My purpose is to eliminate copy-paste style of programming in td files as much as possible, but only to a point that the new language constructs do not create too much overhead/readability-downgrade. In other words, I am targeting those low-hanging fruit of copy-paste programmings in td files that are eliminated by a simple for-loop syntax. The repetitive patterns I observed in PTX backend (and

Chris Lattner wrote: > However, I don't see any reason to base this off of strings. Instead > of passing down "f32" as a string, why not do something like this > pseudo code: > > class X86ValueType { > RegisterClass RegClass; > ... > } > > def X86_f32 : X86ValueType { > let RegClass = FR32; > ... }; > def X86_i32 :

On Thursday 03 December 2009 13:39, David Greene wrote: > I've got the following problem in the X86 selector generated by > TableGen: > > llvm/lib/Target/X86/X86GenDAGISel.inc:91821: error: duplicate case value > llvm/lib/Target/X86/X86GenDAGISel.inc:91442: error: previously used here > > This seems to happen because of a pattern I added for VEXTRACTF128 which > uses

Mon Ping, Thanks for the tip, but I can't for the life of me seem to get the Value from a StoreSDNode. From looking at the SelectionDAGNodes header file, the only class that has the getValue function call is SrcValueSDNode that returns a Value type. The only class that has getType is a ConstantPoolSDNode. I don't think that ConstantPoolSDNode is what I want and when I try to cast the

Hello all, I know that one of the original design goals of libhivex was to be resilient to corrupt, invalid, or malicious registry hives. I've encountered some undefined behavior in libhivex when attempting to open registry files that are too small. I'm not sure if this is a known issue per-se or not, so I figured I'd ask here on the mailing list before I jumped in and started adding

I'm trying to see how the x86 backend deals with the relationship between AL, AH and AX, but I can't get it to generate any code that would expose an interesting scenario. For example, I wrote this piece: typedef struct { char x, y; } struct_t; struct_t z; struct_t foo(char *p) { struct_t s; s.x = *p++; s.y = *p; z = s; s.x++; return s; } But the output at -O2

The address qualifier is stored in the type of %result. From that operand, you can get the Value and then call getType. The type for result should be a PointerType which you cast to a PointerType and get the getAddressSpace e.g. cast<PointerType>(Ty)->getAddressSpace() -- Mon Ping On Sep 17, 2008, at 1:06 PM, Villmow, Micah wrote: > How do I access the address qualifier

Where does the unsignedSub come from? On 2017-02-15 20:38, Ryan Taylor wrote: > Sorry, it should be: > > defm SUB16u_ : ABD_NonCommutative<"sub16u", unsignedSub, LOADRegs, > GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>; > > On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> > wrote: > >> I see. If I put simm16 and

On 12/22/2017 05:03 AM, Matthew Wilcox wrote: > OK, here's a rewrite of xbitmap. > > Compared to the version you sent: > - xb_find_set() is the rewrite I sent out yesterday. > - xb_find_clear() is a new implementation. I use the IDR_FREE tag to find > clear bits. This led to me finding a bug in radix_tree_for_each_tagged(). > - xb_zero() is also a new

On 12/22/2017 05:03 AM, Matthew Wilcox wrote: > OK, here's a rewrite of xbitmap. > > Compared to the version you sent: > - xb_find_set() is the rewrite I sent out yesterday. > - xb_find_clear() is a new implementation. I use the IDR_FREE tag to find > clear bits. This led to me finding a bug in radix_tree_for_each_tagged(). > - xb_zero() is also a new