similar to: [LLVMdev] Tablegen question

Manjunath, I asked this question recently, but instead of telling you to search the archive I'm going to take it as a chance to recall how to do it (because I'll do so anyway and even telling tablegen to use an enum for instructions is not as trivial to do as you might think : ) I wrote it up in the wiki at http://wiki.llvm.org/HowTo:_Add_arbitrary_properties_to_instructions Regards,

Christian, Thanks for your reply and the wiki entry. I did search the archives, but evidently I didn't search for the right thing. My bad. Anyways, I am still wondering about the other part of my question. Why aren't there Tablegen backends specific to some architecture backends? Let me describe a different scenario. Suppose my architecture has vector and scalar units, and suppose I want

> All of the tablegen backends work this way. As you mentioned, > there are no target-specific tablegen backends at present. > > The underlying observation here is that features are never > fundamentally "specific for a target". For example, a mapping > between vector opcodes and associated scalar opcodes could > reasonably be made on many architectures. Even >

Hi LLVM, I ran into a case where RegAlloc would insert a spill across instruction that had same register for output operand and implicit-def. The effect this had was that spill code would immediately overwrite the output result. Is this the expected result of setting up MyInst this way? In other words, does RegAlloc know to not insert spill in case it sees that output reg is same as one of

Hi Quentin, MyInst is a custom instruction that has implicit-defs of fixed registers. The implicit-defs are seen at the end of Instruction Selection. I'd like to add a report, but I am working on an out-of-tree backend based on 7.0. I can try to help reduce the testcase down. Filed https://bugs.llvm.org/show_bug.cgi?id=41790 Regards, Kevin On 2019-05-07 3:45 p.m., Quentin Colombet wrote:

Dan, > In general, it's a design goal to structure CodeGen features as > target-independent code parameterized with target-specific data. > The degree to which this goal is met in LLVM CodeGen features today > varies, but features that have been implemented using TableGen have > been relatively successful. Can you give an example of a relatively successful instance where

How can I prevent some nodes from being combined in DAGCombine.cpp? Maybe what I want to do below doesn't follow the philosophy of LLVM, but I'd like to know if there is any way to avoid node from being combined. TargetLowering::PerformDAGCombine() is only called if DAGCombiner cannot combine a specific node. It seems that there is no chance to stop it from combining a node. I need the

On Jun 8, 2009, at 1:25 PM, Manjunath Kudlur wrote: > Dan, > > >> In general, it's a design goal to structure CodeGen features as >> >> target-independent code parameterized with target-specific data. >> >> The degree to which this goal is met in LLVM CodeGen features today >> >> varies, but features that have been implemented using TableGen

Hello, I am having some trouble matching patterns in targetinstructioninfo.td file with the CodeGen expectation. Could anybody please help? Here is the example: I want to emit instruction for adding 2 different kind of oprands. Basically i want to mix register types when I define the instruction for add,sub etc I define the instruction TargetInstruction.td as follows: class MyInst <opcode

This sounds great! I've been bitten in the past by trying to use a single class for multiple types. Would it make sense to extend this to all DAG patterns? If I have an instruction def: def ANDN64 : MyInst<(outs Reg64:$d), (ins Reg64:$a, Reg64:$b), "and.64 $d, $a, $b", [(set Reg64:$d, (and (not (Reg64:$a, Reg64:$b))))]>; would I now be able to write: def ANDN64 :

Hello, I am new to LLVM and I am not sure whether I am writing to the right distribution list or not. Please let me know if this is not the right distribution list. Question: - I am having hard time lowering ADD instructions for different purposes. Basically, I want to have different machine instruction for pointer addition vs scalar addition. I am having hard time mapping LLVM add to my machine

Hi Jacob, thank you for your reply. Your suggestion works! But instead of using the Pat<>, I am using def MOVE_ADDR : MYInst<(outs Int32Regs:$dst), (ins i32mem:$a), "move $dst, $a;", [(set Int32Regs:$dst, (Wrapper tglobaladdr:$a))]>; I don't quite understand what the semantics of Pat in general. Could you please explain what

On May 9, 2012, at 4:27 AM, Anton Korobeynikov wrote: > Hello Jonas, > >> I wonder, what would be the best solution for instructions that require >> operands in a particular register, and even gives the result in a particular >> register? > You need to custom select such instruction. See e.g. div / idiv on x86 > as an example. That's often easiest, yes;

I'm posting this message in charge of Denis MARS (France), because he is not a subscriber of teh list and I worked with him about the same problem. Domenico Viggiani ---------------------------------------------------------------- Hello, I worked on this problem since three weeks and now i really give up. Clearly i can't go further without your help. I hesitate to send you this bug

Jim, > The an instruction that uses R0 and R1 as fixed input registers and R2 for output could define itself using those register classs: > def myInst : baseclass<…, (outs GPRr2:$dst), (ins GPRr0:$src1, GPRr1:$src2), …> > Use those reg classes in pattern to match also, and things should just work. The register allocator can take care of any reg-to-reg copies that are required. As

Dan, Thanks a lot. Using a modifier in the assembly string works for this case. I am trying to solve a related problem. I am trying to print out a set of "mov" ops for the vector_shuffle node. Since the source of the "mov" is from one of the sources to vector_shuffle, depending on the mask, I am not sure what assembly string to emit. For example, if I have d <-

On Apr 18, 2007, at 2:07 PM, Evan Cheng wrote: > > On Apr 18, 2007, at 11:25 AM, Christopher Lamb wrote: > >> I noticed that the TableGen code emitter generator assumes that >> the instruction fields are declared in the instruction format in >> the same order that operands are defined. This seems like a bad >> dependence to me, and that TableGen should match

I am seeing the following assertion in leak detector. /llvm/lib/VMCore/LeakDetector.cpp:43: void<unnamed>::LeakDetectorImpl<T>::addGarbage(const T*) [with T = void]: Assertion `Ts.count(Cache) == 0 && "Object already in set!"' failed. I am creating a list of instructions using BuildMI() and adding them to a basic block using BB->insert(). I am seeing this

Hello All, I am getting this error when I try to join my Win2K m/c to Samba, Windows cannot log you on because the profile cannot be loaded. Contact your network administrator. DETAIL - The system cannot find the file specified. I dont want Roaming profile to be implemented, I just want to give users local profiles only. When the client tries to logon to the PDC it looks for a profile to

You could hardcode a register for the pseudo instruction to use in the td file. The register allocator will make sure not to clobber it. let uses = [ R1 ], defs = [ R1 ] in { def MYINST : Pseudo<> } On Wed, Dec 11, 2019 at 10:25 AM Przemyslaw Ossowski via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I have one more question regarding expanding pseudo instruction. > >