similar to: [LLVMdev] Best way to get direct memory for intrinsics in tblgen?

> On Jun 15, 2015, at 7:05 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > To be more specific: > > We have some operators that we are currently implementing as intrinsics, for example things like: abs, min, max, etc..... > > for some code: > > int a; > > int food() > { > return abs(a); > } > > the corresponding operator should

Tom, My current example is a global address; however, it could be any operand in theory. The arch allows for direct mem op support for ex instructions, so it could be any type of address or any type of imm or any type of register. For example, we are using intrinsics for some instructions since LLVM does not support them. Table gen does not allow for matching to direct mem op because the

Hey Ryan, You end with a large constant immediate offset value because the register operand stores the register id in a union together with the offset that's used by the global address operand. Just add 'setOffset(0)' to your change method and that should solve your problem. 2015-06-16 9:15 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>: > So I have this for

I'm not sure I understand what your problem is, but are you calling the removeRegOperandFromUseList on the machine operand after changing it to GA? You have to call removeRegOperandFromUseList before changing the operand's type, as it expects a register operand. 2015-06-16 10:05 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>: > @Alex: Thanks. setOffset(0) eliminated any previous

For anyone interested, X86InstrSSE.td makes extensive use of multiclasses now if people are looking for examples other than the sparc backend. -Chris -- http://nondot.org/sabre/ http://llvm.org/

I have a MachineOperand that could be something other than a Reg: mem, global address, imm, etc... I want to replace a reg MachineOperand with this non-reg MachineOperand. I've tried a few different things, but it doesn't seem like there is some simple functionality to do this? "RemoveOperand" and "addOperand" does not work. There doesn't seem to be a valid

ulimit -s = 8192 set "ulimit -c unlimited" On Tue, Sep 11, 2012 at 3:03 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > John, > > Thanks for responding. No, I don't see a limit from ulimit. It's > definitely with the tblgen though, I have the same errors trying to compile > clang. > > > On Tue, Sep 11, 2012 at 2:57 PM, John Criswell

Usually it is the ones that end in ".inc". From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Ryan Taylor Sent: Tuesday, September 11, 2012 3:12 PM To: John Criswell Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Fwd: Build Error from Intrinsics.td What files are created by the TableGen so that I can clean them out and start fresh? On Tue, Sep

Here's another question. It's failing on a clean checkout, so what does llvm use from a previous install that I would need to clean when installing a new clean checkout? On Tue, Sep 11, 2012 at 3:27 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > Usually it is the ones that end in ".inc".**** > > ** ** > > *From:* llvmdev-bounces at cs.uiuc.edu

Hi Chris, Thanks for this info. This provides even better and more advanced examples of multiclass usage! But your previous explanations were so good that I implemented in my backend last week almost the same that you've done now in the X86InstrSSE.td. I even introduced isCommutable parameter to indicate this property, just as you did. So, by now integer arithmetic and general purpose

Essentially it doesn't appear that the reg class assignment is based on uses and is instead inserting an extra COPY for this. Is this accurate? If so, why? In this above example, I'm getting an extra "mov %r0, $b1" (this is an MI::COPY) even though "mov @a, %b1" (this is an MI::MOV) is entirely acceptable since both GPRRegs and BaseRegs are in the reg class list.. If

1. MOV16Copy_IMM_REG is the instruction matched, sorry. AD is the multiclass. The IMM in my case is a global. So you can see that GPRBaseRegs, GPRBaseRegs sets the registerclass for both the src and dst operands, in this case (MOV16Copy_IMM_REG) it's the dst. 2. Yes I agree, it most likely would. Honestly, this comes across like a bug, or unintended feature. It's adding an extra COPY to

On 9/11/12 4:53 PM, Ryan Taylor wrote: > Tried a fresh checkout with the same issue. I'm assuming this issue > must be on my end. Dumb question: do you have a restrictive ulimit setting that might cause the tblgen program to run out of memory? I tend to doubt that this is the case, but it'd be good to double check. -- John T. > > ---------- Forwarded message ----------

Here is the instruction in question: multiclass AD<string asmstr, SDPatternOperator OpNode, RegisterClass srcAReg, RegisterClass dstReg, ValueType srcAType, ValueType dstType, Operand ImmOd, ImmLeaf imm_type> { def REG_REG : SetADInOut<asmstr, srcAReg, dstReg, [(set dstReg:$dstD, (OpNode srcAReg:$srcA))]>; def IMM_REG :

gmake[1]: Entering directory `/home/ryan/llvm/llvm_core/trunk/lib/VMCore' llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc 0 llvm-tblgen 0x000000000058525f 1 llvm-tblgen 0x0000000000585719 2 libpthread.so.0 0x00002b05a7801c60 3 libc.so.6 0x00002b05a83ead05 gsignal + 53 4

Yes, you're probably right about the ID. The odd part is that I have other simpler instructions that use the same type of superset and it always, so far, matches correctly (it doesn't just pick GPRRegs all the time). Like I said, we can just 'fill in the gaps' with new MIs but that sure seems like a brush off solution. The td files would be so much cleaner if you could have a

I have not tried 3.5, it's a significant amount of work to port from one version to the next though, I did not personally do the 3.4 to 3.6 porting. I agree though, it was very strange that it suddenly just changed behavior. It looks like to me that InstrEmitter.cpp:getVR is the one assigning the virtual register no? Though this code in CreateVirtualRegisters: const TargetRegisterClass *RC

It seems the problem arises from using multiple reg classes for one MI in the td file, I guess. I'm not sure it takes first available, if I swap the reg classes in the list it does not change and if I replace the GPR reg class with something different than it picks the base reg class fine, potentially it is using the reg class with most available? idk. I just need to create MIs for every

AddRegisterOperand calls getVR and yes, I think an IMPLICIT_DEF is being generated. On Tue, Aug 25, 2015 at 2:40 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > On Aug 25, 2015, at 11:05 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I have not tried 3.5, it's a significant amount of work to port from one > version to the next though, I did not

Tried a fresh checkout with the same issue. I'm assuming this issue must be on my end. ---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Tue, Sep 11, 2012 at 1:28 PM Subject: Build Error from Intrinsics.td To: llvmdev at cs.uiuc.edu gmake[1]: Entering directory `/home/ryan/llvm/llvm_core/trunk/lib/VMCore' llvm[1]: Building Intrinsics.gen.tmp