similar to: [LLVMdev] [ptx] Propose a register class naming convention change

Displaying 20 results from an estimated 300 matches similar to: "[LLVMdev] [ptx] Propose a register class naming convention change"

2011 May 13
0
[LLVMdev] [ptx] Propose a register class naming convention change
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
2011 May 13
2
[LLVMdev] [ptx] Propose a register class naming convention change
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 May 13
1
[LLVMdev] [ptx] Propose a register class naming convention change
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
2011 May 13
0
[LLVMdev] [ptx] Propose a register class naming convention change
<!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"
2011 Aug 24
1
[LLVMdev] proposal: add macro expansion of for-loop to TableGen
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
2011 Oct 07
0
[LLVMdev] Enhancing TableGen
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
2011 Oct 07
6
[LLVMdev] Enhancing TableGen
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">,
2011 Oct 07
0
[LLVMdev] Enhancing TableGen
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
2011 Oct 07
6
[LLVMdev] Enhancing TableGen
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
2011 Oct 06
0
[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
2011 Oct 06
3
[LLVMdev] TableGen and Greenspun
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
2011 Oct 06
4
[LLVMdev] TableGen and Greenspun
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)], >
2011 Sep 29
1
[LLVMdev] Floating-Point Constants in TableGen?
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,
2011 Oct 08
3
[LLVMdev] Enhancing TableGen
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
2011 Oct 06
0
[LLVMdev] Enhacing TabelGen
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
2011 Oct 06
0
[LLVMdev] MIPS 32bit code generation
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,
2011 Jul 14
1
[Propose] Chroot vsftpd with non-system users
The proposed subject of Wiki contribution: Chroot vsftpd with non-system users The proposed location of Wiki contribution: http://wiki.centos.org/HowTos/Chroot_Vsftpd_with_non-system_users I propose this Wiki to give user choice that they can select whether virtual users and system account coexist in vsftpd system. The shell file vsftpd_virtual_config.sh should also adjust to make this function
2017 Sep 25
1
How to propose changes to R documentation
Hi all, I noticed that there was some confusion regarding a few statements in the R documentation. There are multiple questions on Stackoverflow regarding this. So I thought it may be helpful for other new users to add a small example to clarify the statements. I am wondering how I can suggest these changes to the R manual? Is there a github like interface to R/R manual? -- Thanks Dr.
2009 Aug 18
1
How to propose patch?
Hi all, I'm a totally noob on that point but on my test machine, I've made some changes: * Changes to make the ovirt node able to load igb * Changes to make the possibility to destroy an host (if it's disabled) * Changes to make work again (at least on the GUI part) the migration I think I'll should send "somewhere" those patches but : * How do I make the patches (with
2004 Jul 06
0
[LLVMdev] Propose change gnuplot options for small picture versions
> Change the "rotate by 90" xtics specification to just "rotate" which is > equivalent. The "by <angle>" syntax is not acceptable for all output > devices. Apparently the Sparc and x86 output devices (no color) don't > accept this, but should accept the plain "rotate". Sorry, i must be more careful if i proposed patches. Vladimir