similar to: [LLVMdev] Tablegen foreach

That is what I currently have, I'm trying to simplify them even further since my multiclass file is enormous because of the amount of combinations. I have things like this: multiclass instmcRegImm<...> { def rr: inst<...>; def ri: inst<...>; def ir: inst<...>; def ii: inst<...>; } multiclass instmc<...> { defm i8 : instmcRegImm<...>; ^-- repeat for 15

I think a multiclass may be a better fit for what you are trying to do. In fact, this is the canonical example for multiclasses: <http://llvm.org/docs/TableGenFundamentals.html#multiclass-definitions-and-instances>. --Sean Silva On Mon, Aug 6, 2012 at 1:55 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I’m trying to find examples of the foreach pattern being used in

I believe multiclasses can be nested. Could that help you reduce the duplication? --Sean Silva On Mon, Aug 6, 2012 at 2:46 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > That is what I currently have, I'm trying to simplify them even further since my multiclass file is enormous because of the amount of combinations. I have things like this: > > multiclass

I have been reading the “RFC/bikeshedding: Separation of instruction and pattern definitions in LLVM backends” topic with considerable interest. This is an approach I have been considering for taming our own large instruction set, and it looks like it structures our descriptions better than the conventional approach we have used so far. However, I have another form of TableGen taming that I

On Sun, 1 Oct 2006, Roman Levenstein wrote: > I'm trying to implement a new backend for an embedded CISC processor. > Therefore I thought that it makes sense to take X86 target as a basis, > to save some time. Ok. Note that the X86 backend is one of the most complex though, because it supports several subtargets and ABIs, which makes it more complex than some other targets. >

Hi, I'm trying to implement a new backend for an embedded CISC processor. Therefore I thought that it makes sense to take X86 target as a basis, to save some time. But when I look into the X86InstrInfo.td, I have a very strong feeling that it is one of the most complex instruction set descriptions compared to other targets. I can imagine that this is due to the complexity of X86's

All, Where are the SSE instructions defined? Specifically, I cannot find the def for ADDSDrr. Aran -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100326/130b2e02/attachment.sig>

Hi Artem, Thank you for your encouraging reply :) I have now cleaned up the first batch of changes and put them on Phabricator here: https://reviews.llvm.org/D43552 I've tried to keep individual changes small, and I've verified with `git rebase -x` that the build is good after each change. This first batch does not cause any changes in backend's generated files. [snip]>

Hi all, While working on some features for the AMDGPU backend -- specifically, explicit address components for image intrinsics, which involves generating both (a) a lot of intrinsics with different but somewhat regular parameter types, and (b) the patterns to select instructions for those intrinsics -- I got fed up with a lot of the TableGen bugs and limitations and set out to fix things.

On Mon, Feb 19, 2018 at 11:26 AM Nicolai Hähnle <nhaehnle at gmail.com> wrote: > Hi all, > > While working on some features for the AMDGPU backend -- specifically, > explicit address components for image intrinsics, which involves > generating both > > (a) a lot of intrinsics with different but somewhat regular parameter > types, and > > (b) the patterns to

Nicolai, I want to say huge thank you for your improvements to tablegen. While it's still far from perfect, I now have a hope that one day I'll be able to *just write* something in tablegen, as opposed to constantly struggling to trick tablegen into doing what I need it to do. Thank you. --Artem On Wed, Feb 21, 2018 at 2:48 AM Nicolai Hähnle <nhaehnle at gmail.com> wrote: >

On 08/23/2017 12:44 PM, David Chisnall wrote: > On 23 Aug 2017, at 18:21, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 08/23/2017 12:06 PM, Krzysztof Parzyszek via llvm-dev wrote: >>> On 8/23/2017 11:58 AM, Hal Finkel via llvm-dev wrote: >>>> If we want to go down that route, I can certainly imagine a feasible

Hi Chris, Thanks a lot for your answer! Chris Lattner wrote: >> 1. Why does X86 instruction set description provide different >> descriptions for the same instructions, which differ only in the size >> of operands? >> E.g. >> >> def MOV8rm : I<0x8A, MRMSrcMem, (ops GR8 :$dst, i8mem :$src), >> "mov{b} {$src, $dst|$dst, $src}",

So, I have this small test program that I figured would cause no problems but want to test all the various data types and operations with my modified sparc backend. I've been working on LLVM for about 3 days now, so this might be a problem with not knowing enough yet, so thanks for bearing with me. The code that I based my example off of is compiled to LLVM-IR from: void

llvm/lib/Target/X86/X86InstrInfo.td: class X86Inst<bits<8> opcod, Format f, ImmType i, dag ops, string AsmStr> : Instruction { .... dag OperandList = ops; string AsmString = AsmStr; } def MOV32mi : Ii32<0xC7, MRM0m, (ops i32mem:$dst, i32imm:$src), "mov{l} {$src, $dst|$dst, $src}">; I cannot find any document on initializing the

Dear expeRts, is it possible to carry out calculations between different foreach() calls? As for nested loops, you want to carry out calcuations not depending on the inner loop only once and not for each iteration of the innermost loop. Cheers, Marius library(foreach) foreach(i=1:3) %:% foreach(j=1:2) %do% { i <- i+1 print(paste(i,j)) } foreach(i=1:3) %:% i

On Wed, Sep 10, 2008 at 2:35 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Generating the following LLVM IR: > > define void @test_unary_op_anegate(float %x, float addrspace(11)* %result) > nounwind { > entry: > %neg = sub float -0.000000e+000, %x ; <float> [#uses=1] > store float %neg, float addrspace(11)* %result >

Hi all, Within a foreach loop with doSNOW, we cant call functions which come from the non-default package. We need to load(require/library) the package once more within the foreach loop. Anyone knows why would happen like this? Is it caused by the snow package and something happened when "snow" parallelize the job? Other than load the package once more with in the foreach loop, is

Hi does anyone know of any R functions or packages for the following :- . generating cube plots for displaying the results from a response surface experiment design . generating ternary plots from a mixture design . tetrahedral plot or quaternary plot for displaying results from a four factor mixture experiment thanks Bob Kinley [[alternative HTML version deleted]]

All, I am not understanding the scoping used in foreach when it is used inside a function. I keep getting "could not find function" errors for functions that are in memory when I try to use foreach within a function call. I have a simple example below. "testFun" is in memory and works when called by foreach directly, but when I place foreach in a function called