similar to: Qs about TwoOperandAliasConstraint and TIED_TO

Yes, there is an easy way to fix this. MRMSrcMem assumes register, memory, vvvv register if VEX_4VOp3 is true and assumes register, vvvv register, memory if VEX_4V is true. I just need to change the flag from VEX_4VOp3 to VEX_4V. There are a few places where we assume only the 2nd operand can be tied-to: Desc->getOperandConstraint(1, MCOI::TIED_TO) != -1 (hard-coded index 1) I will fix those

I don't think changing to VEX_4VOp3 to VEX_4V is the right fix. I think the fix is to increment CurOp twice at the start for these instructions so that only the input operands are used for encoding. Also, I just submitted a patch to revert the operand order for these instructions in the assembler/disassembler. Destination register should appear on the right and the mask should appear on the

I need to implement an instruction which has 2 read-write registers, so I added let Constraints = "$src1 = $dst, $mask = $mask_wb" in { ... def rm : AVX28I<opc, MRMSrcMem, (outs VR128:$dst, VR128:$mask_wb), (ins VR128:$src1, v128mem:$src2, VR128:$mask), ... } There is a problem since MRMSrcMem assumes the 2nd physical operand is a memory operand. See the section about

On Jul 9, 2012, at 4:15 PM, Manman Ren <mren at apple.com> wrote: > > I need to implement an instruction which has 2 read-write registers, so I added > let Constraints = "$src1 = $dst, $mask = $mask_wb" in { > ... > def rm : AVX28I<opc, MRMSrcMem, (outs VR128:$dst, VR128:$mask_wb), > (ins VR128:$src1, v128mem:$src2, VR128:$mask), > ... > }

We've discovered a problem in the AVX2 gather patterns X86InstrSSE.td. According to the AVX2 manual, no two of the destination register, vector index register and mask register can be the same. The patterns in X86InstrSSE.td are missing this constraint and it's possible to generate an illegal instruction. It doesn't look like TableGen supports Constraints beyond EARLY_CLOBBER and

> It doesn't look like TableGen supports Constraints beyond EARLY_CLOBBER > and TIED_TO. We would need to add a constraint such as "$dst != $src1, > $dst != $mask, $src1 != $mask" to the current patterns to enforce the > rules. You can emulate such constraints via early clobbing. Just mark dst as early clobbing. > Is there another mechanism to suport a constraint

>> It doesn't look like TableGen supports Constraints beyond EARLY_CLOBBER >> and TIED_TO. We would need to add a constraint such as "$dst != $src1, >> $dst != $mask, $src1 != $mask" to the current patterns to enforce the >> rules. > You can emulate such constraints via early clobbing. Just mark dst as > early clobbing. How would that (or any early

All, TableGen likes to infer the MCID::UnmodeledSideEffects flag from an instruction's pattern. When an instruction doesn't have a pattern, it is assumed to have side effects. It's possible to override this behavior by setting neverHasSideEffects = 1. It was originally the intention that most instructions have patterns, but that's not the way it worked out. It is often more

Hi Johnny, Thank you for your help. I guess the pseudo instruction does not interfere in the generated assembly code. I'll check the file that describes the registers and I hope understand why the assembly code is printed wrong (now is printed things like add r1, r0, -40). Cheers, Carlos Carlos Almeida Jr On Thu, Nov 27, 2014 at 7:56 AM, Johnny Val <johnnydval at gmail.com> wrote:

----- Original Message ----- > From: "Craig Topper" <craig.topper at gmail.com> > To: "Chandler Carruth" <chandlerc at google.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, December 30, 2013 2:29:50 PM > Subject: Re: [LLVMdev] Random question about the x86 backend (and backends in general I suppose)

On Dec 30, 2013, at 8:40 PM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 30, 2013, at 4:17 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> ----- Original Message ----- >>> From: "Craig Topper" <craig.topper at gmail.com> >>> To: "Chandler Carruth" <chandlerc at google.com> >>> Cc: "LLVM

In our generated asm code we've got a constraint such that two registers in a ternary op have to be in different "banks", best illustrated with an example: add r1,r2,r1 # r1 <- r2 + r1 The problem here is that the first operand (the receiver of the value) is in the same "bank" as the 3rd operand (r1 again). This will cause an extra cycle to be burned. As it turns

On Wed, Jan 23, 2013 at 4:40 PM, Tim Northover <t.p.northover at gmail.com>wrote: > >> It doesn't look like TableGen supports Constraints beyond EARLY_CLOBBER > >> and TIED_TO. We would need to add a constraint such as "$dst != $src1, > >> $dst != $mask, $src1 != $mask" to the current patterns to enforce the > >> rules. > > You can

Anton Korobeynikov <anton at korobeynikov.info> writes: >> It doesn't look like TableGen supports Constraints beyond EARLY_CLOBBER >> and TIED_TO. We would need to add a constraint such as "$dst != $src1, >> $dst != $mask, $src1 != $mask" to the current patterns to enforce the >> rules. > You can emulate such constraints via early clobbing. Just

On Jan 7, 2014, at 10:47 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jan 7, 2014, at 10:40 AM, Evan Cheng <evan.cheng at apple.com> wrote: > >> >> On Dec 30, 2013, at 8:40 PM, Chris Lattner <clattner at apple.com> wrote: >> >>> >>> On Dec 30, 2013, at 4:17 PM, Hal Finkel <hfinkel at anl.gov> wrote:

Using bundles here looks like a fragile way to handle that, IMHO. Really, using a pseudo instruction seems the best approach for you. For instance, you can match your add64 during isel with your pseudo instruction and expand it just before emitting the assembly file (add a pass using the hook: addPreEmitPass on your target). -Quentin On Apr 15, 2013, at 2:37 PM, Francois Pichet <pichet2000

On Aug 21, 2012, at 2:02 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > All, > > TableGen likes to infer the MCID::UnmodeledSideEffects flag from an instruction's pattern. When an instruction doesn't have a pattern, it is assumed to have side effects. Hi Jakob, I don't understand what you're saying. Are you proposing that all properties (may load,

I really have to force them to stuck together otherwise the carry will just not work. How about wrapping the 2 instructions in a bundle? Would that be a way? http://llvm.org/docs/CodeGenerator.html#machineinstr-bundles On Mon, Apr 15, 2013 at 5:24 PM, Quentin Colombet <qcolombet at apple.com>wrote: > Hi Francois, > > If you model the effect of your carry on the instructions, the

Hi, I want to encode Loongson ISA initially https://gist.github.com/xiangzhai/8ae6966e2f02a94e180dd16ff1cd60ac gslbx           $2,0($3,$4) It is equivalent to: dadd $1, $3, $4 lb $2,0($1) I just use  mem_simmptr  as the default value of  DAGOperand MO , because  MipsMemAsmOperand  use  parseMemOperand  to parse general  MemOffset  and only *one*  AnyRegister , for example: 0($1) But 

Having worked with a few people to better understand the tablegen descriptions of instructions and patterns in LLVM's backend and looking at x86's pretty heavily, I have some questions: 1) Are there instruction definition flags that are really just "when needed"? I'm thinking of things like "mayLoad" which is really alarmingly missing from a bunch of instructions